harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karen Bennet <benne...@yahoo.com>
Subject Re: Harmony goals and priorities
Date Thu, 12 May 2005 01:18:59 GMT

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 

View raw message