Alex Miller lives in St. Louis. He writes code for a living and currently work for Terracotta Tech on the Terracotta open-source Java clustering product. Prior to Terracotta he worked at BEA Systems and was Chief Architect at MetaMatrix. His main language for the last decade has been Java, although Alex have been paid to program in several languages over the years (C++, Python, Pascal, etc). Alex has posted 43 posts at DZone. You can read more from them at their website. View Full User Profile

JDK Version Poll Results

07.16.2008
| 11907 views |
  • submit to reddit

Any other comments

Finally, there was a catch-all open question at the end for any comments. These are cataloged in full on my site but here are a few choice comments:

Some people have upgraded and not looked back:

  • I never want to go back to 1.4 (or earlier), the features added in 5 are way too useful.

Lots of people are stuck in environments where upgrading is not allowed due to risk.

  • Mostly stalled because in a big company where change = risk = oh no! cant do that!
  • If it aint broke … why break it?
  • An upgraded version of Java would have to be installed on the client PCs. The users don’t have the authority; their system administrators would have to do it. The admins are dragging their heels. It can be done with SMS. But that has to be negotiated months in advance. And our leaders dragged their heels for months during the window when it could be done. So now we have to wait another year!!!! :-[

Several complaints about Apple and their slow movement towards JDK 6:

  • Can’t migrate to 1.6 API features as Apple, in their infinite wisdom, only support x86_64 on their latest release of OS X.

Some people have had issues upgrading:

  • Had to upgrade a legacy app from 1.4.2 - biggest reaction was “Wow, that’s a lot of Generic Raw Type warnings”. We probably had around 500 of them.
  • A Swing app has rendering glitches running under JRE6, but looks fine under JRE5. We could fix it, but no one has the time because it’s deemed lower priority then adding features.
  • Mainly our problems with upgrading to Java 5 are due to Xerces issues.

And of course some people don’t know why it’s even worth upgrading. :)

  • There is not much in java 6, java 5 has some stuff, but I think that the academic types are stuffing in a bunch of junk we really don’t need. My two cents! However, we are in the process of rolling out our product in java 6 just to keep pace.

If you’re interested, you can also check out the poll stat results or poll essay results.

 

Published at DZone with permission of its author, Alex Miller.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Fabrizio Giudici replied on Wed, 2008/07/16 - 6:09am

"I find it pretty amazing that 40% (including those running even older) still had not moved to Java 5 yet. "

Indeed I find it pretty amazing that they are so few; and I am as amazed as you in learning that Java 6 has got nearly the 40% share. Every time the discussion moves on Java 6 (for instance, every time Apple drives mad people about not fully supporting it) there's a crowd of people standing up and saying "Who cares? Most people still uses 1.4, nobody uses 1.6". Well, your poll demonstrates that both assertions are false.

Peter Veentjer replied on Wed, 2008/07/16 - 8:30am

I also see a lot of companies working with Java 1.4 (especially large organizations like banks and insurance companies). Quite strange if you realize that everything under Java 5 has a broken memory model.

Thomas Mueller replied on Wed, 2008/07/16 - 9:53am

everything under Java 5 has a broken memory model

Could you please explain what you mean with this?

Alex Miller replied on Wed, 2008/07/16 - 10:42am in response to: Thomas Mueller

Before Java 5, the memory model defined in the Java Language Spec in ways that were both complicated and under-constrained.  In particular, volatiles had somewhat different semantics on different platforms. 

Java 5 addressed that with JSR 133.  You can find copious information at Bill Pugh's site:

 http://www.cs.umd.edu/~pugh/java/memoryModel/

Abby Fichtner replied on Wed, 2008/07/16 - 12:56pm

Thanks for posting these results.  As a consultant, I get to work on a lot of different projects and all the java ones seem to be stuck on 1.4.  I'm not sure if I feel better or worse to learn that it's not just them.

I think Alex's tip on the memory management improvements is excellent (thank you, Alex!) as maybe we need things like this to really push the customers to upgrade.  Does anyone know of a customer (non-techie) friendly explanation we might be able to pass on about this?

