Slashdot Mirror
Java 2 & Hotspot on Linux in 2000
djKing wrote to us with the news that
Sun will be releasing a "Java2-compliant JVM for Linux that brings the performance, functions, and Java HotSpot
features of the latest Java specifications to the Linux community", which will be announced at the Java Developers' Conference. As well, IBM will be announcing the free general availability of a JSDK 1.18-compliant JVM, with performance better then that of Windows NT JVMs.
Tim is an avid fan of Perl. When he teaches XML to his classes he teaches to parse it in Perl first, and maybe Java later.
,hacker Perl another Just)'
James Clark writes about 50/50 in C and Java.
When you say "[Java] certainly isn't slower than Perl/PHP/CFML/etc" you are actually saying "[Java] certain is faster than Perl/PHP/CFML/etc" (just reverse the "isn't slower" into "is faster"). That's not the experience I and a lot of companies I've consulted for have had. YMMV.
perl -e 'print scalar reverse q(\)-:
Matt. Want XML + Apache + Stylesheets? Get AxKit.
First, to those who think Java is closed, let's get it straight, Java is open...Suns _implementation_ of Java is closed! Anyone can download and implement the Java spec...as several have. And Sun is at least attempting to achieve some consensus and standardization for what they create, which is a hell of a lot better than most other companies (how many people did MS ask for input on, say, DCOM???).
Sun's implementation of the spec may be closed, but it is still more open than a lot of other closed software. Their community source licence, if not that great, is at least a step in the right direction, and if other companies took this step, we would be decidedly better off. It takes time for the corporate world to embrace, understand, and experiment with open software...Sun is heading it the right direction. Keep in mind, they have to make money to survive. Eventually, given the same time C/C++ has had, there will be many good open implementations.
Java being an open specification, with independant, and open implementations, makes it as open as anything else in this world. Just because there are closed implementations, doesn't make Java closed. If Sun started charging $10,000 for their Java implementation tomorrow...what would happen? The whole community would start working on Kaffe, and you can bet IBM (with all they have invested) would do a cleanroom and open source it, but basically, life would go on without Sun. What would all the Visual Basic programmers do if MS started charging $10,000 for VB? Look at how many people use VB! (Don't even get me started on comparing them)
As for Java changing "every five minutes" as some people like to quote, or about it being unstable and buggy. Well, that's true, or at least it has been in the past. But Java is a really new language!!!! I'll say it again...it's new! Java, like Linux in some ways, has been pushed into the spotlight before it's time, because it fills the need better than any of the alternatives. I think Sun has done a great job of moving the languages features forward quickly enough that MS can't hijack it by adding missing/needed features that will in turn tie Java to Windows. Being a full time Java developer, I could never go back to C++/Win32, despite the bugs, and a _few_ missing bits here and there, Java is a _great_ language to work with. Stability and speed, and more open implementations, these will all come with time. Actually, Swing is becoming useable, and the new JIT's are actually quite fast on "reasonable" hardware.
Java is just now really starting to become a viable platform. Linux is in the same vote, it's a relatively new operating system, and is still evolving at a pace at least as quickly (or more) than Java in areas such as multimedia, multitrack digital recording, DVD, USB, component architectures (KOM/Open Parts), etc.
Most importantly, Java is the only real chance Linux has of putting down windows in the enterprise. Even once all the productivity apps are in place on Linux, and the interface (Gnome/KDE) blows away Windows, and it's easy enough for grandma to install, the MS installed base is going to be the problem. Java gives companies a way to easily migrate from Windows to Linux. Java is the link that will let this happen. Normally, convincing a MS based company to develop their inhouse software on Linux would be impossible. But Java is a good language for _MANY_ other reasons than being cross platform, which will get companies to use it, even if it's only on top of Windows. Then one day, when they discover Linux, they will find that they can slowly (or quickly) throw away their Windows boxes without spending a trillion dollars migrating a myriad of software all at once. Without Java, it will never happen.
That is why Linux and Java are a good match.
I know there are some serious problems with native threads on anything less than kernel 2.2 and glibc 2.1.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
My issue with the Blackdown port is that, beautifully compliant as it is, it lacks a JIT compiler. My benchmarks make the Kaffe JITC about three times as fast as the Blackdown JDK's interpreter. I consider interpreted Java unusable -- making my computer three times slower (at least) than it should be is not acceptable.
I'm withholding judgement on JITC'd Java as I haven't found at JITC that will run everything. Kaffe will run my little toy tests, but it dies when trying to run a real app like NetBeans (which is apparently pretty evil, they recommend not running with a JITC). NetBeans under the interpreter runs like it was on a 386. I just downloaded the IBM JDK 1.18. I'd really like to port some Java stuff to C++ and compare for speed. Anyone know of any similar benchmarks that have already been done?
As I am currently employed in my second job involving a large scale java server application, I can say without a doubt, yes, yes, most emphatically yes, people write real software in Java.
Sometimes we have regrets, but I had those in C and C++ too. On the whole, java has been a great step forward. It could be a heck of a lot better but it is more than usable right now.
Such as
Didn't think so...
Seems to me that multithreaded Java apps seem to scale pretty well just from throwing more and faster processors at them as long as you're actively using multiple threads, from a single-processor laptop for development to a dual-processor Linux box for testing to a multiprocessor Sun for deployment it's pretty linear.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
Technically, the Volano tests were conducted on Kaffe 1.0b4, not 1.05. Among the release notes, Kaffe claims the new JIT "improves raw execution speed by a factor of up to 3". It also uses native Linux pthreads, which should be beneficial to real-world multithreading. And then benchmarks are benchmarks... "benchmarketing" should be avoided on both sides.
At any rate, given significant changes to the JVM and threading model, the Volano results aren't totally applicable.
---
Maybe that's just the price you pay for the chains that you refuse.
Hand me that airplane glue and I'll tell you another story.
Oh, and - It's about freakin' time :)
-----------
"You can't shake the Devil's hand and say you're only kidding."
Transvirtual and the Kaffe Core Team have released Kaffe 1.0.5 (finally!). It's got a new JIT, new processor ports, a clean-room RMI implementation, kernel threads, and much more. For more information see http://www.kaffe.org/
Transvirtual Technologies, Inc. today released Kaffe OpenVM 1.0.5, the only complete Java implementation available with a true Open Source license.
The release heralds a major improvement in the reliability and performance of open source Java implementations. Tests conducted with various Open Source server side Java applications, including the popular Apache/JServ webserver and the Enydra Java/XML Application Server, demonstrate Kaffe out performs its Java Linux rivals by as much as 300%. Kaffe also proves more reliable than other Java implementations which simply hang when running under heavy load.
Transvirtual targets Linux as their primary server-side, desktop and embedded environments. Kaffe, developed using the Open Source model, once again demonstrates how Open Source can offer a better, cheaper, faster and more reliable product than proprietary alternatives.
This new release of Kaffe also offers a number of new features, including:
* Bundling of the KJC Java compiler from Decision Management Systems (http://www.dms.at/kopi) - a complete JDK 1.2 Open Source compiler suite.
* A complete Remote Method Invocation implementation written in collaboration with the GNU Classpath project (http://www.classpath.org).
* Support for the the popular Cobalt Network Web Servers.
* Support for the MIPS and StrongARM processors (Kaffe already supports Pentiums, Sparcs, Alphas and Motorola processors).
For more details on Transvirtual Technologies see their web site.
For more details on the Kaffe Open Source Project see The Kaffe Project Web Site.
All names and trademarks are the property of their respective owners.
Bruce Perens.
End-of-Thread
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
Can you post the input data too? And the perl version? It's trivial to make modifications to this Java code to speed it up by 5-10 times.
This code doesn't prove anything about Java's execution speed. It just proves that buffered I/O is more efficient than reading a byte at a time.
Any Java programmer who has more than a few months experience will immediately spot the
problems.
1) Doesn't use buffered I/O at all. A trivial one line fix adding either BufferedReader or BufferedInputStream would boost speed tremendously.
2) Usage of StreamTokenizer on an interactive stream. A bug in JDK1.0-1.2.1
http://developer.java.sun.com/developer/bugPara
3) Usage of synchronized Vector and Hashtable operations instead of ArrayList and HashMap.
4) Usage of StreamTokenizer! Use BufferedReader and indexOf() or StringTokenizer instead.
Like Linux vs NT, let's not post "cooked" or "biased" benchmarks. The only real way to run these sorts of benchmarks is to have a contest between C++, Java, Pyhton, Perl, and C coders, and have the final result judged on speed of execution, speed of development, clairity, and ease of reuse and maintainability.
In terms of academia and research, if you look at the IETF and W3C, almost all "new" protocols start out with Java prototype implementations. This is particularly true of the W3C. Jigsaw, XML, XSL, P3P, SVG,
If you look at commercial websites, E-Trade and Datek come to mind, you'll see Java on the backend.
My own free pop/webmail/antispam service msgto.com) uses Java for everything, JSP, servlets, SMTP, POP server, etc. It's also
faster and more responsive than Hotmail.
Yesterday, two spammers took "revenge" on our site by redirecting spam bounces to my site. In a
10 hour period, about 1 million bounced messages were received and discarded on a lowly dual-processor Solarisx86 box. Even now, we are getting about 10 messages per second but 'top' shows only 10% CPU utilization for the JavaVM and 30M memory used. Java definately scales.
Solarisx86 was used for only two reasons. One, when development was started, JDK1.2 wasn't available on Linux, and our servers use JDK1.2 heavily for its new garbage collection/memory management features and fine grained security.
Second, Solaris can scale to thousands of threads across multiple processors. Only TowerJ on Linux allows massive numbers of threads (by not using kernel threads), and Java's I/O mechanism relies on launching large numbers of threads. But TowerJ is not JDK1.2 compliant: bummer! Otherwise, I would love to have a bunch of rackmounted VA Research boxes.
The only place Java really failed was on the desktop application area. But I'm of the opinion that the general trend is that we are moving away from desktop applications and more towards web-based applications. So in a sense, most new desktop apps will fail, regardless of the programming language they are written in, and especially those that try to compete with areas Microsoft dominates. When was the last "killer-gotta-have-it-client-side app created" I can't think of many besides games, browsers, and other multimedia related utilities.
In the past, if you wanted to manage an address book, or a database, someone would ship you a VB or some other 4GL based app, that displays forms on your desktop and inserts them into the DB. Nowadays, most of these apps can be done on the network. This covers most business uses.
What's left for the desktop apps is multimedia. Music, Games, animation, art.
This Sun/IBM announcement is great news. I only wish that IBM would come out with a JDK1.2 compliant VM, because IBM seems to be alot better at optimizing VMs.
-Ray
It continued to be such a joke and a failure on the client side for so long that they had to play up this server side story for it. They've completely lost sight of what Java was going to do for them.
There was once a coherent strategy in pushing Windows off the desktop in favor of thin-clients, but now, well, it's hard to imagine that you could field a thin-client that could compete with commodity thin-client hardware based on PC components. So, even if, and it's a HUGE if, you could displace Windows (and Linux) on the desktops, you'd still have to talk to PC hardware being used as thin-clients. Seems like a win for Intel or StrongArms maybe, but not for Sun.
So, Sun turns toward the server and middleware for Java dominance. This seems like a move of desparation, to show SOMETHING for their Java investment. If they succeed at flattening the server side with write-once-run-anywhere Java applications, they will have succeeded in commoditizing the server side.
In such an environment, you'll have IBM, HP, Windows NT and some large number of commodity server Java boxes (made in the far east) to compete against. Why would Sun, who have done so well in differentiating themselves on the server side with the best compilers, best RAS, most scaleability want to flatten out the software landscape? It just doesn't make sense from the standpoint of strategy.
Sun is being pulled around by the nose by a Java Strategy that's taken on a life of it's own. They pay $500,000,000 for the world's most popular Java application (StarOffice, which BTW uses C/C++ on the server side) only to give it away apparently in a desparate attempt to legitimize Java on the desktop. They now have to support the development of Java on their biggest up-and-coming competitive environment, Linux, to make sure that the phenomenal growth of Linux doesn't marginalize their precious Java. It seems crazy.
At the end of the day, what large server side applications will be written entirely in Java? All of those systems will have working C/C++ compilers, after all. With C/C++ you should be able to get much greater performance, stability, more immunity to environmental changes, less developmental headaches (no nervously watching evolving Java standards) and more qualified programmers (most good Java programmers are good C++ programmers, but not vice versa).
I can see Java used like stored DB procedures, and for various kinds of utility programs, middleware glue, quick projects, you know, all those things that Perl does quite adequately already, but take over the server side? How? If anybody dares to field a commercial package written in Java, someone else could beat them up with one written in C/C++.
This is the essential point that people don't seem to understand about C/C++. Your operating systems are written in them for a reason. Because your operating systems are written in them, they will always be the most stable and mature compilers available. Because this is true pretty much everywhere, they will be the standard in portability. Maybe not the kind of VM portability where you can compile it here and it will migrate over to execute somewhere else, but what does that buy you over just having good C/C++ compilers everywhere (which you already do, see above).
Java is probably a better language than C++ because of garbage collection alone (and there are other significant advantages), but you need more than just better to displace a truly ubiquitous language like C/C++.
From my perspective, I see far more developers using Java than users for the forseeable future.
When some wide-eyed Java fanatic tries to tell me that everyone will be using Java next year, I'm reminded of the Amway guy who told me 10 years ago that I could be making $90,000/yr. in just 90 days with Amway, much more in 6 months. I told him to go away and come back in 90 days if he was making $90,000/yr. Needless to say, he wasn't. Java was supposed to be really big next year for the last 3 years now. It's getting tired.
Weren't we supposed to be using Java for SOMETHING by now? People using the Hot Java browser, raise your hands! Let's see, it's not good for browsers, nobody would dream of writing an RDBMS like Oracle in it and in the middle, it competes with Perl, Python, C/C++ and Tcl/Tk. Seems like a squeeze to me.
I see where Lotus got out of the Java client business just the other day. Corel got out awhile back too. StarOffice and their free product is not much of a showcase of a vibrant Java marketplace.
Don't point me at Java support in Oracle or Java support in some ORB or another. All of those environments have quite stable and working C interfaces too, thank you. Show me large numbers of users using Java day in and day out. I bet those same users use about 20 times more C/C++ in their OS alone to support this one app. For every one user who is using a Java app today, I'll give you 50 VB/VBA users and 100 users of apps written in C/C++. There may be growth in Java today, but is it like the growth of Linux where almost no Java is used?
I'm not a Sun hater, nor am I anti-Java. I really like Java as a language. I was turned off years ago by it because I didn't want to jump on while they were changing it so rapidly and it seems that it's just now starting to stabilize.
Maybe Java will be really big someday, but I don't see that someday from where I stand.
Before I switched over to all Java development, I was really well versed in C and C++. I once worked on a large product that had the same C codebase that compiled across eight different brands of UNIX systems as well as VAX, VMS, and MPE (Hp3000) systems.
I got to be pretty familiar there with just about every sort of odd cross-platform compatibility problem one could run into.
I also did a lot of C++ work as well, which was great... as long as you use RougeWave collections and DB packages, along with Great Circle or Purify (to make your program stable enough to run without Great Circle).
But there is no way that even at my peak of use of any of these languages, even using Emacs as an editor, that I could approach the speed of Java development. It's not quite as fast as it might first appear as you have to spend a little more time optimizing for performance over other langauges, but you more than make up for the in the stability, portability, readability, and documentation gains you get. I go back to C or C++ when I have to (for instance to write a JNI wrapper for a C or C++ library) but I think you'd have to be mad to try and write some of the software I'm working on now in anything but Java.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I haven't heard anything about GJC (the port of gcc to compile Java and/or Java bytecodes) recently -- isn't it an acceptable alternative to a JIT? On a different topic, has anyone integrated Java with SOAP or XML/RPC? (They're roughly the same thing -- XML/RPC handles RPC in a reasonably portable way, and SOAP extends that to objects in a quite nice way.) -Billy
I don't know. Ask The Hungry Programmers.
Bruce Perens.
K&R C, I can believe. But there are still proprietary OSes out there whose one-and-only compiler doesn't even grok exceptions, and I'd hardly call that impoverished language C++.
This is a troll, right? C and C++ are half-marked minefields, and the industry has spent the last decade or so proving that getting reasonable robustness with them requires such superhuman diligence that you actually get more money if you don't even bother to try.
Ah yes, the joys of DLL Hell.
Instead you can wistfully watch the evolved C++ Standard and wonder which parts your vendors might bother to support.
This is an artifact of C++ having arisen first. Most good C++ programmers have learned Java for the same reason they'd learned C++ - it's better than what they had before. Most Java programmers who didn't already know C++ are too inexperienced to be good (the rest were doing amazing things in Smalltalk instead).
IMHO the notion of code that's married forever to one machine is the next piece of cultural baggage we're getting rid of, and Java (the first widely-deployed language that can safely receive and run untrusted code from elsewhere) will be the centerpiece.
This is absolutely ridiculous. Mr. Perens is claiming that Kaffe is "300% faster" than some competitors without giving concrete benchmarks or even stating who those competitors are. Obviously you can create a loaded scenario by pitting Kaffe with JIT vs. Blackdown with JIT disabled. Even worse is the AC who claimed that Kaffe could be 2x as fsat as HotSpot.w -10-volano.html
For real, 3rd party benchmarks, check out the Volano report at:
http://www.javaworld.com/javaworld/jw-10-1999/j
In terms of speed, Kaffe rated a 389, while IBM's JDK got a 1770. Yup, the IBM kit was more than 4 times as fast. On top of that, Transvirtual doesn't pass Java compatibility tests, so if you develop on their VM, you have no reason to believe that your code will work on a real JVM.
Open source is not necessarily equal to best of breed.
--JRZ
Is that with hotspot installed?
Jilles
I've been doing all Java enterprise work for over three years - at first, it was more R&D work with graphical visualization, but for the past few years I've worked on a number of practical Java programs that were deployed to big telecom companies. One was a big application/applett (it ran as either) that was a replacement for and enhancement of of large Powerbuilder application (and don't tell me the world wasn't made more pleasant by the reduction of Powerbuilder apps in the world by one!). It was an MDI Swing app (using Jdk 1.2), and it had to run on P90's... I won't say it was all that fast on a P90, but on a P166 it ran pretty well. That did require some tuning of course, but in the end it ran pretty well and the client was very happy with the results. That just goes to show that people who talk of Java being useless for apps are living back in 1996.
Now I am working on all server side Java stuff. The whole company is doing almost everything in Java, as are many others.
This is not a flavour of the month kind of event, this has been slowly building for a long time and there looks to be no end in sight. A strong VM on Linux means that at any time, you can swap out that Solaris or HPUX or AIX EJB server for a Linux box if it meets your criteria for the hardware you need. It will be the force that finally shakes loose any doubt of Linux being an equal in the corperate world. It's a shame that Java VM development on Linux has been so slow, but at last we are seeing good progress...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Check out this Java World article for real benchmarks for a variety of JDKs on Intel hardware. The scalability (page 2) is both interesting and disappointing. The numbers on the Blackdown and Kaffe JVMs really show how badly a new JVM is needed for Linux. --JRZ
This is largely in line with comments made by others; that programmer resources are more expensive than hardware in the long run. I also believe that the hardware is so changing so quickly that language decisions made on the basis of performance are generally meaningless within a couple of years.
Few big companies are going to build large multi-user applications from scratch; Java is like the "4GLs" in that they have a huge respository of useful things that are just standard. It is better than the 4GLs in that it is faster and more generalised - and it works everywhere.
It is great to be able to combine the two "obvious" (to me anyway) trends of the future, java and linux.
Just MHO of course.
"Sun is also working with the Blackdown Porting Group to bring Java2 to Linux."
-----------
"You can't shake the Devil's hand and say you're only kidding."
Speaking as a programmer that has been doing a lot of Java development lately, this is very good news. The fact that 'official' Sun blessing has been given to a Java for Linux should help to make Linux more saleable to the PNB types as a Java development and/or deployment platform.
The article really sounded as though there is a pressing need to support Java better on Linux machines, but for some reason I thought the general feeling among Linux users was that Java is slow and not really as useful as traditional programming languages.
I'm wondering if anyone out there uses Java for something useful. Perhaps I sound naive, but I've never seen it deployed beyond annoying applets or slow as molasses games in COS246 (Java Programming) And java support in Netscape seems to be lacking to put it nicely.
I've done some reading about servlets and Jserver pages which seem quite interesting. Does anyone have any experience with them or experience with gnu-jsp?
suns strategy has been pretty consistent since jdk 1.1. Its just that it takes bit longer than they originally expected.
"That's typically what people in here decry - the fact that there is so much hype for so little delivery."
Those people generally seem to be unaware of anything else but applets. One of the reasons there are so many Java products at this moment is because its a profitable business. I.e. people actually buy and use stuff like JBuilder, Visual Age, etc.
You are right that SUN is repositioning Java all the time. They have to because there's a lot changing. A year ago XML was just a spec. Now it's the latest hype. Java is right in the centre providing tools, parsers etc. I don't think that's bad.
Then Jini, I really like the ideas behind that. Its something truly innovative. It doesn't seem to hurt other things in Java so what's your problem with Jini?
"...no tool can satisfy all these diverse needs as easily as Sun would have you believe"
Sun doesn't want you to believe that. They're offering different versions of their JDK now. A standard version, an enterprise version, a micro edition (coming in five flavors if I remember correctly). Each is targeting a different portion of the market.
I'm sorry the world is spinning too fast for you these days.
Jilles
I know a lot of /. readers don't like Java for X, Y, or Z reasons, but this is a really REALLY Good Thing (tm).
The direction middleware (such as application servers, transaction monitors, messaging servers, etc) is going is Java, like it or not (I happen to like it quite a bit). Enterprise Java is getting even more hype in these areas than Linux itself *grin*.
As I've personally just been doing an overview of a systems architecture for a large (fortune 50 or so) company's internal functions, I can tell you that Java support is really holding back a lot of the enterprise middleware products that are available for NT, Solaris, AIX, etc. I had to recommend not using Linux because these enterprise applications are not available for Linux. Hopefully, this move from Sun and IBM's great work on Linux JVM's will help to remedy this situation.
Plus, with the Apache Jakarta code finally having dropped (thanks again Sun!) it will be nice to have a fast, stable 1.2 JVM. I've heard that the Blackdown port is relatively stable, but the Volano benchmarks show it to be relatively slow.
I have this sneaking suspicion that IBM was the motiviating factor in all of this. I work in/around an AS/400 shop (but I am a web designer) and it seems to me that IBM is pushing Java just as fast as it'll go. Additionally, it makes sense for IBM to pursue this route in terms of client independence. IBM really doesn't have a competitive client to push into the market at this point, so by pushing Java to every other platform, they hedge their bets and can sit back and watch the client wars play out while they focus on the Big Iron behind it all without having to worry quite so much about interoperability problems. My guess is that they will drag Sun kicking and screaming along with this plan through some kind of liscensing deal that we may/may not be privy too. Heaven knows that IBM's patent arsenal affects Sun _somehow_
Dojo: defanging browsers so you don't have to
Sun didn't want anyone to change Java, so that it would be a "write once, run anywhere" language. OK, that's a reasonable goal. But they did that by prohbiting anyone but Sun from making changes in Java. They should have done it by establishing a Java standard, with trademarks attached to it and a certification program, instead of casting the software in concrete and prohibiting any innovation by people outside of Sun. And now, they've lost. Their big expensive lawsuit against Microsoft means nothing, because Microsoft simply bought their Java VM from someone other than Sun.
Bruce Perens.
My issue with the Blackdown port is that, beautifully compliant as it is, it lacks a JIT compiler. My benchmarks make the Kaffe JITC about three times as fast as the Blackdown JDK's interpreter.
With Java designed the way it is, it should be a truly no-brainer hack to graft the Kaffe JITC onto Blackdown. If a hack it would be at all. Perhaps the relative hooks in the JITC should be exposed with CORBA, if they aren't already, that is.
Life's a bitch but somebody's gotta do it.
The current 1.2 JVMs for linux aren't really all that good. There are speed problems, functionality problems... a lot of problems. They're certainly not ready for a real deployment in anywhere near a mission critical situation. Fun to play with, but not business ready yet.
Remember that many of the difficulties encountered when porting this around are due to the very SolarisThreading-centric 'reference' implementation provided by Sun -- unless they're willing to do something about that, they're in the same mess that Blackdown/IBM/HP/etc are.
You're special forces then? That's great! I just love your olympics!
The IBM JDK does need a kernel 2.2/glibc-2.1-based machine, but if you're "into" Java, you're going to want to be on those versions anyway for the improved native thread support. (read: "working native thread support.")
We'll have to see how things turn out in a few months regarding a Java2 JDK, but I'd put my money on IBM. Sun's good at talking the talk, but IBM has proved themselves to also be good at walking the walk. (And it seems like the poor Blackdown guys have just been getting the shaft...)
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
Note that it is very much a commercial product and rather pricey IMHO.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
What all that means is, if you wrap a for loop with say 200 iterations around each program, the Java code should be relatively faster per iteration, because after a while the optimisations will trip in - and the initial overheads will be constant, thus less significant.
Female Prison Rape in NY
...and with this new announcement today of a security flaw in Microsoft's VM (haven't seen it posted yet today), it's all the better.