Write Once Run Maybe

Java was touted as WriteOnceRunAnywhere. In truth, you never know whether a java program will run or not. It depends on the JVM, and you never know what release of what JVM is going to kill you. A support nightmare.

This was somewhat true in '97 or so (on the client side), but not anymore. In the five years I've been using Java I've seen very few portability issues that couldn't have very easily been avoided... 95% involve back slashes. One problem did involve different threading models on platforms, but even then it only took about a day to port a 50,000+ LOC application from Wintel to UNIX.

I've had great success with WORA, especially when compared to other prevalent programming systems. Certainly better than CeePlusPlus! The only real trick is to ensure your JVM version. Basically, it is WORA for the JVM's your application supports, which is saying a lot more than most devleopment systems.

It is a matter of control. With CeePlusPlus you control your own link time. If you want your app to run on multiple platforms you need only use a library that runs on multiple platforms - ObjectSpace and RogueWave are two good standard ones. If you're delivering a product you will want to set up a lab to FunctionalTest the results, sure, but you'll need to do that with Java anyway. But with Java you need to keep testing with every new JVM that comes out - you're never done. With CeePlusPlus you can link, test, and then forget about it. WriteOnceRunDefinitely?.

Unless you run into DLL hell or want it work in multiple versions of winDOS including whatever version comes next. Me, I ported an EJB app from NT to Solaris in about a day without recompiling. Actually the only tweaks were some places in the config and properties files where we'd had DOS paths. Try that with CeePlusPlus

No more so than with every new version of your CeePlusPlus compiler or library.

Concerns about JVM versions largely go away if you're delivering an Enterprise application where you control the server, or where the nature of the application is such that you can dictate the browser version. --DaveSmith

If you control the server you may as well use CeePlusPlus. Then there is no need for WriteOnceRunAnywhere anymore. --MarkoSchulz

This argument for C++ over Java is pretty poor. Any time your system--and by system I mean the entire user experience, including the user, the keyboard, the OS, your imaging libraries, your code, the browser, etc.--depends on some third party (or even first party), dynamic module, you will have versioning problems when the module changes. Just look at what happens when a new version of an OS comes out--like Windows--, or with changes in HTML/browsers. The main problem with Java is that Sun markets it. They claim it's WriteOnceRunAnywhere, but there are in fact configuration problems as the anonymous poster mentioned above. Or changes to the class libraries between versions. Anyway, there is always work to be done when porting anything significant to a new platform. Except for text-only C programs because ANSI C has been pretty stable for a long time. And even then it takes discipline to know how to write portable code. -- SunirShah

I've been working with Java since 1995 and I can't remember the last time I had a portability issue (I spent three years developing on MicrosoftWindows and deploying on NT or Solaris with JavaWebServer?, ApacheJserv?, ApacheTomcat, BeaWeblogic?, blah blah). The only time I've come across problems is when people code in platform specific stuff (of course they blame Java :-). --ChanningWalton

N.B.: Case-sensitive file paths, path seperators, file seperators, 'newlines and carriage returns' are "platform specific stuff." - there must be loads more

Almost all of this can be dealt with pretty easily in Java.

Yes, perhaps it takes discipline to write portable Java as well. Except Java is humongous and C is tiny. In comparison. Perhaps a lot of discipline. -- SunirShah

By humongous, do you mean language or library? --ChanningWalton

The threading model is platform dependent. See JavaIsPlatformDependent?.

You mean threading models i assume. See GreenJavaThreads and NativeJavaThreads. In my experience these VM implementation differences have always been a killer, even on the same platform (zb. move from ibm to sun vm on linux )

Some real-world examples please? I use threading pretty extensively and have not had any problems going between Solaris, MicrosoftWindows, and Linux. All in all, it's been pretty painless developing for these platforms -- much better than the days of creating platform.h files, different build scripts, compiler options, and so on in C++. But maybe I'm missing something.

I'd recommend AllenHolub's series at JavaWorld (http://www.javaworld.com/javaworld/jw-09-1998/jw-09-threads.html) called, appropriately enough, "Programming Java threads in the real world".--AdewaleOshineye

CategoryJava CategoryJavaPlatform