Ritesh Chitlangi replied on Wed, 2008/07/16 - 1:22pm

I have been running (it will be shifted to Java 6 on Windows tomorrow, I think) one of my programmes on a the blackdown java VM (1.4) on FreeBSD for more than a year. Why hadn't I shifted? Well, when it went into production, blackdown java was the only version available on FreeBSD.

Alex(JAlexoid) ... replied on Wed, 2008/07/16 - 3:54pm

Having been through a couple of migrations here is why I don't understand people that can upgrade:

 - Mid scale migration of a telecom app that was essential to business went without a hiccup. No code changes were made specially for the migration. Though the system never was on any app server, PicoContainer 1.1, Hibernate 2 and Struts 1.2.5 had no issues with it (mind you we migrated April 2005, 6 months after Java 5 was released). And it had mix of code in 1.4 and 5. Though everything new was written in 5 compatible syntax.

 - Service web app failed migration(code syntax only though). Why? Because the Indian "consultants" did not know Java 5 syntax(and that was autumn 2006!) and the team lead quoted his bad experience with C++ and the templates(witch are something similar to generics). Though we(the UI team) managed to migrate the WEB UI onto new syntax,the system itself had JVM update and had Weblogic 9 with Java 5 for both frontend and backend. No issues before and since it went into production.

 - Now the biggest migration. A huge processing application, with incredible requirements in reliability. The focal point of SOI of the processing workflow. Again. The syntax is OLD, the compiler is set to default version Java 5. Both new and old syntax used in the same source code. Now guess what's the platform? IBM WebSphere! Migration started with WebSphere 5.1 on J2EE 1.3 and JDK 1.4.0(that is right, trailing is 0), for graceful migration of the configuration we had to migrate initially to WebSphere 6.0 with J2EE 1.4 JVM 1.4.2(Thank you IBM for the tools that automatically did their work) and now we are happily in production with WebSpere 6.1 and JVM 1.5. Have we had any problems? Yes. Were those related to the VM version? NEVER.

 So the most problems that I have seen if the application was a riddled with hacks and/or the team was unwilling to learn new things. And always little to do with Java.

 [quote=holyroller]blackdown java was the only version available on FreeBSD.[/quote]

Atleast a year ago I had a VPS setup on hub.org and there was no problem getting Java 6 installed on FreeBSD.

Slava Imeshev replied on Thu, 2008/07/17 - 12:11am in response to: Fabrizio Giudici

 

I think the key question here is that if your poll provides a representative sample. If the sample is not representative, there is nothing to talk about. For instance, I work within two miles from a company for that if I conducted a poll I would esily get 90% of 5000 respondents using Java 6 (Sun Micro).

Why don't you tell us a bit more about the methodology used to compose the sample and the key statistical charactertics of the sample?

 

Regards,

Slava Imeshev

Cacheonix: Clustered Cache for Java

 

 

James Selvakumar replied on Thu, 2008/07/17 - 3:46am

You will be surprised. But we still use java 1.1.8 and java 1.3.1 in our products.

 But majority of our software are now running java 1.5.

java 1.1.8 is still the best available version for some versions of IBM OS/2 operating system.

 

Apart from the OS/2 thing, the major roadblock for us is the deployment size of jre. Some of our products have distributed architecture and we find it difficult to upgrade the jre remotely.

Jose Maria Arranz replied on Thu, 2008/07/17 - 6:42am

This poll doesn't seem bad, a recent online survey at javaHispano.org showed similar results.

 

Alex Miller replied on Thu, 2008/07/17 - 7:22am

@Slava My methodology was that I threw the poll up on the web, then posted about it to a few mailing lists and Twitter and my blog. Then I waited a few days.  It's highly unscientific and you should probably trust it as far as you could throw me. :) I still think it's useful and interesting.

Alexander Shirkov replied on Thu, 2008/07/17 - 9:34am

It make sence to upgrade 1.4.x to 5.0 (annotations and generics are really cool), but I have no idea, what turns me to upgrade from 5.0 to 6.0.

Slava Imeshev replied on Thu, 2008/07/17 - 3:09pm

