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 02:37:41 GMT

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


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:
>> 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
>> 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


View raw message