harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Griswold <bgrisw...@terracottatech.com>
Subject Re: Harmony goals and priorities
Date Thu, 12 May 2005 03:28:43 GMT
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" <nlothian@educationau.edu.au> 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:bgriswold@terracottatech.com]
>> 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"
>> <nlothian@educationau.edu.au> 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:bgriswold@terracottatech.com]
>>>> 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" <bennetkl@yahoo.com> 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 <bgriswold@terracottatech.com> 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.

-- 




Mime
View raw message