Well, then the only consclusion you can can draw from your poll is that people are using Java 1.5, 5, and 6. You can argue about quantative characteristics of only in terms of the error. Something like, the probability of JDK 1.4. 40% being a valid value is 10% :-) In other words it is fun but very incorrect :-)

 

Slava Imeshev

 

 

Slava Imeshev replied on Thu, 2008/07/17 - 3:11pm in response to: Alexander Shirkov

[quote=sgdread]It make sence to upgrade 1.4.x to 5.0 (annotations and generics are really cool), but I have no idea, what turns me to upgrade from 5.0 to 6.0.[/quote]

 

That's right. What do you think about Java matured enough to be left alone?

 

Regards,

Slava Imeshev

 

 

Alexander Shirkov replied on Thu, 2008/07/17 - 3:35pm in response to: Slava Imeshev

I think there always will be something to add, but every upgrade have the price. If we talking about enterprise development - its cumbersome - here every action costs much and nobody will upgrade code just to try this "new fancy language thing".

Slava Imeshev replied on Thu, 2008/07/17 - 4:11pm in response to: Alexander Shirkov

 

[quote=sgdread]I think there always will be something to add, but every upgrade have the price. If we talking about enterprise development - its cumbersome - here every action costs much and nobody will upgrade code just to try this "new fancy language thing".[/quote]

Exactly! Everyone has already learnt that there is no such thing as a smooth upgrade. Frankly speaking, oftentimes there is no practical reason for upgrading. The application is in production crunching requests and everyone is happy.

That's why we have to support JDK 1.4 though we would love to move to 5.

Regards,

Slava Imeshev

Cacheonix: Distributed Cache For JDK 1.4

 

 

Dmitri Trembovetski replied on Thu, 2008/07/17 - 6:22pm in response to: Slava Imeshev

> I have no idea, what turns me to upgrade from 5.0 to 6.0.

How about huge performance gains in the VM? That must count on a server. Not sure how much you care about the client side, but there were important improvements in Swing and 2D in Java6 (in terms of fidelity, performance) as well.

Dmitri

 

Alexander Shirkov replied on Fri, 2008/07/18 - 2:26am in response to: Dmitri Trembovetski

We need tests to prove benefits of new JVM. Now it's much more simpier to put another node in cluster, add more memory and CPUs and just forget about perfomance issues. Often work of developer costs much higher, than new hardware.

