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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 --
