A Portability Tale: Serial Monogamy

26 09 2007

I’ve recently been testing a pile of my Java code on different JVMs and operating systems. I’ve done enough of this in the past to expect it to all just work – which still never fails to amaze me – but with the inevitable odd little quirk or two that needs sorting out. Usually not so much in the code itself as in various things around it (build scripts, configuration files and so on).

I’ll write-up the particular minor issues that I encountered in a later post, but in the meantime it reminded me of an experience I had a few years ago, that I now think of as an example of “serial monogamy” portability.

I’d summarize this as:

for (Platform currentPlatform : arbitrarySequenceOfPlatforms) {
    manager.speak("Portability isn't an issue, we only use " 
        + currentPlatform);
    wait(surprisinglyShortTime);
}

Fortunately, we managed to ignore the implication that we should freely churn out a mass of non-portable code, and survived across a rapid succession of three different “strategic” platforms.

Here’s the full story, followed by some current thoughts on the subject.

The project

It was 2000, maybe 2001, and at the time I was working at an insurance company, relatively new to Java, and about to develop our first web-application.

This was very much an “outside the mainstream” role. The bulk of the IT department worked on mainframe systems using a 4GL and a non-relational database that were both well past their use-by dates. They’d been trying, fairly unsuccessfully, to migrate away from these technologies. You’d think this would have taught everyone a lesson about platform dependencies, but sometimes a problem is so big that it becomes a way of life.

The business people knew we needed to start finding our place on the internet, but weren’t sure what to do about it – the company didn’t deal directly with the public, and commercial use of the internet was all very new and unclear. Similarly, the IT people weren’t up to speed on internet technologies, with these being almost entirely outside of their experience and too bleeding-edge. So there were many, many unknowns, and lots of having to explain things that I was only just learning myself.

Amidst all of this, about the only thing that was made very clear to me right from the start was not to worry about portability. The system would definitely be running on the company’s IBM mainframes, as that was our “strategic” platform.

Therefore I was not to concern myself with portability in any way…

It’s definitely Websphere on IBM Mainframes

Our management also mandated the use of IBM Websphere as the application server. And an old version of it at that, on the basis that this would obviously be more stable than a newer release… Well, the “websfear” story is a saga in its own right, which many others who got ordered to use Websphere at around that time can probably guess, but that will keep for another day.

So the project was strictly aimed at Websphere on an IBM JDK on the IBM mainframe.

Whatever the practicalities for production, that wasn’t suitable for our development work, and it wasn’t even available to us when we started development. So I set up a development environment on our normal MS Windows desktops, with a Sun JDK and Ironflare Orion as a convenient application server (after trying out a few others).

There seemed to be lots of stuff in Websphere where you could get sucked into using IBM-specific classes and methods for no particular reason and without even realizing it. But I made sure we stuck to writing platform-independent Java code and using the standard J2EE APIs. The use of a different application server for development ensured we stayed free of any dependencies on Websphere. It also helped pin-down a lot of bugs in Websphere that were clearly its own bugs rather than something we were doing wrong, whatever the IBM people tried to imply (at some point we started using Tomcat as well for the same purpose). Most of the other usual portability issues were ironed out by virtue of developing on MS Windows but with the mainframe as the target platform.

All of this was regarded as OK so long as we kept quiet about it. Any mention of portability or being able to develop on one platform whilst deploying on another would bring an immediate reminder from management that there’s absolutely no point in making any allowance for any other platforms: we must not spend a moment’s effort or worry on portability, and Java being “theoretically” cross-platform is of no relevance whatsoever.

What actually happened, predictably, is that whilst we were writing the application the company decided on a new IT strategy…

It’s definitely Websphere on IBM AS/400

The new strategy was to move everything from the mainframe onto AS/400s.

So at this point I was told that the application needs to run on Websphere on AS/400 – but don’t worry about portability, because that’s our new “strategic” platform for the forseeable future and there won’t ever be any need to run on anything else.

Thankfully all our code ran on the AS/400 quite happily, despite it having a somewhat unusual operating system that I’d never worked with before (see, for example, this overview).

Guess what? We then got taken over by another company…

It’s definitely Oracle on Unix

The company taking us over had existing non-Java web-applications, and ran everything on Oracle software running on Unix.

So at this point I was told that our application needs to run on Oracle’s application server on Unix. But also that this obviously won’t work, because our application has been developed purely for Websphere on IBM hardware. And anyway, Oracle’s application server is a big and nasty old beast that we’d never manage to get to grips with.

As it happens, about this time Oracle suddenly introduced a re-branded copy of Ironflare Orion (i.e. exactly what we were using for development) as their brand-new “OC4J” J2EE environment. So overnight we became intimately familiar with the brand-new Oracle J2EE software that the company’s Oracle guys were scratching their heads about.

Of course, nobody believed our code would actually port across to Unix (“fine in theory, but it’ll never work in practice”). So we got access to one of the Unix machines and I demonstrated our application running on Unix. I had to make one fix to some image-processing code or something like that, but very minor. Naturally, all the people who’d doubted it were completely unimpressed (“hey, obviously it works, java is supposed to do that anyway”).

There was also some talk of maybe using BEA Weblogic, and I think I checked that our application worked on that as well, but nothing ever came of this.

So at this point I was told that the application needs to run on Oracle OC4J on Unix – but don’t worry about portability, because that’s our “strategic” platform and there won’t ever be any need to run on anything else. Of course.

Back to the Future

Sometime after this I left for wilder and riskier things. I can’t be sure of exactly what has happened since, and the particular application involved is long since dead, but the last thing I knew was that they’d been taken over by an even bigger company.

Now I may be wrong, but as I heard it all the Oracle and Unix stuff has since been junked so that everything can be consolidated onto the parent company’s infrastructure.

Which I gather is all on mainframes…

Current thoughts

I can see how the “serial monogamy” approach is reasonable from a YAGNI point-of-view. It clearly made sense to our management at the time, given our then-current expectations of software portability.

But in view of how well Java and its related standards handle portability, it probably only really makes sense if the platform truly doesn’t change and if there is a significant cost or problem in making the code as portable as possible – or if portability can be added afterwards at no greater cost than building it in from the start. On the whole this all seems rather unlikely, or at best an unecessary gamble. Except, of course, where you specifically need to use some particular proprietary and non-portable functionality.

So I tend to see portability in general as a useful code-quality that’s just part of writing good, maintainable code, rather than as an additional “feature” that requires extra effort and which you might or might not actually need at some point.

On the other hand, actually testing the portability does seem to be something that can fairly safely be left until needed – provided the code is written to be portable, you have adequately knowledge, tools and procedures to ensure this, and you have adequate automated tests to exercise the code.

Where that’s true, my own experience has been that proving the portability and carrying out any necessary final corrections can be done quite easily if and when needed, and doesn’t benefit from being done prematurely. As ever, this depends on the project and the people involved, and your mileage may vary.

My own approach at present is to write all code to be as portable as possible, but defer testing the portability until the code is otherwise complete or the portability is actually needed (depending on the nature of the project).

Advertisements

Actions

Information

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




%d bloggers like this: