I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Java 5 Reaches End of Service Life - How Does This Affect You?

10.30.2009
| 11915 views |

As Java 5 reaches End Of Service Life (EOSL) today, does that mean that you'll be upgrading to Java 6 today, if you haven't already? If you want to have support for Java 5 further than today, you'll need to switch to Java SE Support for Business.

I moved to Java 6 as soon as it became available, but I was able to do this as the product I was working on hadn't yet had it's first release. I had no bad experiences in the transition from Java 5 to Java 6. In fact, because of it's better performance, I got a lot of benefits for free.

I'm interested to see if people are still using Java 5 and why. 

I no longer use Java 5
47% (243 votes)
I will be switching to Java 6
21% (106 votes)
EOSL doesn't matter to me, I'll stick with Java 5
30% (152 votes)
I'll be moving to the business support plan
3% (13 votes)
Total votes: 514

Comments

Otengi Miloskov replied on Fri, 2009/10/30 - 11:54am

My employer still using java 1.4.2 a lot we just migrated an app to Java 5. I think it will take a long time before everybody reach to Java 6, We need Java to be very stable and robust for critical applications that takes years to develop and takes years to migrate to a new technology. I will say if you want to experiment with new language features go to Haskell or Scala. Don't change anymore the Java language it does not need anymore.

I dont want Java become similar to the complexity and mess of C# lately.

Tom Wheeler replied on Fri, 2009/10/30 - 3:31pm

Personally, I am using Java 6 and have been for a long time.  As you note, the performance improvements alone make the upgrade worthwhile. But as an instructor and consultant, I know that lots of companies are not using it yet.   In fact, I was talking to some other developers about this at the recent Strange Loop conference and they worked for companies just now planning to move to Java 5!

That matches my own informal poll, when last year marked the first time that more than half the people in a relatively advanced Java class I teach had "at least some experience" with Java 5.  

And these are multi-billion dollar companies, who tend to be averse to risk.  Java 1.4.x works well enough for them and whether or not it's officially supported by Sun is inconsequential.  I suspect their IT staff figures that an upgrade is a lot of effort/risk for little benefit. In the best case, you might see some modest performance improvements and in the worst case, you really mess things up and get fired.  I guess it's for the same reason that you can still find Windows NT 4 Server in use by many companies if you look around a bit.

Jilles Van Gurp replied on Fri, 2009/10/30 - 2:45pm in response to: Otengi Miloskov

Barring a handful of (known) issues, stuff should just work when you switch. Java 5 to Java 6 is a pretty painless switch. 1.4.2 to 1.5 (or 1.6) should not pose much issues. People tend to exaggerate the backwards compatibility issues in Java. Yes, there are isolated cases of specific API changes between versions of Java that may affect you. In most cases for good & solid reasons, which might cause you to wonder if you are not better off depending on the fixed version. All of the language features from 1.0 - 1.6 are optional and don't affect existing code (which by definition does not depend on those features to begin with). Code that compiled with 1.0 will compile with 1.6, barring API changes.

 Most of the actual issues are non technical:

1 - Certification, this affects many commercial products: you only get support if you use specific versions of Java and other components. Likely, moving to a new certified environment involves major updates of not only the jvm but also middleware components. The latter tend to be a lot less compatible from version to version, making this a major headache. Don't blame this on Java though but on the vendor of the components that are now obsolete.

2 - Testing, even if it just works there's only one way to know for sure: test the hell out of it. Many business applications are too business critical to just switch over to some new version of Java without a lot of testing taking place. Depending on the application, this can be a major expense.  On the other hand, if you have good test coverage, you should be pretty confident after your continuous build environment fails to detect any new issues. But still, some manual functional and non functional testing will be required (e.g. load and performance tests). If you don't have test coverage, don't blame infrastructure for your problems. Any kind of change is likely to be problematic from testing point of view in that case.

