Todd Huss has blogged that "It's still too soon to move to J2SE 5.0." His reasons are based on industry adoption rates, tool support, and competitive advantages. He goes on to state that when J2SE 5 becomes a mainstream JVM, he'll move to Java 5.

One of Mr. Huss' objections is that tools and libraries aren't fully supporting Java 5 yet. Eclipse, IDEA, and Netbeans IDEs all support Java 5 currently, and they're not the only major IDEs that support Java 5. Libraries are slowly migrating to Java 5, with some libraries depending on the new features (primarily annotations and generics).

The subject of migration doesn't end with tool or library support, however, especially on the server side. Have many application servers been certified for use with the new JVM? Which ones are you using? What issues have you come across, if any, in considering migrating your enterprise applications to Java 5?

One of Mr. Huss' objections is that tools and libraries aren't fully supporting Java 5 yet.

I think it should be "do not fully take advantage of Java 5 yet" as Java has at least a decent history of being backwards compatible.

Personally I don't think "feature support" should be the deciding factor: stability and reliability should be the deciding factor.

Previous new versions of Java have usually made great steps forward in the JVM itself, such as performance and scalability (correct me if I am wrong, but Linux 2.6 combined with Java 5 is miles ahead of Linux 2.4 and Java 1.3 in terms of performance and scalability if i remember correctly?).
Even if you are not yet using all the bells and whistles of Java 5, such improvements should be good enough justifications in most cases, so long as the stability and reliability is satisfactory.

Personally I don't think "feature support" should be the deciding factor: stability and reliability should be the deciding factor. Previous new versions of Java have usually made great steps forward in the JVM itself, such as performance and scalability (correct me if I am wrong, but Linux 2.6 combined with Java 5 is miles ahead of Linux 2.4 and Java 1.3 in terms of performance and scalability if i remember correctly?).

My home laptop is fairly bleeding edge Gentoo Linux and J2SE 1.5 has definitely been more stable on Linux 2.6 than the 1.4 series. I could not run Eclipse for the past six months on 1.4 due to a JIT bug that crashed the JVM. The problem got fixed only recently in 1.4.2_08 whereas 1.5 has worked fine the whole time. So at least for me, Java 5 has been a much smoother ride on 2.6 series kernels.

Previous new versions of Java have usually made great steps forward in the JVM itself, such as performance and scalability (correct me if I am wrong, but Linux 2.6 combined with Java 5 is miles ahead of Linux 2.4 and Java 1.3 in terms of performance and scalability if i remember correctly?).

I'm not so convinced that Java 5 (meaning the class libraries) is faster or more scaleable than previous versions. However, the version of Sun Hotspot included with Sun's distribution of J2SE 5 is certainly an improvement. The latest version of BEA JRockit is also improved over our 1.4 version, so I guess the end result is that Java 5 code is faster...

Linux 2.6 is certainly better than 2.4 in many respects (NPTL being one of them).

i have no idea whats going on with freeBSD tomcat 5.5 and jdk 1.5
i get wierd JVM crashes.
hope this is solved soon.
if someone knows anything about this i would be more than happy to get your opinion

This just in from the tools and libraries vendors/creators/maintainers: "We're not going to fully support Java 5 until more people start adopting it !. " :)

Ant1.6.x is tested on, it, and Ant1.7 will add new features like <apt> to run the apt tool, a <reachable> test that uses InetAddress.isReachable().

If you want more, come and help. Some areas for interest
-platform independent way of getting env variables (Again!)
-better process control
-maybe some jconsole integration

Java1.5 does work, there is new stuff in there that is useful. My IDE of choice (IDEA) works in it too (some swing quirks about focus surface in that and SmartCVS),

Andy Oliver has told me numerous times that he has come across very serious garbage collection bugs in JDK 1.4.2 in large applications out in the field. Sun refuses to fix them in JDK 1.4.2 since they are already fixed in JDK5. I can't seem to find the email on it, so ask him.

Most know how hard JBoss is pushing the use of annotations, but beyond that, many developers at JBoss are dying to move to JDK 5 to take advantage of the new java.util.concurrent package. Sure, you can get many of the same features of the oswego concurrent package, but java.util.concurrent has native hooks that will allow it to scale even better.

Bill

