JDK Version Poll Results

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/

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

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

[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

[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

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.

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'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.

[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.)

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