Harmony goals and priorities

[Bob Griswold <bg...@terracottatech.com>]

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

Re: Harmony goals and priorities

[Stefano Mazzocchi <st...@apache.org>]

Bob Griswold wrote:

> 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, thanks much for your comments.

As much as this sounds weird, I completely agree with you: without code, 
we are just a bunch people whining.

But let's look at history for a second: do you remember what happen to 
the mozilla codebase when they dumped it into the open? It got rewritten!

Was it that bad? maybe, but maybe not. The need for 'redesign' comes 
from "getting it right this time" (and people already expressed that 
overhere) but, most importantly, because it's very hard to understand 
somebody else's code, especially when built by big groups over several 
years and behind closed doors! (read: without an organic incremental 
growth).

Say BEA donated JRockit and IBM donated J9, both at the same time.

What would we do with it? how much likely it is that people here would 
understand it well enough or be fearless enough to get there and modify it?

I said this once before and got cited by many: "good ideas and bad code 
build communities, the other three combinations do not".

I'm not saying that if some of those vendors showed up, we would turned 
them down, but I have the impression (well, let's say a little more than 
that) that no big vendor will show up until we manage to convince them 
we can get some traction ourselves.

How?

Well, let's glue the pieces together... if you have a (small and lean) 
JVM that you want to see it becoming the seed of Harmony, donate it to 
us, we'll give you commit access and we'll start from there.

Is it in java? even better, a lot more people will be able to help out.

Academic exercise? potentially, but also a way to make seeds grow. And 
no matter how small the seed, it doesn't really indicate how big, strong 
and long lasting the plant is going to be ;-)

-- 
Stefano.

Re: Harmony goals and priorities

[ALEJANDRO GONZALEZ <ag...@NETexplora.com>]

> 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 would add

5. Modularity: The user can choose to use the GCs, class verifiers,
interpeters, etc that (s)he likes. And more, the ability to create
personalized VMs putting together different components, for example a
small footprint VMs for old systems, state of art server VMs, etc...