Without even a peep from big blue, it has been reported that IBM has released a beta version of the 1.5.0 JDK. This technology is reported to include many optimizations found in both the compiler and the run time. These optimizations include the currently hot topic of escape analysis.

Is the impressive list of performance improvements incentive enough to make you want to kick the tires on this release or is this release (now 4 minor releases behind Sun’s JDK) too late to peak your interest.

I am sure its worth a pique. ;)

Even MAC OS X released 1.5 quicker than their normal effort.

With Mustang corraled and Dolphin about to learn new tricks it would appear IBM should put more resoruces on this effort.

One could question their commitment, eh!?!

A good year or so late. Which means that it will be what, 2nd quarter or so 2006 before it is part of their server distributions? Which means that it will be another year before wide adoption. Meanwhile JDK 7 will probably be in beta...

I guess you'd need to take a look to see if the features it provides are worth the wait. Remember, not are JDKs have the same level of features.

This release is much more than a simple "port" of Sun's VM. They seem to have pulled all stops to make sure J9 is as good, if not better than jrockit and sun. Being sun-ip free means they have leverage over the others when it comes to the licensing model. The question of the class libraries is a different issue but let's give credit where it's due.

Again, there is no "official" download for win32 version. They probably put it under some WebSphere or WebSphereMQ package...

This is good news. We deploy on several platforms - IBM AIX being one of them. Currently we have to develop/build on JDK 1.4 because we have to use the 1.4 JDK when deploying to AIX. Even though we deploy on 1.5 for Solaris and Windows, we have to write code to the lowest common denominator.

IBM releasing a 1.5 JDK means that we'll finally be able to develop and build with the 1.5 platform. We'll certainly kick the tires on this release.

IBM make their own JRE? What features do they have that the base JRE does not?

_That_ software they own. I guess being IBM they are not comfortable with someone else owning the JVM. What they really want is to remove control of Java from Sun, and the first step is to have a clean-room implementation.

If you read it... it has Harmony.

.V

IBM make their own JRE? What features do they have that the base JRE does not?

AIX. Who else is going to write a VM for AIX. I believe that they also have it running on mainframes under VM (the OS) and/or Linux.

Kinda cool when you think about it...

The OS is branded Z/OS these days (goes with Z-series hardware). Not only do they have a mainframe version of the JVM, you can add processors optimised for, and dedicated to, running only Java. It's not cheap but performance is cool.

The OS is branded Z/OS these days (goes with Z-series hardware). Not only do they have a mainframe version of the JVM, you can add processors optimised for, and dedicated to, running only Java. It's not cheap but performance is cool.

...is definetly not cool. A "regular" mainframe is horribly expensive, but runs Java _extremly_ bad. We have tried to run WebSphere on zOS for an extended period of time (because IT department think of Mainframes as the ultimate hardware) and failed in terms of performance. A single Wintel (2,4GHz 1-2 GB RAM) smashes a Mainframe on standard J2EE applications.

To get minimum acceptable performance on zSeries, you have to have at least 3-4 dedicated processors (z900). The new hardware (z9) is faster (the CPU is faster), which means that you can less CPU with same MIPS. But then the situation for Java gets even worse, because you need many CPUs that can run i parallell. The zAAP (Java co-processor) is just a standard zSeries CPU, dedicated for Java. It does not affect the total MIPS of the machine, but its not fast at all. Its also only possible to have 1 zAAP per regular CPU.

My experience with Java on zSeries is just horrible, so until IBM puts some of its decent Power processors in them, I would warn everyone against this plattform. (Its not better running Java/WebSphere on zLinux, same hardware)

That ends my Java/zSeries bashing of the day :-)

My experience with Java on zSeries is just horrible, so until IBM puts some of its decent Power processors in them, I would warn everyone against this plattform. (Its not better running Java/WebSphere on zLinux, same hardware)That ends my Java/zSeries bashing of the day :-)

1) How old is your mainframe?