Andy Oliver has told me numerous times that he has come across very serious garbage collection bugs in JDK 1.4.2 in large applications out in the field. Sun refuses to fix them in JDK 1.4.2 since they are already fixed in JDK5. I can't seem to find the email on it, so ask him.Most know how hard JBoss is pushing the use of annotations, but beyond that, many developers at JBoss are dying to move to JDK 5 to take advantage of the new java.util.concurrent package. Sure, you can get many of the same features of the oswego concurrent package, but java.util.concurrent has native hooks that will allow it to scale even better.Bill

Thanks, Bill.

Sometime back you mentioned JRockit 1.5. Are you still as excited about it ?

Rickard Oberg mentioned that JRockit gave him good improvements over sun's JDK. want to know how many developers out there are using JRockit.

Thanks,

BR,
Anjan Bacchu

Andy Oliver has told me numerous times that he has come across very serious garbage collection bugs in JDK 1.4.2 in large applications out in the field. Sun refuses to fix them in JDK 1.4.2 since they are already fixed in JDK5. I can't seem to find the email on it, so ask him.Most know how hard JBoss is pushing the use of annotations, but beyond that, many developers at JBoss are dying to move to JDK 5 to take advantage of the new java.util.concurrent package. Sure, you can get many of the same features of the oswego concurrent package, but java.util.concurrent has native hooks that will allow it to scale even better.Bill

Thanks, Bill.Sometime back you mentioned JRockit 1.5. Are you still as excited about it ? Rickard Oberg mentioned that JRockit gave him good improvements over sun's JDK. want to know how many developers out there are using JRockit.Thanks,BR,Anjan Bacchu

Don't know how it performs (JRockit 1.5), I haven't tried its new profiling tools (you can profile, look for memory leaks on a live system with little overhead), but I intend on trying them out very soon. As long as its a stable VM, that feature alone would be cause to use it.

Bill

Thanks, Bill.Sometime back you mentioned JRockit 1.5. Are you still as excited about it ? Rickard Oberg mentioned that JRockit gave him good improvements over sun's JDK. want to know how many developers out there are using JRockit.Thanks,BR,Anjan Bacchu

Don't know how it performs (JRockit 1.5), I haven't tried its new profiling tools (you can profile, look for memory leaks on a live system with little overhead), but I intend on trying them out very soon. As long as its a stable VM, that feature alone would be cause to use it.Bill

The profiling tool we have is the Runtime Analyzer, which is hardly new, although the latest version has some improvements. The nifty new memleak tool is going to be released shortly. Both are/will be available from dev2dev.bea.com.

Andy Oliver has told me numerous times that he has come across very serious garbage collection bugs in JDK 1.4.2 in large applications out in the field. Sun refuses to fix them in JDK 1.4.2 since they are already fixed in JDK5.

Bill,

Which garbage collection bugs are you referring to? We came across a problem with garbage collection when there are too many calls to String.intern(). Try turning off ALL logging and see if you can reproduce it.

Vincent

In Linux, and I believe even on other platforms, it is a well known problem that 1.4 VM's can crash when memory is being consumed and freed from the heap. Google SIG11 and JVM 1.4 and you'll see what I mean.