3 - As mentioned, there are minor, well documented incompatibilities that may affect you. That sucks obviously. On the other hand, you are probably better off knowing which those are and addressing them pre-emptively than not knowing you have show stopper compatibility bugs around the time Sun stops shipping security & stability updates for your current vm.  You might have to migrate in a hurry at some point (e.g. major security issues published with your no longer supported platform) and one way or another, those compatibility issues will come back in need of a fix at some point.

 

Alex Miller replied on Fri, 2009/10/30 - 3:08pm

I did a reasonably large poll about JDK version usage (and why people haven't switched) in summer of 2008. I thought the results were pretty interesting.  In particular, I was surprised at how many reasons there were for people NOT switching, often well beyond the developer's control.  At that point there was still heavy 1.4 usage.  Would be interesting to re-do the poll now as some of the complaints around Apple or Websphere support for older versions have changed since then. 

Result data

Result comment answers

Analysis

Zqudlyba Navis replied on Fri, 2009/10/30 - 8:40pm

If you're working on a small pet project, then sure, it's very simple to migrate.

However, I work on a multimillion dollar project with close to 50 developers and over 150 other staff on the project alone.

We're currently in the process of migrating from WebSphere 5.1 (using Java 1.4/J2EE 1.3) to WebSphere 6.1 (using Java 5/J2EE 1.4 without EJB3 feature pack).

Of course I would love to dump the application server and switch to Jetty or Tomcat, but it's out of my control.

WAS 6.1 nor WAS 7.0 don't yet have an end of line.

 See http://www-111.ibm.com/software/support/lifecycle/PLCDetail.wss?synkey=C578916B44100K52&from=spf

 Migration is little to do with technical, but more often political.

Alex(JAlexoid) ... replied on Sat, 2009/10/31 - 6:08am in response to: Zqudlyba Navis

IBM supports it's own version of JVM, so this EOSL notice does not affect you in any way.

I have migrated from 5.1 to 6.1. The pain is not with the code. The code worked perfectly without any changes. It's the changes in configuration files and deployment descriptors. Those are a pain, because you need RAD 6 and then RAD 7. And even then, the configuration had problems.

FYI: Check you watches people, from some FP onwards  WAS 5.1 has a hard limitation of 758 MB per VM.

Henk De Boer replied on Sat, 2009/10/31 - 9:18am in response to: Zqudlyba Navis

If you're working on a small pet project, then sure, it's very simple to migrate.

Please define 'small pet project'.

We're a shop developing and maintaining an application consisting of some 500k LOC, keeping approximately 12 developers and some 40 persons in support occupied. The app generates a monthly revenue of a few hundred K (euros).

I wouldn't exactly call this a HUGE app and it's also not multimillion for sure, but I think it's not exactly a 'pet project' either.

Our strategy has been to adopt new versions of Java and dependent libraries as quickly as possible. Namely, the faster you upgrade, the less you get behind and the easier each following update will be.

Typically we're only 2 minor versions behind. Currently we're running on Java 6 update 14 and Jboss AS 5.0.1. We're now testing with Java 6 update 16 and Jboss AS 5.10, which we plan to bring into production in about 5 months time. It goes without saying that to be able to do this a well oiled testing machinery is of the highest essence. Also, I am aware that growing beyond some size these fast upgrades won't be feasible anymore. If the stakes are REALLY high, i.e. if you're actually deploying a multimillion dollar app, then I can understand the upgrade fear.

However, like I said, we have been maintaining this fast upgrade pace for some 6 years now and never had a problem with it. There are always more bugs in our own code than in new versions of Java.

I absolutely don't advocate using the very latest version of the JDK without any testing, but with a careful test setup and for medium sized projects, a 5 month update cycle should be feasible for many.

Slim Ouertani replied on Sat, 2009/10/31 - 3:06pm

  •  The majority of java developer don't know what is the new features in java 6 vs java 5.
  •  I think that Mac users had a problem with java 6
  • Starting project today for embedded device uses JAVA 4 or java 3.
  • Few people change or get jdk upgrade if available
  • Not a lot of java 6 users are waiting to update 10 of java 6
 

 

 

Henk De Boer replied on Sun, 2009/11/01 - 4:29am in response to: Slim Ouertani

The majority of java developers don't know what the new features of Java 6 vs Java 5 are.

They don't have to specifically KNOW this. Just by making clever use of your tooling (e.g., autocomplete) you'll discover many of these new features automatically and start using these without realizing they are Java 6 features. Just think of silly little things like String.isEmpty().

 

I think that Mac users had a problem with Java 6.

More than a year ago there was indeed a problem, since it wasn't available back then. But guess what, two years before that Linux users had a problem too, since there wasn't a JDK 6 for their systems either. Actually, JDK 6 wasn't released at all back then...

My point is; just that something wasn't available a while back doesn't mean we can't use it *now*.

 

Anyone starting a project today for an embedded device uses Java 1.4 or Java 1.3.

Are you sure about that? The latest I heard was that Java 1.0 was still all the rage. Thinking of it, some embedded developers actually seem to prefer Java -1.1 and even using Java -1.8 is not totally unheard of it. Java -1.8 btw dates back to 1989 or so.

 

Not a lot of Java 6 users are waiting for Java 6 update 10.

I'm pretty sure about that too. I mean, it would be rather silly to still wait for an old update that was released long ago, wouldn't it? :P I you want Java 6 update 10, just head for Sun's website and download it from the archives.

Slim Ouertani replied on Sun, 2009/11/01 - 5:50am in response to: Henk De Boer

  • Generaly java version 6 cames with silent features vs java 5 or java 7 . Most develloper said why should I change to java 6 ?.
  • As I was waiting java Fx to try it in ubuntu ( linux ) and I observe some demos without test it. Now, when it became available, I haven't test it ;)
  • for embeded system, I am sure that many starting project uses java version 1.3 and 1.4 ( experience with mika jvm)

Tom Wheeler replied on Mon, 2009/11/02 - 6:18pm in response to: Henk De Boer

More than a year ago there was indeed a problem, since it wasn't available back then

It's still a problem on any G4 machine AFAIK.  Apple also didn't offer Java 6 on older Intel-based MacBook Pros (32-bit?) either, though maybe they do by now.  They're certainly not the only ones who tie their JDK to their OS -- it was like that on AIX, HP/UX and SGI IRIX machines too.  I recall having to use Java 1.3 on a machine just a couple of years ago because a sysadmin wouldn't upgrade the machine to the latest version of AIX.

But guess what, two years before that Linux users had a problem too, since there wasn't a JDK 6 for their systems either.

Huh?  I recall pretty clearly running Java 6 on Linux in early 2007.  Sun released Java 6 for Linux at the same time as Windows, just as they always do.  I don't recall Linux being treated like a second class citizen for Java since the late 1990s when you had to download the JDK from Blackdown because Sun didn't support Linux.

Ivan Lazarte replied on Wed, 2009/11/04 - 4:34pm

There are lots of multi-million dollar apps that have or will migrate to Java 6 soon.    Java esl has been timed perfectly imo.  If your company isn't actively pushing through the versions, maybe you should wonder why you're towards the bottom of that bell curve.

Henk De Boer replied on Wed, 2009/11/04 - 5:15pm in response to: Tom Wheeler

Huh? I recall pretty clearly running Java 6 on Linux in early 2007. Sun released Java 6 for Linux at the same time as Windows, just as they always do.
Of course, but you missed the joke ;) Right after that I said that JDK 6 wasn't available for any system, namely it wasn't released at all. Something that isn't released also isn't available for Linux ;) The point I tried to make there was that "once upon a time Java 6 wasn't available for any system", so therefor you shouldn't be put off by the fact that "once upon a time Java 6 wasn't available for the Mac". For the G4 there's Soylatte and the OpenJDK ports. Personally I'm running OS X 10.5 on a 32bit C1D, and therefor can't use the official Apple JDK 6 either. I could if I upgraded to 10.6, but I haven't done that yet for reasons unrelated to Java. Anyway, I'm thus running OpenJDK 6 beta1 and haven't really seen a lot of problems with it. Not something I would encourage for production use, but quite workable for development.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.