Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
User-Agent: Microsoft-Entourage/11.0.0.040405
Date: Wed, 11 May 2005 20:06:40 -0700
Subject: Re: Harmony goals and priorities
From: Bob Griswold <bgriswold@terracottatech.com>
To: "harmony-dev@incubator.apache.org" <harmony-dev@incubator.apache.org>
Message-ID: <BEA81650.68D%bgriswold@terracottatech.com>
In-Reply-To: <F02EAE07A561584D92034BA84EE601239739BB@eduau-exch.eduau.local>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

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 i=
s
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 wi=
th
> their JVMs?
>=20
> 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.
>=20
> Nick=20
>=20
>> -----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
>>=20
>> Karen:
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> Bob
>>=20
>>=20
>> On 5/11/05 6:18 PM, "Karen Bennet" <bennetkl@yahoo.com> wrote:
>>=20
>>>=20
>>> Bob, I share many of your thoughts on this topic and thank
>> the Apache=20
>>> team for getting this project kickstarted.  There have been
>> some of us=20
>>> 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. =20
>>> I would like to highlight one of Red Hat's goal in working
>> with this=20
>>> community project is to get a JRE deeply integrated within
>> Linux.  We=20
>>> also have another goal in mind for this project and that
>> integration=20
>>> with SystemTap (Linux profiling project :
>>> http://sourceware.org/systemtap) which enables performance
>> profiling=20
>>> through the JVM.
>>>=20
>>> Looking forward to this project moving out of the incubator stage.
>>>=20
>>> --- Bob Griswold <bgriswold@terracottatech.com> wrote:
>>>> I ran the JRockit product group at BEA for the last
>>>> 3.5 years =AD from the
>>>> time BEA first bought the Appeal team in Sweden until
>> about 3 weeks=20
>>>> ago (I=B9m now at a small start-up doing some interesting
>> things with=20
>>>> AOP). I am excited about this project, but also a bit
>> skeptical about=20
>>>> it=B9s chances for success. The overall goal of
>> =B3harmonizing=B2 the JRE
>>>> landscape is exactly what the industry needs =AD it=B9s something that
>>>> BEA should have tried to do with JRockit long ago. The
>> Java runtime=20
>>>> is not something that any one company should own and rely on for
>>>> competitive advantage =AD it=B9s a commodity/utility, and our ultimate
>>>> enemy is the CLR. The Microsoft community has one managed
>> runtime to=20
>>>> target, while there are at least 3 credible JRE=B9s in the
>> Java world,=20
>>>> each of them are different in hundreds of tiny ways =AD
>> despite passing=20
>>>> a rigorous JCK.
>>>>=20
>>>> If harmonizing the JRE landscape is goal #1, then goal #2
>> is to have=20
>>>> this JRE be open sourced =AD so that it can be deeply
>> integrated with=20
>>>> Linux. M$FT is integrating the CLR deeply into Windows =AD
>> managed code=20
>>>> 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.
>>>>=20
>>>> In my experience trying to unseat the de facto standard
>> JRE (HotSpot)=20
>>>> for the last 3 years, any JRE that wants to be credible
>> and used must=20
>>>> satisfy a set of =B3competitive qualifiers=B2 just to be in
>> the game, and=20
>>>> must have at least some major =B3competitive differentiators=B2 to get
>>>> people to make the
>>>> switch:
>>>>=20
>>>> COMPETITIVE QUALIFIERS:
>>>>=20
>>>> 1. Must be 100% Java compatible. All of the
>>>> services/API=B9s/functionality people are talking about here are
>>>> absolute minimum requirements. A JRE must pass the JCK 100% - any
>>>> =B3forking=B2 will only serve to further fragment the non-M$FT
>> world, and=20
>>>> we can=B9t afford for that to happen 2. Must be pressure
>> tested/bullet=20
>>>> proof. No one in the real world wants to debug their own JVM. You
>>>> won=B9t 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
>>>>=20
>>>> 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=20
>>>> 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 =B3weaving=B2 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=20
>>>> more likely we are to have conflicts =AD the =B3multiple
>> agent=B2 problem=20
>>>> 4. Clustering/resource management: Another area that the
>> Java Runtime=20
>>>> should naturally own.
>>>>=20
>>>> 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=20
>>>> major vendors out there who are investing a great deal in
>> duplicate=20
>>>> 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=20
>>>> of success. I=B9ll be excited if BEA opens up the JRockit
>> source base=20
>>>> and backs this project, or if IBM does the same with J9,
>> or ideally,=20
>>>> both.
>>>>=20
>>>> Bob
>>>> --
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> __________________________________________________
>>> Do You Yahoo!?
>>> Tired of spam?  Yahoo! Mail has the best spam protection around
>>> http://mail.yahoo.com
>>=20
>> --=20
>>=20
>>=20
>>=20
>>=20
>=20
>=20
> IMPORTANT: This e-mail, including any attachments, may contain private or
> confidential information. If you think you may not be the intended recipi=
ent,
> 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 inte=
nded
> 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 wi=
th it
> for viruses or any other defects.
> education.au limited will not be liable for any loss, damage or consequen=
ce
> caused directly or indirectly by this email.

--=20