Sun has released JDK 1.4.2. This release has new features, performance improvements, and over 2400 bug fixes. Some of these include: Class.forName() has been sped up, Itanium support, many hotspot improvements, NTLN auth for windows, AES encryption support in SunJCE, new Swing look and feels, startup time improvements, and many more.

Download JDK 1.4.2

JDK 1.4.2 Release Notes

JDK 1.4.2 Bug Fixes

This looks more like a move to push their NetBeans IDE than fix java bugs.

They fixed over 2000 bugs. Get a clue bub. With all of the improvements, it looks like a good, solid release.

Mike

Thats a hell lot !!! Given the fact that jdk 1.3 had 8 patches released
( 1.3.1_08), i wont still go with this 1.4.2 as the last and the best. I m sure they are working on rest of the 2000 for next months release :)

Link on 1.4.2 perf. Seems good.

http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html

So what's happened to the notorious StringBuffer memory leak bug, #4724129? This got 520 votes on BugParade (far more than any other in the list) and is marked as "Closed, fixed" for releases "1.4.1_05" and "mantis-rc" (presumably meaning the first 1.4.2 release), but it's not in the list of fixed bugs.

Anybody know what's going on?

Consider not using Sun VM.
This guy thinks Sun is going out of business:
http://www.pbs.org/cringely/pulpit/pulpit20030213.html

You do not want your clients stuck on Sun's Java.

Instead use jRockit
http://www.bea.com/framework.jsp?CNT=garbage_collectors.htm&FP=/content/products/jrockit/features/
or good old IBM VM (jikes etc.).

This way is something happens to Sun, it's a non event for you clients.

Also JRockit VM proved faster in my testing.

.V

Vic -

Aren't you getting a bit vitriolic? It doesn't seem to make a huge difference which JVM you use. I'd suggest just using whichever one meets your needs best. And unless someone uncovers a massive accounting scandal at Sun, I don't think they're going out of business any time soon.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Yep.
You really should take a guy seriously who spreads these kinds of rumours.
He had a few interesting other ones:
* Microsoft will build its next Windows on Linux
* Microsoft is absolutely behind the SCO vs IBM thing (well, some conspiracy theorists might agree, I think they just like whats happening, but dont want to get their hands dirty to obviously by associating with SCO)

And the list goes on..

Well then, Sun has to go bankrupt soon! It can only be the truth! :)

One of the good things SUN did was insist on binary compatibility.

Which means that you can run the same binary on SUN JVM and JRockit JVM.

So if SUN JVM disappeared tomorrow, then you could switch tomorrow.

No need to do anything today.

So SUN's financial status is of huge interest to SUN stockholders,
their competitors and all the stock analysts.

But completely irrelevant when deciding on what JVM to use.

-Leak on JSP compile
-Leak on StringBuffer
-GC that freezes for 15 seocnds or more
-Lack on multi maching VM remote montiroing of GC
-Up to 50% slower.
-Not allowed to distirbute SDK with war, on JRE ... I can't compile.

So I use BEA VM, becuase I like it, and above. It has a great white paper (but if you read it... you might switch to)

Of course, I provided the link of the person that stated Sun is not doing good, so you can read that link or not as to that persons opinion.
The reason it matters to me that Sun might not be doing good, as a consultant, is that I want my clients on Java, becuase I know Java. If my clients are using Sun VM today, and something happens to Sun, they might think, hey "Java is dead, lets go .Net".
But if they are runung a BEA VM, I have already sold them on "Java != Sun", today.

Java is about choice, and my choice is BEA VM. You can chose another VM, ok by me.

Also, to say that C# is not crossplatform is wrong (Ex: Mac and Mono), it is a worthy competitor. Borland and MavNet.sf.net are at C# allready.

.V

Congrats on reading the marketing materials.
Steve

So we agree that SUN's financial status is irrelevant for choice
of JVM ?

I have absolutely no problem with people preferring BEA JVM for
specific technical reasons.

It is my impression (based on relative little use though) that
BEA is a very good JVM for multithreaded servers.

Which ofcourse is the market of interest in this forum.

But not the same as the entire Java market.

vic,

You make me miss Rolf! Rolf had better command of the English language and his remarks were often witty. Rolf perfected the art of spreading FUD : he argumets where based on solid foundations even though he maged to twist them to further his case,he did it by sounding sincere with the right touch of humor. You sound like you swallowed a pitcher of bile.

You mix up wierd prognostications from hack on PBS who nobody has heard of with some issues lifted off the bug list. Dude, every SDK or JVM has issues : just because you haven't stumbled upon them doesn't mean they dont exist. Same goes for Jrocket or whatever other JVMs you offer as alternative. Go with whatever JVM works for you. In my case, I used IBM SDK on Linux and Sun JDK on Windows and then test the hell out of my code on both.

If I werent so darn lazy , I would probably try JRocket. But if I were to go by your logic , I shouldn't be touching it as BEA's jRocket as BEA's marketshare may be threatened by the likes of Jboss etc.

I dont mind the FUD -- but make it amusing!

Mainsh, for you amusement, here is the "marketing" I read a long time ago on jrockit, since before J:rockit was aquired by BEA, it is a very nice VM:
http://www.bea.com/content/news_events/white_papers/BEA_JRockit_wp.pdf
Sun might be more targeted at client side java.

