harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From FaeLLe <mrbillcollec...@gmail.com>
Subject Re: Harmony goals and priorities
Date Thu, 12 May 2005 03:35:42 GMT
You just convinced me to try out JRockIt !!

On 5/12/05, Bob Griswold <bgriswold@terracottatech.com> 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" <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.
> 
> --
> 
> 


-- 
www.FaeLLe.com <http://www.FaeLLe.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message