Time for genuine 'write-once, run-anywhere' Java

Oracle and BEA: a new hope?

Providing a secure and efficient Helpdesk

One of the big selling points of Java has been its "write once, run anywhere" capabilities. Of course, in practice, this has always been "write once, test everywhere" you intend to deploy your chosen application.

With the planned purchase of BEA Systems by Oracle, I got to thinking about what this meant for the "write once, run anywhere" mantra in relation to application servers.

My thoughts were partly spurred by my need to port a large server application to IBM's WebSphere and Oracle's Application Server from BEA's WebLogic. This left me thinking about the practicalities involved in porting Java, and looking for areas where an ironing out of inconsistencies between Java containers would have a beneficial effect.

As I looked deeper at the challenges the companies would face, it became clear that in many cases the problem with Java portability springs from a combination of developer ignorance and specification omissions - or at least limitations.

When it comes to Java across different Virtual Machines, there are at least two gotchas you should be wary of. The first relates to the type of JVM available. For example, we had an application running on one hardware platform using a 64-bit JVM and all was fine. In moving to a new platform, there was only a 32-bit JVM available. On this platform the application suddenly started experiencing out of memory exceptions. In a similar vain, I know of a colleague who had a working system on a 32-bit JVM but when moving to a 64-bit JVM found that it required more memory.

The second gotcha relates to non-Java standard classes. For example, a little while ago I encountered a developer who had directly referenced the sun.security.provider.X509Factory class; this was only found when the code was run on an IBM JVM and this class was, of course, missing. Perhaps the developer should not have used this class - but nothing actually stopped him from doing so.

Next, there are application-server specific issues. I refer, of course, to those parts of a server-side system that are not specified by Java EE but are needed to correctly deploy an application to the application server. These are application-server specific deployment descriptors (such as weblogic.xml or orion.xml). Each of these files has its own format, which may vary widely (for example WebSphere uses an .XMI format). However, it goes further than that, as in some cases defaults can be assumed and on other application servers no default is provided - or an alternative default is used.

Internet Security Threat Report 2014

More from The Register

next story
Microsoft on the Threshold of a new name for Windows next week
Rebranded OS reportedly set to be flung open by Redmond
'In... 15 feet... you will be HIT BY A TRAIN' Google patents the SPLAT-NAV
Alert system tips oblivious phone junkies to oncoming traffic
Apple: SO sorry for the iOS 8.0.1 UPDATE BUNGLE HORROR
Apple kills 'upgrade'. Hey, Microsoft. You sure you want to be like these guys?
SMASH the Bash bug! Apple and Red Hat scramble for patch batches
'Applying multiple security updates is extremely difficult'
ARM gives Internet of Things a piece of its mind – the Cortex-M7
32-bit core packs some DSP for VIP IoT CPU LOL
Lotus Notes inventor Ozzie invents app to talk to people on your phone
Imagine that. Startup floats with voice collab app for Win iPhone
prev story


Providing a secure and efficient Helpdesk
A single remote control platform for user support is be key to providing an efficient helpdesk. Retain full control over the way in which screen and keystroke data is transmitted.
Intelligent flash storage arrays
Tegile Intelligent Storage Arrays with IntelliFlash helps IT boost storage utilization and effciency while delivering unmatched storage savings and performance.
Beginner's guide to SSL certificates
De-mystify the technology involved and give you the information you need to make the best decision when considering your online security options.
Security for virtualized datacentres
Legacy security solutions are inefficient due to the architectural differences between physical and virtual environments.
Secure remote control for conventional and virtual desktops
Balancing user privacy and privileged access, in accordance with compliance frameworks and legislation. Evaluating any potential remote control choice.