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: harmony-dev@incubator.apache.org > 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: harmony-dev@incubator.apache.org > >> 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.
