For a JRE to be usable for a real-life enterprise customer, it has to be a hell of a lot more functional and stable than just passing the JCK. That was the absolute lowest bar of any test we used in JRockit.
The VM is a very, very complicated beast - when you get into multiple GC algorithms, dynamic GC, threading & locking issues, code generation and optimization, debugging & profiling, etc. It is truly a combination of an operating system and a compiler - all dynamic and indeterministic. The class libraries are not easy, of course, but a really good VM, on the order of JRockit or J9 (J9 is a lot more than a J2ME VM nowadays - it is a very good, very high performance JVM now) is a LOT different than just a simple VM that can pass the JCK. Bob On 5/11/05 8:21 PM, "Nick Lothian" <[EMAIL PROTECTED]> wrote: > I would have thought (perhaps naively) that the class libraries are the key > issue here. > > There are a number of reasonably functional Open Source JVMs around. While > they may not have quite the level of features as some of the commercial JVMs > my impression is that they are probably reasonably close to what would be > required to pass the VM part of the TCK. > > However, it appears to me that there is more work required in completing GNU > Classpath - particularly in the Swing area. > > Of course, if BEA would like to Open Source JRockit I'm sure it would find a > appreciative audience! My point is that the class libraries are the thing that > will take the longest to complete. > > (Why is the J9 VM of such interest in particular? Isn't that just the VM IBM > uses for it's J2ME implementations, and don't they have a separate, different > JVM used in their J2SE implementation? Wouldn't that VM be of wider interest?) > > > Nick > >> -----Original Message----- >> From: Bob Griswold [mailto:[EMAIL PROTECTED] >> Sent: Thursday, 12 May 2005 12:37 PM >> To: [email protected] >> Subject: Re: Harmony goals and priorities >> >> Both IBM (in J9) and BEA (in JRockit) own 100% of the JVM - >> the virtual machine - that is just part of the JRE (Java >> Runtime Environment). Both J9 and JRockit are clean-room >> implementations of the virtual machines - this is where the >> biggest "magic" is in terms of performance, manageability, >> stability, etc. You are right to point out that the class >> libraries come from Sun, and while both IBM and BEA modify >> some of these libraries, they are derivative works of Sun's >> IP, so they can't open source those. >> >> Bob >> >> >> On 5/11/05 8:02 PM, "Nick Lothian" >> <[EMAIL PROTECTED]> wrote: >> >>> Does either IBM or BEA own the rights to the class >> libraries that come >>> with their JVMs? >>> >>> I was under the impression that they had simply licensed >> much of the >>> code from Sun. I may be way off there, but it would be good >> to know for sure. >>> >>> Nick >>> >>>> -----Original Message----- >>>> From: Bob Griswold [mailto:[EMAIL PROTECTED] >>>> Sent: Thursday, 12 May 2005 12:08 PM >>>> To: [email protected] >>>> Subject: Re: Harmony goals and priorities >>>> >>>> Karen: >>>> >>>> You and I have shared our thoughts and have seen eye to >> eye on this >>>> for a long time now. It's good to see this project getting >> started, >>>> and it's good to know that you are monitoring this and Red >> Hat will >>>> work to help integrate it deeply with Linux. >>>> >>>> I do still feel strongly that stability and commercial >> hardening are >>>> indispensable here. It would be great to get a BEA or IBM >> to donate >>>> their JVM's to this project - they are mature, pressure >> tested pieces >>>> of software that have had thousands of bugs shaken out of them. >>>> Shaking bugs out of JVM's is very different than shaking >> bugs out of >>>> Mozilla - or even Linux. >>>> JVM's do so many things indeterministically, no amount of >> testing can >>>> replace hundreds or thousands of years of cumulative customer >>>> production hardening. >>>> >>>> Bob >>>> >>>> >>>> On 5/11/05 6:18 PM, "Karen Bennet" <[EMAIL PROTECTED]> wrote: >>>> >>>>> >>>>> Bob, I share many of your thoughts on this topic and thank >>>> the Apache >>>>> team for getting this project kickstarted. There have been >>>> some of us >>>>> who have been attempting to get the commercial >> contribution path in >>>>> place, but todate, different licensing, code integration >> problems, >>>>> company strategic value-add direction, etc have prevented >>>> that path. >>>>> I would like to highlight one of Red Hat's goal in working >>>> with this >>>>> community project is to get a JRE deeply integrated within >>>> Linux. We >>>>> also have another goal in mind for this project and that >>>> integration >>>>> with SystemTap (Linux profiling project : >>>>> http://sourceware.org/systemtap) which enables performance >>>> profiling >>>>> through the JVM. >>>>> >>>>> Looking forward to this project moving out of the incubator stage. >>>>> >>>>> --- Bob Griswold <[EMAIL PROTECTED]> wrote: >>>>>> I ran the JRockit product group at BEA for the last >>>>>> 3.5 years � from the >>>>>> time BEA first bought the Appeal team in Sweden until >>>> about 3 weeks >>>>>> ago (I�m now at a small start-up doing some interesting >>>> things with >>>>>> AOP). I am excited about this project, but also a bit >>>> skeptical about >>>>>> it�s chances for success. The overall goal of >>>> �harmonizing� the JRE >>>>>> landscape is exactly what the industry needs � it�s >> something that >>>>>> BEA should have tried to do with JRockit long ago. The >>>> Java runtime >>>>>> is not something that any one company should own and rely on for >>>>>> competitive advantage � it�s a commodity/utility, and >> our ultimate >>>>>> enemy is the CLR. The Microsoft community has one managed >>>> runtime to >>>>>> target, while there are at least 3 credible JRE�s in the >>>> Java world, >>>>>> each of them are different in hundreds of tiny ways � >>>> despite passing >>>>>> a rigorous JCK. >>>>>> >>>>>> If harmonizing the JRE landscape is goal #1, then goal #2 >>>> is to have >>>>>> this JRE be open sourced � so that it can be deeply >>>> integrated with >>>>>> Linux. M$FT is integrating the CLR deeply into Windows � >>>> managed code >>>>>> will be a first class citizen. Linux should be the same. >> So, this >>>>>> project is exactly aimed at those two goals, so I am >> excited about >>>>>> it. >>>>>> >>>>>> In my experience trying to unseat the de facto standard >>>> JRE (HotSpot) >>>>>> for the last 3 years, any JRE that wants to be credible >>>> and used must >>>>>> satisfy a set of �competitive qualifiers� just to be in >>>> the game, and >>>>>> must have at least some major �competitive >> differentiators� to get >>>>>> people to make the >>>>>> switch: >>>>>> >>>>>> COMPETITIVE QUALIFIERS: >>>>>> >>>>>> 1. Must be 100% Java compatible. All of the >>>>>> services/API�s/functionality people are talking about here are >>>>>> absolute minimum requirements. A JRE must pass the JCK >> 100% - any >>>>>> �forking� will only serve to further fragment the non-M$FT >>>> world, and >>>>>> we can�t afford for that to happen 2. Must be pressure >>>> tested/bullet >>>>>> proof. No one in the real world wants to debug their own >> JVM. You >>>>>> won�t find a Wall Street bank, an airline reservation >> system, or a >>>>>> telco, adopting and using a new JRE unless and until it >> is solid, >>>>>> tested, and stable >>>>>> >>>>>> COMPETITIVE DIFFERENTIATORS: >>>>>> 1. Performance: At least as fast as HotSpot, but faster (on >>>>>> benchmarks that matter to the customer) is always better 2. >>>>>> Manageability/diagnostics: This is an area that JRockit >>>> has invested >>>>>> a great deal in the last few years. Memory leak detection, zero >>>>>> overhead profiling, fast debugging, real-time >>>>>> manageability/diagnostics, etc. >>>>>> 3. AOP: This is an area that has started to get a lot of >> attention >>>>>> lately. >>>>>> The whole idea of �weaving� of code, or byte-code >>>> instrumentation in >>>>>> general, will go away entirely if the JVM handled this. The more >>>>>> commercial products we have out there that instrument byte >>>> codes, the >>>>>> more likely we are to have conflicts � the �multiple >>>> agent� problem >>>>>> 4. Clustering/resource management: Another area that the >>>> Java Runtime >>>>>> should naturally own. >>>>>> >>>>>> I am excited about this project, but I am also skeptical >> about its >>>>>> chances for success. This is not easy stuff, and as long >>>> as we have >>>>>> major vendors out there who are investing a great deal in >>>> duplicate >>>>>> work (Sun, BEA, IBM, HP, etc.), I doubt this project >> will do much >>>>>> more than be a cool academic exercise. We need to get the major >>>>>> vendors and investment (and their existing teams) behind this >>>>>> project, or a project like this, for this to stand much of >>>> a chance >>>>>> of success. I�ll be excited if BEA opens up the JRockit >>>> source base >>>>>> and backs this project, or if IBM does the same with J9, >>>> or ideally, >>>>>> both. >>>>>> >>>>>> Bob >>>>>> -- >>>>>> >>>>>> >>>>>> >>>>> >>>>> __________________________________________________ >>>>> Do You Yahoo!? >>>>> Tired of spam? Yahoo! Mail has the best spam protection around >>>>> http://mail.yahoo.com >>>> >>>> -- >>>> >>>> >>>> >>>> >>> >>> >>> IMPORTANT: This e-mail, including any attachments, may >> contain private >>> or confidential information. If you think you may not be >> the intended >>> recipient, or if you have received this e-mail in error, please >>> contact the sender immediately and delete all copies of >> this e-mail. >>> If you are not the intended recipient, you must not >> reproduce any part >>> of this e-mail or disclose its contents to any other party. >>> This email represents the views of the individual sender, >> which do not >>> necessarily reflect those of education.au limited except where the >>> sender expressly states otherwise. >>> It is your responsibility to scan this email and any files >> transmitted >>> with it for viruses or any other defects. >>> education.au limited will not be liable for any loss, damage or >>> consequence caused directly or indirectly by this email. >> >> -- >> >> >> >> > > > IMPORTANT: This e-mail, including any attachments, may contain private or > confidential information. If you think you may not be the intended recipient, > or if you have received this e-mail in error, please contact the sender > immediately and delete all copies of this e-mail. If you are not the intended > recipient, you must not reproduce any part of this e-mail or disclose its > contents to any other party. > This email represents the views of the individual sender, which do not > necessarily reflect those of education.au limited except where the sender > expressly states otherwise. > It is your responsibility to scan this email and any files transmitted with it > for viruses or any other defects. > education.au limited will not be liable for any loss, damage or consequence > caused directly or indirectly by this email. --