BEA uses J:Rockit. Oracle ships with J:Rockit also.
IBM uses IBM VM.
So from market share point, that is a big chunk of market not using Sun JVM.

jBoss does not have a VM, if they did, but kaffe.org does have a VM (and kaffe to be included by RH maybe, if you like to look at market share).

FUD?
My soap box is "Sun != Java", Java is cross platform, pick a vendor.

.V

Oracle ships with J:Rockit? That I'll be the day!
Get serious.

Do you need the best white paper? Try Sun's HotSpot! :))

Joking apart, it is a very fast VM. I was very pleased when I switched from IBM's JDK 1.3.0 to Sun's 1.3.1 (on Windows).

There's no JRockit for Solaris plus JRockit is not free in terms of money. I also found some problems with stability of the VM (at least with version 8).

Overall I didn't see a great difference in performance that made me think about switching to JRockit.

just my 2 cents.

Can anyone recommend the best JVM for Linux ? I had opted to use IBM JDK on Linux quite a while ago because I think Sun JVM on Linux had isuses with their thread implementation or so I heard. I wonder if that issue is solved yet ?

Is there some data on JVM performance on Linux ?

Try the most stable and fast Java VM for Linux ... www.blackdown.org
Only for compliance with SUN they named their 1.4.1 release 1.4.1_001 and NOT
because of bug fixing release versioing ... It's strange that no one here mentioned this JVM, is very popular as far as I know ...

It is the SUN's JDK ports, is not it ?

Check out the JVM performance comparison from ObjectWeb:

JMOB: http://jmob.objectweb.org/
JVM Comparison: http://jmob.objectweb.org/jvm.html

=> RUBiS benchmark, VolanoMark Benchmark and SPECjbb2000 Benchmark

Regards,
Lofi.
http://openuss.sourceforge.net

HI!

I would like to post some results, to see If someone could help me to understand what’s happening here. The 1.4.2 white paper (http://java.sun.com/j2se/1.4.2/1.4.2_whitepaper.html) seems to imply that only j2sdk 1.4.2 has support for the new NPTL Linux threads. But the results that I had show otherwise.

I benchmarked using a simple web application with Jboss321. The requests go through an AAS filter that contacts an NT Server via NTLM (using jcifs) for authentication purposes. It also retrieves user profile information from a backend database, using JDBC. In the test, a JSP page shows the profile information.

The benchmark setup is as follows:

Hardware Setup:
Machine A (Redhat 8 - Server Installation): Pentium III 933 Mhz, 512 Mb Ram
Machine B (Redhat 9 - Server Installation): Pentium III 933 Mhz, 512 Mb Ram
Machine C (Windows NT Server): Pentium III 866 Mhz, 1 GB Ram

Software:
A e B: Jboss321 with Jetty configured for 500 threads, and the db connection pool configured for 200 connections.
C: Oracle 8i (8.1.7)

Load test software: Ms Web Application Stress Tool
Load: 400 simultaneous users

The results:

          Redhat 8 (-Xms256 -Xmx256) Redhat 9(-Xms256 -Xmx256)
Jvm1.4.1 80 req/s 199 req/s
Jvm1.4.2 88 re/s 204 req/s

Interesting, in the machine with Redhat 9 the results are quite similar...

Just for fun, I used the +XX:Aggressive in the machine with Redhat 9. The results:
Jvm1.4.1: 194 req/s
Jvm1.4.2: 170 req/s

But, anyway, I don´t think Aggressive must be used with this low-end hardware, so this results are useless...

What do you think?? It seems that Jvm1.4.1_03 also supports the NPTL. Anyway, I think the JVM depends on the system thread implementation. It’s abstracted, thus, in theory, any Jvm would perform better with Redhat 9, am I right?

Andre

I forgot the test run length: 10m

Andre

I am afraid you have tested Application,JBoss,Jetty,Oracle, JDBC Driver, ... your network, but not the JVM.

"I am afraid you have tested Application,JBoss,Jetty,Oracle, JDBC Driver, ... your network, but not the jvm."

Well, everything you said was equal. Only the operational system was different. My reasoning was that the 1.4.1_03 also supports NPTL threads in Redhat 9, not only 1.4.2, as Sun implies.

Regards,

Andre

This is not entirely true!

Just read “Redistribution of Java 2 SDK Files” section of the JRE’s README.txt. It clearly states that one can include all the files needed for the compilation support with the JRE’s redistributable.

Artem

Just read “Redistribution of Java 2 SDK Files” section of the JRE’s README.txt. It clearly states that one can include all the files needed for the compilation support with the JRE’s redistributable.

Does this allow redistribution of the SDK's tools.jar?

Yes!

Artem

Comparing the comments from the bug parade with the StringBuffer in src.jar that comes with j2sdk1.4.2 it looks like the bug is fixed.

I'm still waiting for the 64-bit JVM on Linux / Windows on Opteron support.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Is that jupdate scheduled, "i wanna be like windows update" crap piece of software still in there? i hope not...

anyone seen the Volano report?

http://www.volano.com/report/