Examine three traps you could fall in when porting Java Web applications from Windows to AIX, and learn how to maneuver around them.
Avoid Traps When Porting Java Web Apps from Windows to AIX
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
this is more like Websphere-AIX related issues to me..
It’s more like bad-programming issues.
All three are terrible practices to be involved in once out of the learning phase.
I think this article should be renamed “porting bad software into less-bad software.”
Porting ? I thought Java was “compile one time, then run everywhere” ?
I think it’s clear to most developers that the WORA bubble has burst. Java is simply much more portable than e.g. C, which is still better than nothing. At least the fixes can be described in a few lines, and are nothing like “this library isn’t available on AIX, but there is a competing one with a completely different API and you’ll have to rewrite your entire code to make it work”
The only programming languages I’ve seen that are truly WORA are toy languages that don’t do anything useful. As soon as useful functionality enters the scene, so does system-dependent behaviour.
You’ve never experienced the greatness of scripting languages like Perl, Ruby and PHP then.
Let me refill your Kool-Aid…
If you’d read the article, you would have realized that the problems stem from bad programming practice (e.g. hard coding the carriage return, etc). Once those bits of code are written in the Java way, the problems disappear.
So yes, it still is write once run everywhere.
I don’t like CDE very much, and I didn’t think GNOME 2.6 (yes it’s a very old version) was very appropriate for my development workstation. So I tried to get fluxbox working on AIX. Big mistake.
The configure script ran successfully, but said that xft support was unavailable. Building xft required tracing down a chain of dependencies about 6 levels deep. The bottom was pkg-config, which built fine. Things were looking promising. But pkg-config really didn’t understand AIX, and every package that depended on it refused to build. I figured I could do without xft.
So I went ahead and built fluxbox without xft, using the GNU toolchain of course (xlc is out of the question). The build broke less than 10 seconds in. I gave up on fluxbox and found a binary version of blackbox compiled for AIX 5.3 on UCLA’s AIX OSS package repository. This had to work. Well, apparently my libstdc++ (from IBM’s official GNU toolchain package for AIX) was missing required symbols even though it was the exact version that blackbox was looking for.
At this point I decided I would be better of running a bunch of telnet terminals from my Linux laptop (since AIX doesn’t support ssh by default). Forget about getting most OSS packages to work on AIX. If IBM doesn’t ship an official AIX fileset or RPM for a given application, chances are you won’t be able to get it to run without a significant porting effort.
The interesting tangent is that System P, the line of POWER5 and soon POWER6-based servers on which AIX runs, relies on fluxbox. System P servers are usually partitioned into virtual hardware servers called LPARs. In order to administer LPAR configurations or communicate with LPARs when their network interfaces are unavailable, the admin must use the HMC (Hardware Management Console). This is a commodity x86 PC that sits next to the server and communicates with a special service processor on the server via Ethernet. It runs Linux and uses fluxbox as its default window manager. They even use my favorite fluxbox theme by default!
Edited 2007-02-09 03:11