So of course everyone who writes in Java is familiar with "write once, run anywhere" and this has really helped Java get in a lot of doors. I guess this might work if you have some console app or something, but in the real world there's a lot of time spent making sure your Java (and especially J2EE applications) run on various OSes, JREs and application servers.

Today I was conducting a dismal interview where I asked about the candidate's experience with porting a J2EE application from WebLogic to WebSphere (which was listed on his resume). The candidate said that it was very easy and he just deployed his application with no problems or changes necessary, he had no changes made for the application to run properly. This was one of many bad signs for the candidate.

I really hate WebSphere and I really hate zOS (MVS). Because of this, the fates conspire to constantly make me port applications to WebSphere (I finished my third port of a J2EE app to WebSphere). Porting to WebSphere isn't the worse thing in the world. I just had to change how we read the JNDI bindings for our EJBs (which will be easier once I remove all the EJBs from the application), redo the data sources, change the JAAS configuration files I was set and the app was up and running. The real challenge came with zOS and its EBCDIC charset.

zOS is bizarre, it costs tons of money, runs slowly, is difficult to administer and gets JVMs and app server releases after everybody else; but companies use it. IBM is trying to sell Linux on the mainframe, but I'm not sure why this is a good thing. Somehow it's better to spend $1MM on a huge mainframe running a bastard form of Linux than 500 Linux servers from Dell? I'd love to see the mangled TCO studies on that one.

Anyway, our customers use zOS and they buy my company's software so we support zOS (and make our app run pretty well actually). Adding character sets to all out File IO is probably a good idea anyway as it makes internationalization easier. This solved about 50% of our problems. We also had a third party app that specifically needed the Sun JCE for some encryption algorithms it uses. The IBM JRE on zOS (and AIX actually) of course doesn't come with the Sun JCE. It comes with the IBM JCE that has pretty much the same algorithms. Usually, I just package BouncyCastle's provider or IAIK's provider but I guess you can also just reference the provider name in your code. At one point I favored modifying the security.properties in the JRE to change the provider level, but this caused problems because 1)it confused customers and 2)the provider the customer has doesn't always have the strong algorithms I need (i.e. some wimpy Sun JCEs only have the 128bit AES/Rijndael and stuff like that).

In a nutshell, when porting your app to zOS be careful about character sets and when porting to non-Sun JCEs be careful about JRE differences (like xml support and cryptography support).

I've also had to port to/from OAS/OC4J, Tomcat, JBoss and WebLogic but they usually just boil down to internal security, data sources and JNDI settings.