2) Adding powerpc cpus doesn't make sense to me. You are better off using Linux on Power then.

How old is your mainframe?

Performance-wise, the current "Z" is the equivalent of a P3-800Mhz. Never buy a mainframe for performance.

On the other hand, the Z will have a one-bit memory error only once every 358 years (or something like that). If you need the highest levels of RAS (Reliability Availability Serviceability) then the mainframe is quite possibly the best choice.

Peace,

Cameron Purdy
Tangosol Coherence: Clustered Coherent Caching

As many of you might now, the SUN x86-64bits versions of their JDK contain a bug which happens to be triggered by the populair IDE Eclipse. Because of this, users of x86-64bit platforms need to resort to an alternative JDK when running Eclipse. (the other option is to disable JIT, but this slows down the machine to such a degree that it can hardly be considered an option)

If the IBM JDK comes out in a release version before SUN comes out with the release version of Mustang* (probably, Mustang is still a good year away), then this might be attractive for x86-64 users that wish to run a JDK5 platform.


*
Sun is not going to fix the bug in the current major version of their JDK, since it involves using another version of GCC for the compilation. Sun's policy is to only change GCC for major revisions. Therefore, the current bug can only be fixed in JDK6, not 5.

As many of you might now, the SUN x86-64bits versions of their JDK contain a bug which happens to be triggered by the populair IDE Eclipse. Because of this, users of x86-64bit platforms need to resort to an alternative JDK when running Eclipse. (the other option is to disable JIT, but this slows down the machine to such a degree that it can hardly be considered an option)If the IBM JDK comes out in a release version before SUN comes out with the release version of Mustang* (probably, Mustang is still a good year away), then this might be attractive for x86-64 users that wish to run a JDK5 platform.*Sun is not going to fix the bug in the current major version of their JDK, since it involves using another version of GCC for the compilation. Sun's policy is to only change GCC for major revisions. Therefore, the current bug can only be fixed in JDK6, not 5.

Can you point to some information on this bug?

I am lucky I use Emacs.

As many of you might now, the SUN x86-64bits versions of their JDK contain a bug which happens to be triggered by the populair IDE Eclipse.
[...]

Can you point to some information on this bug?

There are many reports about this problem. The one below is one of the official bug reports about this issue on the Eclipse site:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=71987

I am lucky I use Emacs.

Damn you are! ;) But seriously, do you mean because it's not running on Java or because Emacs is just great?

If the first is true, the bug I mentioned is in the SUN JVM, not in Eclipse itself. Eclipse just happens to trigger it. You can take a look at the Eclipse source in question yourself. It doesn't contain any out of the ordinary constructs.

First, congrats to IBM for getting this release out!

Regarding Eclipse - if it's a JVM bug, then chances are it is not triggered using IBM's VM. Another workaround would be the 64-bit version of BEA JRockit, which has been out for almost a year for Linux (the Windows version in due in a month or so).

Can you point to some information on this bug?I am lucky I use Emacs.

I think it is the bug 5060628
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5060628

Sure, Sun should upgrade to a newer GCC but that could break other things relying on them sticking to the current GCC with Java 5. I can understand them waiting until Java 6 for this -- which is out in decent betas anyway...

I'd say Eclipse has a bug in that it uses native code that relies on GCC versions when it should just be pure Java code -- thus avoiding any GCC versioning issues.

Seriously, any GCC usage can lead to horrible version conflict issues. It's best to avoid native code when possible and just use Java.

NetBeans would be a good option :-)

Ooops. I see that this bug appears to be triggered by Eclipse's Java, not native code. That would seem to be a reason for Sun to figure out a workaround even if they can't change GCC versions.

Well,

Lets just hope they fixed the quirks and problems in their ssl implementation in this one then....

Greetz
Leo

Hi all,

Is there a comparison between Sun's & IBM's SDK (website/ article)? This would be a great benifit for me.

Plus is IBM's 1.5 comparable to all the bug fixes Sun has done (i.e all 5 releases Java 1.5.0_05).


TIA