harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Griswold <bgrisw...@terracottatech.com>
Subject Harmony goals and priorities
Date Wed, 11 May 2005 21:22:45 GMT
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


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.


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