You just convinced me to try out JRockIt !! On 5/12/05, Bob Griswold <[EMAIL PROTECTED]> wrote: > > 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: 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. > > -- > >
-- www.FaeLLe.com <http://www.FaeLLe.com>