If we are talking about enterpise development, we need to take in mind the fact, that major vendors like BEA, IBM and others must adapt to new features. For example, IBM WSAD 7 was released far after Java 5.0 release (their previous release use JVM 1.4.2). Plus some of vendors have their own JVMs (BEA's JRockit etc). This time gap tends to grow.

It's perfect, when you starting absolutely new project - you just take what you want and do the job, but usually we have no choice - most of projects have old legacy code. This code works and nobody will rewrite it without reason.

Alex(JAlexoid) ... replied on Fri, 2008/07/18 - 2:47am in response to: Alexander Shirkov

[quote]This code works and nobody will rewrite it without reason.[/quote]

That is the thing. There is little reason to think that you actually NEED a rewrite. Unless you actually move to a new version of API(ex: J2EE 1.4 => Java EE 5).
Why do people think that JVM 1.5 FORCES you to use Java 5 syntax?
And JVM migration is all that it is, the hardware cost. You just place the app onto a server with th enew JVM and run it to see if it has any problems.

Alexander Shirkov replied on Fri, 2008/07/18 - 3:35am in response to: Alex(JAlexoid) Panzin

Yes, you're right - nobody forces to move new syntax. In such terms it eligible to ask question: "why to move"? JVM 1.4.2 is very stable - there is no significant perfomance gains while moving on 5.0. I've tried to force my customer many times to move from 1.4.2 to 5.0, but it was solid wall - "we don't want to teach new people". People don't want to study new syntax too. They says: "It works fine, just don't touch it".

Stability and Security. You always need to wait updates (nobody in clear mind will setup JDK 1.5.0.0 on production system - it's not proven).

And the final question: what about realtime systems 365x24x7? How can we stop them, when downtime must be less than 3 seconds per year?

Alexander Shirkov replied on Fri, 2008/07/18 - 3:52am in response to: Alex(JAlexoid) Panzin

[quote=jalexoid]

You just place the app onto a server with th enew JVM and run it to see if it has any problems.

[/quote]

It simple, when you have one server. I'm not sure, that is so easy for large distributed systems. Try to replace JVMs on 1500 machines spreaded across the country (when you have tens of subsystems with complex connections). How much it costs? If there are problems, what about rollback cost?

What about fine tunings of JVMs? Can you guarantee, that excelent tuned JVM will stays same after upgrade?

Fabrizio Giudici replied on Fri, 2008/07/18 - 4:01am

Alexander's point is good, if you have a lot of nodes to be updated you have high costs. What is unclear to me, in this scenario, is how people think to go on indefinitely with an old version. I mean, we have the end of life thing and no more security updates after next Fall. Is this acceptable? This could be ok if e.g. the application we're talking of is getting near to its own end of life, say it will be replaced in 2009 by a completely new system. In this case, upgrading is probably an unneeded cost. But if it will live for other 5 years, is it acceptable to stay without security patches?

The whole thing of re-testing and re-tuning a JVM upgrade has clearly a cost, but it should be part of the planned maintenance costs.

BTW, I'm involved in only one project, dating back to a few years ago, that still runs Java 1.4 code. I've made an assessment and there are some things to do in order to upgrade it to Java 6 - the most serious part is the lack of a good test plan for QA from the customer. In other words, they know they have a stable product now, but they fear to introduce instability by upgrading. If they had a good test plan, they wouldn't we worried so much; and probably up to now they just didn't want to pay the costs of a specific test session after the upgrade. In any case, the end-of-life thing is probably changing their mind.

Slava Imeshev replied on Fri, 2008/07/18 - 4:54am in response to: Fabrizio Giudici

[quote=fabriziogiudici]

But if it will live for other 5 years, is it acceptable to stay without security patches?

[/quote]

It depends on what kind of security problems are discovered. If problems do not affect the production, a system may run on an EOLed JVM forever.

Regards,

Slava Imeshev

 

Fabrizio Giudici replied on Fri, 2008/07/18 - 5:46am

Right, but often this kind of problem is discovered to affect the production after it caused havoc :-)

Slava Imeshev replied on Fri, 2008/07/18 - 6:03am in response to: Fabrizio Giudici

[quote=fabriziogiudici]Right, but often this kind of problem is discovered to affect the production after it caused havoc :-)[/quote]

 

Yes, but isn't a disaster an ultimate call for change? :-)

 

Slava

 

Alexander Shirkov replied on Fri, 2008/07/18 - 6:11am

Fabrizio, I completely agree with you - in every point. Just want to add: many of us want to migrate new versions, but they can't because of... <look all above>.

Alexander Shirkov replied on Fri, 2008/07/18 - 6:17am in response to: Slava Imeshev

[quote=imeshev]

Yes, but isn't a disaster an ultimate call for change? :-)

[/quote]

It depends. In every case it will be question of priorities: upgrade and have some potential maintenance problems / leave all "as is" and have potential security breach. 

Alex(JAlexoid) ... replied on Fri, 2008/07/18 - 7:10am

[quote=Alexander Shirkov] In such terms it eligible to ask question: "why to move"?[/quote]

 Simple: You may use new syntax and libraries in new code.

[quote=Alexander Shirkov]And the final question: what about realtime systems 365x24x7? How can we stop them, when downtime must be less than 3 seconds per year?[/quote]

Real time systems is a whole other area. The same point could be made if a critical security bug is discovered.
3 seconds per year? With upgrade/restart/reboot/whatever taking at least 30 mins, the upgrade on a non redundant system would be once per 600 years!

 [quote=Alexander Shirkov]
It simple, when you have one server. I'm not sure, that is so easy for large distributed systems. Try to replace JVMs on 1500 machines spreaded across the country (when you have tens of subsystems with complex connections). How much it costs? If there are problems, what about rollback cost?

What about fine tunings of JVMs? Can you guarantee, that excelent tuned JVM will stays same after upgrade?
[/quote]