Hyperthreaded processors show this problem even more prominently. Sun has refused to fix this because there isnt a single reproducible test case. Meanwhile, in the real world, people have to resort to various hacks like -Xint:gc or setting max and min heap to the same value (a solution we've employed in the past) in order to avoid this problem.

Its a serious problem with nothing to do with String.intern()

Java 5 brings enormous productivity gains, not least because you allways know what is inside a collection unlike in previous java versions where it was a question of trawling through javadoc/source code to figure out what they'd put into the danged thing.

Java 5 is fast, stable, easier to code with than previous versions. Learning it now will also get you up to speed
quicker ( it's easy anyway ) with the new ejb3.0 stuff
as well when it gets popular.

Basically the only reason not to upgrade is if your code is
full of variables called "enum" or if you are relying on open source profiler tools such as the eclipse profiler ( doesn't work with jdk 5.0 ) appart from that I've been using it the last 6 months and it works like a treat ( especially now that eclipse ( almost ) fully supports it.

--b

...or if you are relying on open source profiler tools such as the eclipse profiler ( doesn't work with jdk 5.0 ) appart from that I've been using it the last 6 months and it works like a treat ( especially now that eclipse ( almost ) fully supports it.--b

Or you could use NetBeans, its profiler, and a Mustang pre-release. When 1.5.0_04 is out, then you can just use it with NetBeans' profiler.

From the perspective of someone in an IT organization running someone else's app server, to some degree they have to wait until the app server vendors verify proper operation under Java 5, fix any unexpected incompatibilities, etc.

For everyone else (most especially the app server vendors) and for other unrelated IT projects, I don't see why everyone should not be on Java 5 full bore by now. IDEA and NetBeans have had 1.5 support for some time now. Eclipse has lagged in this area (due in part to their insistence on writing their own Java compiler as I see it), but even they have a workable development milestone release with 1.5 support.

Of course if you're an OpenOffice developer apparently you're supposed to stick to ancient APIs until GCJ, etc, catch up -- which seems rather unfortunate to say the least.

Finally, if you're using an OS without a stable Java 5 then it is probably a good sign that your OS is solidly in the third world in terms of technology adoption. In that case, blame the OS, not Java 5 -- it's quite ready.

Of course if you're an OpenOffice developer apparently you're supposed to stick to ancient APIs until GCJ, etc, catch up -- which seems rather unfortunate to say the least.

That's completely wrong. OpenOffice.org currently sticks to Java 1.3 because on many platforms where OpenOffice.org's market lies, the state of the art is Java 1.3 and nothing else.
Gcj and Kaffe both use GNU Classpath for the core class libraries. GNU Classpath is working on the latest specified class library revisions.

For more information, feel free to send me an e-mail, or drop by on irc://irc.freenode.org:#classpath

cheers,
dalibor topic

OpenOffice.org currently sticks to Java 1.3 because on many platforms where OpenOffice.org's market lies, the state of the art is Java 1.3 and nothing else. Gcj and Kaffe both use GNU Classpath for the core class libraries. GNU Classpath is working on the latest specified class library revisions.

On what platforms is Java 1.3 "state of the art"? On (reasonable/x86) Linux, HPUX, Solaris, Mac OS X, and Windows, stable Java 5 releases are available. On AIX and IRIX, Java 1.4.x releases are available. So is this all about odd-ball Linux and FreeBSD variants?

Personally I have trouble considering any OS that does not have a stable Java 5 by now -- for personal or development use -- irrespective of why there is no stable Java 5 there yet (e.g. regardless of how hard brilliant GNU folk are working on rectifying this).

I know it supports 5.0 in the Eclipse 3.1 Milestones.
But using non-release versions of a tool is in many companies an absolut no-no.

I know it supports 5.0 in the Eclipse 3.1 Milestones.But using non-release versions of a tool is in many companies an absolut no-no.

Well that is a bit dumb, because it is only the IDE that is in pre-GA (General Availability) phase and not the actual compiled code you are working on ...

Just my two pence!

Peter P

I know it supports 5.0 in the Eclipse 3.1 Milestones.But using non-release versions of a tool is in many companies an absolut no-no.

Well that is a bit dumb, because it is only the IDE that is in pre-GA (General Availability) phase and not the actual compiled code you are working on ...Just my two pence!Peter P

What do you mean by compiled code? The code of my project?
Well actually it is pre-GA, too, since Eclipse uses its own Java compiler.
In my opinion it is irresponsible to risk your time and the code you are working on by a possible bug in a pre-GA IDE.
(Of course GA IDEs have bugs, too, but hopefully many fewer ;)

just my 2 Eurocents

Well, nothing prevents you from compiling with ANT and use Eclipse only for editing...

Well, nothing prevents you from compiling with ANT and use Eclipse only for editing...

Of course, but then I cannot use the benefits from Eclipses incremental compilation, which is a massive productivity boost for me.

I put in the original message I replied on to make it clearer:

What do you mean by compiled code? The code of my project?
Well actually it is pre-GA, too, since Eclipse uses its own Java compiler.
In my opinion it is irresponsible to risk your time and the code you are working on by a possible bug in a pre-GA IDE.

Well, nothing prevents you from compiling with ANT and use Eclipse only for editing...

Of course, but then I cannot use the benefits from Eclipses incremental compilation, which is a massive productivity boost for me.

What I meant was use it for building the delivered code, and you can still use Eclipse incremental compilation in the editor (while editing code).

ehh... it wanted to be use ant for building code which is delivered to the customer, and use eclipse while editing (even incremental compile while editing code)

What do you mean by compiled code? The code of my project?Well actually it is pre-GA, too, since Eclipse uses its own Java compiler.In my opinion it is irresponsible to risk your time and the code you are working on by a possible bug in a pre-GA IDE.

Well, nothing prevents you from compiling with ANT and use Eclipse only for editing...

Of course, but then I cannot use the benefits from Eclipses incremental compilation, which is a massive productivity boost for me.What I meant was use it for building the delivered code, and you can still use Eclipse incremental compilation in the editor (while editing code).
I know all that. There is to need to argue, that I'm able to work with Eclipse and JDK 5.0.
I just wanted to point out: if you want to play safe, you shouldn't use Eclipse 3.1 Milestones and Java 5.

Regarding your last suggestion:
If I use different compilers for development and deployment, I open up wide the possibility for errors in the compiled deployed code which were produced by the ant compilation, but are not reproducable by eclipses compiler (and vice versa)

What do you mean by compiled code? The code of my project?Well actually it is pre-GA, too, since Eclipse uses its own Java compiler.In my opinion it is irresponsible to risk your time and the code you are working on by a possible bug in a pre-GA IDE.

Well, nothing prevents you from compiling with ANT and use Eclipse only for editing...

Of course, but then I cannot use the benefits from Eclipses incremental compilation, which is a massive productivity boost for me.

What I meant was use it for building the delivered code, and you can still use Eclipse incremental compilation in the editor (while editing code).I know all that. There is to need to argue, that I'm able to work with Eclipse and JDK 5.0.I just wanted to point out: if you want to play safe, you shouldn't use Eclipse 3.1 Milestones and Java 5.Regarding your last suggestion: If I use different compilers for development and deployment, I open up wide the possibility for errors in the compiled deployed code which were produced by the ant compilation, but are not reproducable by eclipses compiler (and vice versa)
Yes, unfortunately that is true.... you really don't want to do that when doing remoting (we had lots of unmarshal problems when running an RMI client in Eclipse and trying to deserialize classes from the server which is compiled with ant, if we did not overwrite the travelling classes in the eclipse build output directory with class files compiled during the server build with ant from the same source).

Actually i see no problem switching Java 5 in terms of stability of virtual machine or JDK. However, some tools (especially tools creating class files automatically) are causing problems. For example XmlBeans. In ant when you use java 5, you can make the compilation target as 1.4 but there is no option like that for xmlbeans generated classes, and jar file. So when you try to use that jar file in a Java 1.4 system it does not work, or compiles.

We're using Java 5.0 for greenfield work, and overall it's been a very positive move. We've barely scratched the surface of it yet, although we heavily use generics and annotations. I've run into some issues with Eclipse and Java 5.0 support, which I have detailed here:

http://www.researchkitchen.co.uk/blog/archives/17
http://www.researchkitchen.co.uk/blog/archives/28

Overall though, I have noticed a marked performance increase. We're planning to take advantage of the enhanced JMX support next, and after that, look at the concurrency enhancements. It will be nice when support is ubiquitous though - some nice tools like Jude, for instance can't parse 5.0-based code yet.

There are two different things when talking about "moving to J2SE 5.0": using the new JVM and using the new language. For our own part we will be using the new JVM ASAP (at least on the server), whereas it will probably take quite some time before we start using the new language features in order to be able to run on older JVM's properly.

I know that it is small part of Java population, but goverment and many other companies in Serbia cannot use Java 5 since Serbian locale has been removed from Java 5, probably by mistake.

We have reported this bug few months ago and still have no response even we had enough votes to be on top 25 RFE list http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6227961

Since earlier versions of Java had support for our locale, we have to use them instead of Java 5. So that is one reason more why not to use Java 5 for serbian Java developers!

Regards,
Dejan

This is nothing new. Most large organizations, and many small one, are not willing to take the risk of upgrading OS/JVM/app-server etc., until they have a compelling reason to do so. Why upgrade if what you have now works?

In my experience, most organizations are one Java version behind. I did not upgrade to JDK 1.3 until JDK 1.4 was released, and I did not upgrade to JDK 1.4 until shortly before JDK 1.5 was released. This was not because of any technical short comings of the new JVMs; it was all about risk management.

There is always *some* problem with upgrades, even if they are small and easily fixed. Most of my problems came from the introduction of new keywords and library classes. For JDK 1.4, I got bitten by the "assert" keyword; for JDK 1.5, I had problems with the enum keyword and java.awt.List conflicting with java.util.List. These were all minor problems caught by the compiler, but multiplied over tens of thousands of lines of code, upgrading is not trivial.

Given all that, I am happy that there are early adopters out their blazing the trail for me :)

In my experience, most organizations are one Java version behind.

At the job I've just started, we're still using 1.2 :( The problem with being conservative is that you can fall so far behind that it's too hard to catch up. The need to upgrade becomes stronger and stronger but the difficulty of getting anywhere near current rises just as fast.

In my experience, most organizations are one Java version behind.

At the job I've just started, we're still using 1.2 :( The problem with being conservative is that you can fall so far behind that it's too hard to catch up. The need to upgrade becomes stronger and stronger but the difficulty of getting anywhere near current rises just as fast.

Agreed. At least *starting* the upgrade process as early as possible is the only reasonable approach. For instance, determining what things will need to be changed and thus not producing more instances of them should be done as soon as possible.

In my point of view, Java 5.0 has two main purpose:

1. Increase the productive for the developer:
In 5.0, Sun includes a lot of JCP implementation it. Most of them are towards to help the developer to develop series application (not only web application) with less dummy code.
2. Rich Client Platform
I think sun (and IBM) are now moving their focus from Server Application to Client Application. I guess they want to bite Microsoft somehow. 5.0 not just bundle a new Look and Feel, Ocean. It also make a noticeable performance enhancement in User Interface (Swing). One of my duty is develop Java Application. I found that the performance (UI) of 5.0 is far better than 1.4.

One point I would like to highlight 5.0 is not the destination. I have tried the 1.6 beta. The improvement between 1.5 and 1.6 is far far better then 1.4 to 1.5. I am looking forward to use 1.6 in my application.

Sun seems to have completely rewritten the ORB in 1.5. There's a number of bugs that give us headaches --- outgoing calls on the client that have no counterpart on the server side. We're actually quite happy with the version in 1.4.2. If we were just allowed to bundle it with a 1.5 VM ...

There are 3 major JVM providers, but AFAIK only IBM thinks that is's too soo to move to J2SE5.0 :))

Regards,
Horia

IBM thinks that is's too soo to move to J2SE5.0

IBM even thinks it's too soon to move to J2SE 1.4!

Continuing on the serious side, I think 5.0 is doing very well, there appears to be good support from vendors, several now standardise on 5.0, the small/medium ones not the monolithic dinosaur vendors. All the serious IDEs provide good support for 5.0 now especially IntelliJ and most OS projects are now releasing updates for 5.0.

That's my view of the world anyway.

-John-

There are 3 major JVM providers, but AFAIK only IBM thinks that is's too soo to move to J2SE5.0 :))Regards,Horia

Sun, HP, and Apple all have stable Java 5 releases...

We upgraded from 1.3 through 1.4 to 1.5 in one go. We got stuck on 1.3 because they changed focus management in 1.4 and migrating gave me problems with the JTableForEdit component (a specialized JTable setup for easy editing like ENTER=edit next cell). The 1.4 to 1.5 migration had no issues what so ever. I'd say that is a great backwards compatibility record.

There are 3 major JVM providers, but AFAIK only IBM thinks that is's too soo to move to J2SE5.0 :))Regards,Horia

Sun, HP, and Apple all have stable Java 5 releases...

I think that by the three major JVM providers he means Sun, BEA and IBM. Of these, IBM has not released a Java 5 version yet, and I have not seen any commited dates from their part.

I've been seeing a lot of open source softwares are getting more support for JDK 5.0. For instance, Ant, Eclipse 3.1 M7, Tomcat 5.x, etc...

That is becuase support will be in Weblogic 9.0

http://e-docs.bea.com/wls/docs90/notes/new.html

There is always going to be some inertia, viz my apps works well now, why should I change it. However moving to 5.0 will prevent potential future breakages and will provide better diagnostics if the unthinkable does happen.

If you plan to run 64-bit on Linux AMD based systems (including Sun's V20z and V40z) and you want to use a Sun JVM, you have no choice but to use a Java 5 JVM.

The only 64 bit version available in the 1.4 series JVM for Linux is the Itanium build. The only other 64-bit choices for the 1.4 series on x86 hardware is the Solaris x86 and Windows builds.

I am surprised that Sun does not build a 1.4 version for AMD Opteron Linux systems. Especially since Sun is selling alot of AMD Opteron based pizza box servers running 64-bit Red Hat Enterprise. I suppose they think that most companies buying their V20z line (like mine) are also ready to move to Java 5 as well.

I think that is a mistake to not have a 64-bit Opteron build for 1.4, but at least for us, Java 5 has been stable so far running 1.4 created binaries.

We have been running 64-bit Opteron servers with Sun JDK5 and JBoss 3.0.5 for 6 months now. No problem, whatsoever. Works like a charm.

I've got 1.5.0_03 running on a V40z running RedHat Enterprise 4 (beta, 2.6.9 kernel) and it flys, I don't think I've ever seen anything run quite so fast on a single machine. I'm waiting for Sun to put Solaris 10 on it (hopefully dual boot) but it's really impressive.


[root@V40z ~]# uname -a
Linux V40z 2.6.9-6.37.ELsmp #1 SMP Tue Mar 29 15:46:31 EST 2005 x86_64 x86_64 x86_64 GNU/Linux
[root@V40z ~]# java -version
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_03-b07, mixed mode)


It's probably also worth noting that we saw a good 15-20% performance increase with 1.5 over 1.4.2 on Linux (2.4.24 kernel with Redhat E3 modes, i.e. similar to 2.6 kernel). Likewise with Solaris 8 on a 490.

J2SE 5.0 is worth using just for the performance gain, haven't seen a core dump yet, something I got used to with 1.3.

If anyone has a benchmark or application that I can run "out of the box", i.e. without spending more than a minute on it I'll happily try it out for you and post the results back here.

-John-

I've got 1.5.0_03 running on a V40z running RedHat Enterprise 4 (beta, 2.6.9 kernel) and it flys, I don't think I've ever seen anything run quite so fast on a single machine. I'm waiting for Sun to put Solaris 10 on it (hopefully dual boot) but it's really impressive.

I am also running 1.5.0_03 on 16 Sun V20zs and have been pretty happy with both the performance and stability using the default JVM settings.

Only one exception is that since our batch application requires a huge memory footprint (4 to 8 gig) per job, reducing the large FullGC times by spreading GC out over time has been the only real challenge.

I have also had a few core dumps of the JVM when using XX:+UseConcMarkSweepGC in combination with the various CMSIncremental options as recommended by Sun for 1-2 CPU machines here http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html.

I'm still trying to come up with the best combinations of flags to suit the requirements, but so far, the default settings seem to be the most stable, but with the downside of longer FullGC cycles.

I suspect that most who do not have the strenuous requirements for the JVM and GC management will find the default options to work quite well.

I am also running 1.5.0_03 on 16 Sun V20zs and have been pretty happy with both the performance and stability using the default JVM settings. Only one exception is that since our batch application requires a huge memory footprint (4 to 8 gig) per job, reducing the large FullGC times by spreading GC out over time has been the only real challenge.I have also had a few core dumps of the JVM when using XX:+UseConcMarkSweepGC in combination with the various CMSIncremental options as recommended by Sun for 1-2 CPU machines here http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html.I'm still trying to come up with the best combinations of flags to suit the requirements, but so far, the default settings seem to be the most stable, but with the downside of longer FullGC cycles.I suspect that most who do not have the strenuous requirements for the JVM and GC management will find the default options to work quite well.

Out of curiosity:
Have you tried the -XX:+UseAdaptiveSizePolicy flag with -XX:MaxGCPauseMillis=x ?
I made quite good experience with it, but that is on Solaris 9 Sparc.

Out of curiosity:Have you tried the -XX:+UseAdaptiveSizePolicy flag with -XX:MaxGCPauseMillis=x ?I made quite good experience with it, but that is on Solaris 9 Sparc.

I have used -XX:+UseAdaptiveSizePolicy with some success, but have not tried the MaxGCPauseMillis flag. That flag isn't apart of Sun's GC tuning document and I read elsewhere that it is simply a hint, so I wasn't sure if it was worth playing with.

Have you had any experience with MaxGCPauseMillis and if so, did it help any?

Out of curiosity:Have you tried the -XX:+UseAdaptiveSizePolicy flag with -XX:MaxGCPauseMillis=x ?I made quite good experience with it, but that is on Solaris 9 Sparc.

I have used -XX:+UseAdaptiveSizePolicy with some success, but have not tried the MaxGCPauseMillis flag. That flag isn't apart of Sun's GC tuning document and I read elsewhere that it is simply a hint, so I wasn't sure if it was worth playing with.Have you had any experience with MaxGCPauseMillis and if so, did it help any?

Yes, I have some experience, but not much comparison how it would have looked without using it (I just used it from the start and it worked fine ;)
I use -XX:UseParallelGC -XX:+UseAdaptiveSizePolicy -XX:+MaxGCPauseMillis=2000. When the application (Webapp with Tomcat) gets more load I watched the GC pauses to get longer but never above 2 seconds. Instead the pauses between full collections decrease. With less load the heap size is reduced by the vm, with more load it is increased. So adaptive sizing seems to work quite well.

However, as I said, I haven't checked, how it would be without it and my heap sizes are much smaller than yours (up to 700 MB)

Really funny, Im working everyday and in every project with the J2SE 1.3.1.15 . Move to 1.4 is like a dream... Here every customer use old Application Servers, and every day seems more difficult upgrade the J2SE because every day they have more applications to migrate. It is a chain difficult to break ...

It is a common issue? Im the only one who think that work with J2SE 5.0 is like a sci-fi film?

Hi all,

JDK 1.6 is out in probably 10 month give or take... since every dev guy is probably still using JDK 1.4.* , how the hell are they going to catch up and take advantage of the new features (that's been out for a year now) if they don't start using it now (lazy lazy lazy) yes there a a few valid reasons why not to upgrade to 1.5... but at least over 2 dozen why to move to 1.5 (most of us come under the latter)
The latest update (_03) fixes a total of 70+ bugs and if Sun's Java team releases another update (_04) that's another 45+ bugs fixed.

Yes so what if eclipse took a year to take advantage of 1.5 (more like to catch up) ... hell 5 years ago we used notepad/emacs & the code still holds out... use Ant, it's here to help us now ;-)!!!

As I said 1.6 is out in a number of months or even if it's a year... if your code is thousands of lines it's time to start looking into the future & upgrades... besides for real who used enum as a key word in Java pre 1.5???? most of us are from C++ backgrounds and know not to use it any way!!!

If you don't tend on using any 3rd party libs/tool (that still use pre 1.3 ) or are starting a new Java dev team... use Java 1.5 (or atleast have a think-tank meeting about it)
Also I thought Sun killed 1.3 and are not supporting it any more ... soooo 1.4 in a few years time is dead (with all this year hard work coding and all)... you get the idea.

Just my two cents...

besides for real who used enum as a key word in Java pre 1.5???? most of us are from C++ backgrounds and know not to use it any way!!!

*looks around*
*raises hand*
*shrug*

In my defense, I've never used C++ :)
(I'm assuming you mean "variable name", not "key word".

(I'm assuming you mean "variable name", not "key word".

hehehe ... ooops yeah meant as a variable name. Thanks.

Also I thought Sun killed 1.3 and are not supporting it any more ... soooo 1.4 in a few years time is dead (with all this year hard work coding and all)... you get the idea.Just my two cents...

Indeed. J2SE 1.3.1 is being end of life'd next year. Quote from Sun's website:

"J2SE 1.3.1 has begun the Sun End of Life (EOL) process. The EOL transition period is from Oct 25, 2004 until March 30, 2006. With this notice, customers should now begin to move to current product versions.

During the EOL transition period, the products will be supported as per existing customer support agreements. After this period, these products will no longer be supported by Sun."

...so if you rely on Sun to provide Java 1.3 support, you ahd better start migrating...

In my company, we upgraded production jvm-s from 1.2 to 1.5 when 1.5 update1 came out. By that time we had done a new major project development on 1.5 since the beta came out and had been running our old servers in dev/test environments (Solaris 8) on 1.5 as well.

We had our reasons for it, the main ones being:
* 1.5 is the first to support nio + ssl.
* not to fall too far behind. As 1.2 had been EOL-d, and we had some problems with it.

Generally - we are happy with the results. Of course there were things that had to be considered/paid attention to. The ones that pop into my mind atm (6am here) are:

* 1.2 jvm uses hardcoded character encodings, starting from 1.4 platform default is used.
* 1.5 jvm instance takes about 70M more memory than a 1.2 one. Having to run ~40 server instances in some production environments, swap size had to be increased.
* Eclipse 3.1M7 was the first version that we have not had a 1.5-related problem with. It did not come out too long ago..

Cheers,
Einar

.. and see you at the JavaOne2005 ;)