This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
One reason is that some people like to stick with what works. Have you ever written program that runs fine on, say 1.4.2_04, yet crashes the JVM in 1.4.2_06? I've seen it, and the toll it takes on the programmers is not pretty to see.
Often a new major version release is very buggy and some people don't like the potential for instability that comes with life on the bleeding edge, but will opt to wait for several minor releases to fix the initial slew of bugs. Also, some people do not need features beyond the ones their using. You'll find this fairly often with maintenance programmers.
Give a man a fish, he'll eat for one day. Teach a man to fish, he'll drink all your beer.
Cheers, Jeff (SCJP 1.4, SCJD in progress, if you can call that progress...)
In my situation. I have about 12 inches of 1.4 books, and at times I feel I'm just understanding 1.4. So I'll just wear out these books for a few more months. While I'm grasping some of the finer details of 1.4 I won't have to worry about those changes that I've not had the time to properly investigate. I feel like if I swap into 1.5 then I'll get side tracked from my learning targets.
I'm stuck on a version of WebSphere that only runs 1.3
Ditto. Anything with third party dependencies like this tends to be written in older versions of the JDK (in my experience particularly if the third party is IBM). A colleague of mine was only recently able to ditch a dependency on writing code which complied with the EJB 0.9 spec!
you shouldn't have to rename anything but you may need to specifically add a -source 1.4 flag to the compiler.
As to sticking with older releases: Our main deployment platforms are SCO (Unixware/OpenServer) and AIX, 2 platforms that have no 5.0 JVM yet. I used to work for a company where they were using an old appserver which wouldn't work with anything written to a newer than a 1.3.1 JVM (even though it allowed a 1.4.0 to work itself, the internal JVM for servlets etc. was 1.3).
I used to deploy to OS/2, back when there were 1.3 JVMs for Windows. The latest JVM for OS/2 at the time was 1.1.6 or so.
Then there's corporate policy. I once applied for a consultancy job at a company that had a hard policy to NEVER use the latest major and minor release. If 1.4.2 was the latest they'd stick with the second to last 1.3 release (so 1.3.0). They wouldn't even install the latest service packs and hotfixes(they were upgrading to NT4 SP3 when SP4 came out and only after Windows 2000 was released). However misguided such policies are there's often no way for a development group to get them changed.
My impression is that many of the enhanced features are simply more convenient ways to write Java code -- for example, replacing what might have required 3 lines in a previous version with a single line in the new version. But (in these cases) wouldn't the compiled class file essentially be the same -- still runnable / interpretable in a previous runtime environment?
Does anyone know whether this type of back compatibility (or more accurately, "back-runtime-environment compatibility") is addressed in a Sun article?
I haven't yet struggled with issues of Java deployment, but if applications compiled under 1.5 definitely require a 1.5 runtime environment, and you can't be sure of your client's platform, then this appears to be another reason to postpone upgrading. Consider, for example, that 1.5 isn't yet available on Macs, so you can't even bundle the runtime environment with your app.
Joined: Jan 29, 2003
Yes, some new language features compile into byte code compatible with older JVMs. Sometimes that means you can sneak a few classes or jars into the classpath and use them. I've never tried it, tho!