a) The "place on one machine and test it" was meant to test the application's compatibility with the platform.(1 app against 1 platform)
b) 1500 different systems?First thing that comes to mind: Call one of the big software vendors and have them brainwash your management on things like consolidation and SOA(I bet Oracle, SAP and IBM will gladly help you out on that)
c) Fine tunings? These are mostly techie done things, some "fine tunings" are more like HACKS, witch are the reliefs at that moment, but bring big headaches down the line. Been there done that, know how to avoid it.
And even though, fine tuning parameters of a JVM is mostly compatible across versions from same vendor.

 [quote=Slava]It depends on what kind of security problems are discovered. If problems do not affect the production, a system may run on an EOLed JVM forever.[/quote]

Well I don't even think that that is even a problem,  if no one has to maintain the code. A lot of COBOL software on mainframes still runs unchanged(except for the Y2K changes made), no one seems to mind.
And anyway it is acceptable to have an EoL'ed system up, if there is no reasonable replacement,Java is NOT the case.(See Microsoft's Vista problems for the other example)

 [quote=Fabrizio Giudici]The whole thing of re-testing and re-tuning a JVM upgrade has clearly a cost, but it should be part of the planned maintenance costs.[/quote]

+1 on that. Not only should it be in the maintainace plan, but a project plan should mention platform upgrades explicitly.

 [quote]most serious part is the lack of a good test plan for QA from the customer[/quote]

 Looks like the customer is not even interested in evolving the application, so that just means that it's accessed from the wrong side. The business people should be informed and educated on what and how, and reminded that the system without maintainace WILL die.


"A bad sysadmin always has a lot of work, a good sysadmin has considerable ammount of work and an excellent sysadmin gets fired because employers think he does nothing." - by an anon excellent sysadmin.

(Everything stated above is IMHO.)

Alexander Shirkov replied on Fri, 2008/07/18 - 7:52am in response to: Alex(JAlexoid) Panzin

[quote=jalexoid]

Real time systems is a whole other area. The same point could be made if a critical security bug is discovered.
3 seconds per year? With upgrade/restart/reboot/whatever taking at least 30 mins, the upgrade on a non redundant system would be once per 600 years!

[/quote]

Firstly, we are talking NOT about bug issues. Of course cost of leaving unclosed critical bug is much higher, than redeploy app. We are talking about systems, which are working fine. It's all about cost - nobody let you down production system just because you want to install new JDK - there must be significant reason (for example, EOL of current version or major system upgrade or security issues in existing JVM).

P.S. Yes - High Availability systems requires downtime less than 3 seconds per year.

[quote=jalexoid]

b) 1500 different systems?First thing that comes to mind: Call one of the big software vendors and have them brainwash your management on things like consolidation and SOA(I bet Oracle, SAP and IBM will gladly help you out on that)

[/quote]

Yes, I saw system, which was VERY distributed. It needed to be distributed - a kind of retail system can't be consolidated (even by IBM or Oracle). I write about 1500 machines (not systems) - here were included clients systems (there was not simple desktop SWING system, but also databases etc). So, please, don't make fast conclusions.

[quote=jalexoid]

And anyway it is acceptable to have an EoL'ed system up, if there is no reasonable replacement,Java is NOT the case.(See Microsoft's Vista problems for the other example)

[/quote]

Why not. Most of projects, where I was involved NEVER will see MS environment (Vista is not server system). I strongly believe, that some of then will stay unchanged even after EOL of Java 1.4 and 5.0.

Dmitri Trembovetski replied on Fri, 2008/07/18 - 11:51am

While I understand the logic "don't fix it if it ain't broken", I would think that you need to plan ahead that it will indeed be broken at some time, broken so badly that you will need to replace the vm (if only to fix a particular bug). This means that you should have the plans in place on how to qualify and replace the vm if needed. If not, your enterprise setup is a disaster waiting to happen..

Another huge benefit in 5/6 vms is improved observability and manageability of the vm. You can observe and even manage the vm at run time, and detect (and possibly resolve) issues before they run out of control.

Dmitri

Comment viewing options

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