We kicked of a J2SE project today at the ASF. If the Incubator PMC approves, we're on our way. Here's the proposal. Please come and participate.

Project Harmony
==========

Motivation
----------

There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform, and there are many ongoing efforts to produce solutions (Kaffe, Classpath, etc). There are also efforts that provide alternative approaches to execution of Java bytecode (GCJ and IKVM). All of these efforts provide a diversity of solutions, which is healthy, but barriers exist which prevent these efforts from reaching a greater potential.

Proposal
--------

We propose that we create a new Apache project, Harmony, that will achieve the following goals :

1) create a Compatible, independent implementation of J2SE 5
  under the Apache License v2

2) create a community-developed modular runtime (VM and class library)
  architecture to allow independent implementations to share runtime
  components, and allow independent innovation in runtime components

In doing so, we intend to create a broad, collaborative community of contributors, implementors and users of the modular platform specification.

To begin, we propose the following as a basic architectural blueprint as a starting point for our discussion :

     http://people.apache.org/~geirm/harmony.jpg

We will create directly, via inclusion of independent third-party code, or through contribution :

a) a freely implementable specification of a modular VM
  and class library that allows for multiple, independent
  implementations

b) a test suite for interoperability testing of the modules

c) an implementation under the Apache License of the modular VM

d) a class library under the Apache License compatible with
  the J2SE 5 specification that implements the defined interfaces

We will start with this mechanism because we desire to :

- have a simple plan upon which coding can immediately begin

- ensure that we have a focal point to begin the conversation
  among interested members of the community

- have a clearly defined set of technical needs to allow
  potential contributors, either code contributors or
  individual participants, a basis for consideration

- ensure that this is a community effort - together we will
  architect and implement via fresh new code or donation

- produce a set of specifications/designs allowing multiple
  interoperable implementations that allow for sharing,
  extension and innovation

We propose that the following people are considered the starting participants. This set represents members from across the community, this diversity a factor we wish to start with and preserve as we grow.

These individuals have expressed an interest in participating in the architecture and design work. The information in parenthesis indicates other community participation or relevant experiences of that individual :

  Guy Churchward (individual w/ commercial VM experience)
  Joakim Dahlstedt (individual w/ commercial VM experience)
  Jeroen Frijters (IKVM)
  Geir Magnusson Jr. (Apache)
  Ricardo Morin (individual w/ commercial VM experience)
  Georges Saab (individual w/ commercial VM experience)
  Bruno Souza (SOUJava)
  Davanum Srinivas (Apache)
  Dalibor Topic (Kaffe)
  Tom Tromey (GCJ)
  Weldon Washburn (individual w/ commercial VM experience)
  Mark Wielaard (Classpath)

and the following individuals have expressed interest in participating as committers for the Apache-licensed implementation :

  Jeroen Frijters (IKVM)
  Ben Laurie (Apache)
  Geir Magnusson Jr. (Apache)
  Ricardo Morin (individual w/ commercial VM experience)
  Bruno Souza (SOUJava)
  Davanum Srinivas (Apache)
  Dalibor Topic (Kaffe)
  Tom Tromey (GCJ)
  Weldon Washburn (individual w/ commercial VM experience)

These individuals will participate as Incubator Mentors :

  Noel Bergman
  Ben Laurie
  Geir Magnusson Jr.
  Stefano Mazzocchi
  Sam Ruby
  Leo Simons
  Davanum Srinivas

The following Apache Members will be the sponsoring members :

  Noel Bergman
  Jason Hunter
  Ben Laurie
  Ted Leung
  Geir Magnusson Jr.
  Stefano Mazzocchi
  Sam Ruby
  Leo Simons
  Davanum Srinivas

The following community members support this effort :

  Danese Cooper
  Brian Goetz
  Doug Lea
  
Operating Considerations
------------------------

0) We have established a list for discussions. Unless your comment is directed to the general Incubator community or the Incubator PMC, please post everything to :

    harmony-dev at incubator dot apache dot org

You can subscribe by sending an email to

    harmony-dev-subscribe at incubator dot apache dot org

Until this proposal has been accepted by the Apache Incubator PMC, these lists are provisional.

1) Due to the various known and unknown risk factors of this project, we propose that in addition to the required Individual Contributor License Agreement (ICLA) we shall require that any committer to Harmony will have a Corporate Contributor License Agreement (CCLA), when appropriate, on file with the ASF Secretary, and will keep that document current with respect to current employer to preserve committer status. We do this in order to help protect the community, both contributors and users, from unauthorized incorporation of code or other intellectual property.

2) Historically, there has been wide exposure to VM and class-library-specific source code that is the property of Sun Microsystems as well as others, as it is common for commercial J2SE implementations to be based on licensed Sun code. We wish to make every effort to ensure that the licenses and rights of external projects and efforts is properly respected. To that end, we will explore additional ways to work with the Apache Incubator to ensure that all IP is carefully monitored and tracked as it enters the project.

Geir,

What *exactly* will the relationship to the GNU Classpath be ?
Is the GPL-with-exception license of Classpath compatible with the ASF licensing ?
I do hope that this ASF initiative will be able to use it, it would be a terrible failure of the OS not to...
Thanks in advance for your comments.

Radu-Adrian :

Geir,What *exactly* will the relationship to the GNU Classpath be ?Is the GPL-with-exception license of Classpath compatible with the ASF licensing ?I do hope that this ASF initiative will be able to use it, it would be a terrible failure of the OS not to...Thanks in advance for your comments.

GNU Classpath is a separate project. One of the reasons we kicked things off in the Apache Incubator was to explore what we can do together.

-geir

There's no way distribute GPL code under the ASF licence, I think they won't use anything from the Classpath project.

Is the intention to be innovative ( create an environment for experimentation ) in the implementation or conservative ( just get something working in the shortest timeframe ).

I was interested in using genetic algorithms to tune JVM instructions/performance.

There is also a pure java JVM called joeq, you may want to get the author of that software involved.

microsoft tried to fork java. is ibm trying the same thing using a different route? ibm and apache have had many ties. ibm has made it known that it would like to "own" java in the past. with sun making the source available and some reports of success regarding non-sun employee fixes making it into sun's code base, i have to wonder who is really behind this and why? and what about indeminfication? sun was sued by kodak over claims that java was infringing. the only company i know that would pick up this project and indemnify it for corporate use would be ibm. and, if you don't need such a high degree of license freedom, obviously gnu classpath exists. sounds a bit suspicious...

always read the full story before posting... my bad

intuitively I would say BIG NO

i believe in diversity etc, but with respect to JVM i'm all
for dictatorship

so - good luck...will jump bandwagon later

Now that Sun are selling commodity x86 boxes, they cant afford the old margins. They cant afford to focus on obscure problems, or things they dont care about.

you can see that: JNI overhead is too high, java.net HTTP client is still brain dead, linux desktop integration still hit and miss.

We need an OSS impl so that java survives, so it stops being seen as just-another-single-vendor runtime, like Visual Basic. Harmony could be it. Its interesting though: imagine being able to ship a customised JVM for your app. That is, not just your own JRE, but a custom JVM just for your project. That is a power we could use, at times.

An extraordinarily ambitious project, but regrettably it isn't going anywhere without mad corporate support.

The last time some talented guys decided they were going to build a core piece of Java infrastructure out of their garage, it didn't turn out quite as well as planned.

I believe that's completely untrue.
GNU Classpath and affiliated projects have come a really long way. Also having native compilation for Java kicks ass !

Corby Page :

An extraordinarily ambitious project, but regrettably it isn't going anywhere without mad corporate support.

I think that this is an accurate assessment. There's nothing wrong with that - this is (if approved...) an Apache project, and thus everyone is welcome to participate and contribute.

The last time some talented guys decided they were going to build a core piece of Java infrastructure out of their garage, it didn't turn out quite as well as planned.

LOL. Hey, we're been in the focused TCK testing stage for a while now, believe we are feature complete, and definitely see the end is in sight. I think that we have a great thing going there in Apache Geronimo. But of course, you aren't surprised that I'd say that :)

-geir

Geir,
Are you going to reimplement the standard library? What
about compatibility issues if people have invested a
lot in workarounds for long pending issues - is this
browser nightmare all over?

Thanks
Ricky

And they will copy buggy implementations just for "conformity" with Sun's VM?

It's better try to patch the code as people are already doing than to use broken implementations.

I don't see any "browser nightmare", we can't compare the bizarre IE's CSS implementations behaviours with some bugs from Sun's VM, 'cos we have lots of alternative VMs.

And they will copy buggy implementations just for "conformity" with Sun's VM?It's better try to patch the code as people are already doing than to use broken implementations. I don't see any "browser nightmare", we can't compare the bizarre IE's CSS implementations behaviours with some bugs from Sun's VM, 'cos we have lots of alternative VMs.

You are mixing VM and classlib. I'm only talking classlib.
How long is the transition period aka "two buggy classlibs"
going to be? Whom do you expect to switch/test it (Corby
Page: "mad support"), while Suns is still better? I'd rather
see Scott McN hand over current source a minute before Suns
death as a "last good act" <- knowing that, evil me would
say please die Sun, die soon ;)

and building Linux wasn't "extraordinarily ambitious?"

and building Linux wasn't "extraordinarily ambitious?"

At the time, no. It's turned out to be a bit more than Linus envisioned, but it did so with the help of many hands and the "borrowing" of many other projects. While everyone calls the OS "Linux" nowadays, Linux used to just be a kernel, much of which was made up of code borrowed (legally) from FreeBSD.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

I though Sun weren't going to open source Java. Is this an attempt to circumvent that or a pre-emptive strike?

Richard F :

I though Sun weren't going to open source Java. Is this an attempt to circumvent that or a pre-emptive strike?

Neither. Sun can do what it wants with it's property :) so I don't consider this "circumvention".

We think that there are good reasons to have an open-source J2SE project, to allow collaboration on things that everyone wants to share, and yet allow those that want to innovate and differentiate (in a compatible way) to leverage "the commons".

I think it will bring broad choice and diversity for those that want compatible implementations of Java.

-geir

IMO,it is a great idea!

Patrik A :

>>>There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform ....There is? I'll tell you what there IS a clear need of: a working standard implementation of a JVM that provides fast and stable running of java applications. Look at that sentence you open source fuckface; it contains keywords that are new to you, I know. Feel free to lookup:- standard- fast- stable- running- workingand read the sentence again. Who tf needs another broken os implementation of Java?

So how *do* you feel about this?

Other than me being an "open source f*ckface" (btw, I think the last word is hyphenated...), I do agree with you - this effort has to be just as good as any other implementation out there. An unreliable or slow implementation implementation isn't worth much for the large percentage of users for which Sun's, IBM's or BEA's free-as-in-beer implementation is just fine.

No one needs a broken implementation of Java, open source or not.

-geir

I'll tell you what there IS a clear need of: a working standard implementation of a JVM that provides fast and stable running of java applications.

Fast is a matter for debate. The jvm can definitely be implemented faster than Sun's. An open source implementation would freely allow for optimized builds for specific platforms, so as long as the base line is as good as Sun's there is a great potential for improvements.

The major argument that I've heard for an open source implementation is distribution rights. Right now you can't get a linux or bsd distro with java included and none of them have a real jvm in their packaging systems. If you make it easier for open source developers to work with java you will see much greater adoption on more platforms. Granted, all that would depend on getting a jvm that actually works, so I'm just hoping Apache can do what the others haven't so far.

Right now you can't get a linux or bsd distro with java included and none of them have a real jvm in their packaging systems.

Some of the commercial Linux distros (Red Hat, Suse, Red Flag) bundle BEA JRockit. The license allows redistribution.

If you make it easier for open source developers to work with java you will see much greater adoption on more platforms.

I'll be happy if you could convince me otherwise, but I have to say that I really doubt this. Java already has very widespread adoption. I can think of some niches where a specifically open source Java may have an advantage, but they are very small. I just don't believe that whether or not things are open source really matters that much in most IT projects, no matter how much some open source fans may wish that this were the case. For example, I use Linux because it is high quality and free. I believe that motivations for the use of Java is much the same.

However, if there is evidence to show I am wrong I would be highly interested.

All in good humor:

Fast is a matter for debate. The jvm can definitely be implemented faster than Sun's.

Assuming you mean "getting it done sooner", yes, there's something that Apache has a great track record on </sarcasm>

Assuming you mean "getting it to run code faster", that's an area that a lot of smart people (Microsoft CLR team, BEA jRockit team, etc.) have failed to do with lots of money and time. Sun's Hotspot has turned out to be a remarkably tough act to follow.

An open source implementation would freely allow for optimized builds for specific platforms, so as long as the base line is as good as Sun's there is a great potential for improvements.

You realize the incredible leap you took here? Please allow me to clarify what you just said:

"Assuming that the platform-unoptimized builds of the ApacheJVM 1.0 are just as fast as Sun's Hotspot JVM, then we could build them with platform optimizations turned on and we'd be even faster!"

Or, equally likely:

"Assuming that I have just as much wealth as Bill Gates, if I can just get my portfolio to perform slightly better than his, I will be the world's richest man!"

I am finding this discussion just a bit humorous ;-)

Let's get IBM to fund the project, Sun to donate Hotspot and the Java standard libraries, and the BEA jRockit guys to clean it up, and then it'll be a leap forward.

Otherwise, it's going to be a very long process.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

Quoting Cameron:

Assuming you mean "getting it to run code faster", that's an area that a lot of smart people (Microsoft CLR team, BEA jRockit team, etc.) have failed to do with lots of money and time. Sun's Hotspot has turned out to be a remarkably tough act to follow.

Yes, I meant executing code faster. Now I'll qualify what I'm about to say by stating that I'm not familiar with the performance comparison history of Sun's jvm vs. others. I am simply basing this on a single personal experience. If my experience is not normal, please correct me.

Where I worked up until recently we have always used sun on xeons. We have always found that performance suffers when hyperthreading is turned on so we leave it off. We were looking for ways to improve so we gave ibm and bea a try. Both resulted in very significant performance increases for both an ejb based data repository application and another that is more data throughput: lots of xsl transforms with xalan and queuing messages in the db. I think that our applications are generic enough to conclude that we weren't benefitting from some fluke critical piece that sun happened to not implement well.

In this case, ibm's didn't seem to care if ht was turned on while bea's definitely benefitted from it. I was also told (and again, not claiming any definitive knowledge here) that sun has optimized largely for amd while bea has paid special attention to intel.

An open source implementation would freely allow for optimized builds for specific platforms, so as long as the base line is as good as Sun's there is a great potential for improvements.

You realize the incredible leap you took here?

Let me clarify what I just said ;)
I think that if an open source implementation is able to reach the level of sun's implementation on, say, amd, and if there was significant community desire to improve the threading issues that cause a loss of performance on intel with ht, then we would have the ability to do so and it would be easier than asking sun to optimize for intel. The same idea could be applied to operating systems instead of architectures and to ease-of-use and integration instead of performance.

Please allow me to clarify what you just said:

"Assuming that the platform-unoptimized builds of the ApacheJVM 1.0 are just as fast as Sun's Hotspot JVM, then we could build them with platform optimizations turned on and we'd be even faster!"

Now if apache cannot rival sun's performance or my ideas on performance are indeed not the norm then what I have said is all for naught.

The criticisms of java that I constantly hear from the hardcore open source freaks are these:
-can't distribute it with non-commercial products
-can't improve it on our(their) own
-have to put up with whatever implementations the commercial vendors decide to make available for a particular platform.
Maybe the available commercial jvms are plenty good on mac os, linux and windows and those that are satisfied with them most definitely do not need to switch and will probably not benefit from this project much but those that would like either more freedom or more support on their platform of choice stand to benefit a lot.

Assuming you mean "getting it to run code faster", that's an area that a lot of smart people (Microsoft CLR team, BEA jRockit team, etc.) have failed to do with lots of money and time. Sun's Hotspot has turned out to be a remarkably tough act to follow.

Cameron - care to back this statement up with some data? We run literally hundreds of benchmarks ranging from micros to large server apps every day in our QA, and JRockit consistently outperforms Hotspot on a vast majority, often by a significant amount. BEA customers who have tried both Hotspot and JRockit report performance gains ranging from a slight improvement to "twice as fast", most falling in a 30-50% spectrum. Of course, if your bottleneck is not in Java code, then you won't see much of a difference.

The world is a complex place, and it's impossible to be best at everything. One place where JRockit does not outperform the competition is floating point calculations, which happen to be one of the most popular areas for Java microbenchmarks.

Here's an open challenge: Find benchmarks where JRockit does not outperform Sun's or IBM's JVM's and post them to our public forums. I promise you we will do our best to improve, as we did in this case.

Cameron - care to back this statement up with some data? We run literally hundreds of benchmarks ranging from micros to large server apps every day in our QA, and JRockit consistently outperforms Hotspot on a vast majority, often by a significant amount. BEA customers who have tried both Hotspot and JRockit report performance gains ranging from a slight improvement to "twice as fast", most falling in a 30-50% spectrum. Of course, if your bottleneck is not in Java code, then you won't see much of a difference.

First, I love what you guys do. Keep it up.

Sun's Hotspot suffers from "NeedsToBeTunedItis", probably because Unix people don't like server software unless it doesn't run well without tweaking a dozen command line knobs.

Nonetheless, once a properly tuned Hotspot server warms up, its inlining ability is incredible potent, and Sun has finally removed a couple rough spots in the performance over the past few releases. On the tests I've done, jRockit is typically a bit slower.

(Since jRockit is an effective JIT, I like to test performance-critical code both in Hotspot server and in jRockit, just to make sure that any optimizations are applicable both to an inlining-style JVM as well as a JVM focused on method-by-method optimization. I can also provide specific examples of how the Java libs assume a Hotspot model; one need look no further than the UTF8 coversion from Strings in java.io.DataOutputStream, which obviously assumes that the cost of String.charAt(int) is zero.)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

Sun's Hotspot suffers from "NeedsToBeTunedItis", probably because Unix people don't like server software unless it doesn't run well without tweaking a dozen command line knobs.

Yes, we noticed that as well. Of course, many customers don't care to tune, so out-of-the-box performance is very important and a focus area for us.

Nonetheless, once a properly tuned Hotspot server warms up, its inlining ability is incredible potent, and Sun has finally removed a couple rough spots in the performance over the past few releases. On the tests I've done, jRockit is typically a bit slower.

JRockit also inlines aggressively, at least in our current versions, and we verify performance in part using microbenchmarks that make calls to various standard APIs - the result is almost always in JRockit's favor. I'd be interested in knowing what JRockit version you have been running on. I'll dig up your email and will take that discussion offline.

Cheers,

Henrik Ståhl
JRockit Product Manager

I'll dig up your email and will take that discussion offline.Cheers,Henrik Ståhl

Please don't. I'd like to hear what you've got to say (if you don't mind). The forums maybe?

I'll dig up your email and will take that discussion offline.

Please don't. I'd like to hear what you've got to say (if you don't mind). The forums maybe?

You got it! Let's move this discussion to the JRockit user forums. I'll make sure to put some hard facts in there, and will get developers and our performance team to answer any questions you might have!

Henrik Ståhl
JRockit Product Manager

>>>There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform ....Can someone please explain WHY they feel there is a CLEAR need for this? Customized JVM's?? Aren't we talking about forking java at that point? Sounds like a pandora's box to me.

That's what I was thinking too. Alarmbells started ringing almost the moment I read the headlines and they didn't stop reading the proposal.
Nowhere is it mentioned that this beast should pass the Sun compatibility tests for example. That leaves the whole thing open to (and probably designed to) forking and destruction of the Java language specification (and therefore a return to the bad old days of having to rewrite your program for pretty much every machine it's going to have to run on.

I wonder if this project could ever be a success. This is no trivial task that we're talking about. A tremendous amount of research typically goes into building a high-performance JVM, implying significant levels of funding.

And don't use Linux to suggest that anything otherwise works. OSDL CEO Stuart Cohen recently wrote that "..Looking at the top 25 contributors to the Linux kernel today, you'll discover that more than 90% of them are on the corporate payroll full-time for companies such as HP , IBM, Intel, Novell , Oracle , Red Hat and Veritas , among many others".

Sandeep

OSDL CEO Stuart Cohen recently wrote that "..Looking at the top 25 contributors to the Linux kernel today, you'll discover that more than 90% of them are on the corporate payroll full-time for companies such as HP , IBM, Intel, Novell , Oracle , Red Hat and Veritas , among many others".Sandeep

But how many of them were hired <strong>because</strong> they are top Linux contributors?

There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform

Care to substantiate this claim?

Because from my experience and after having seen several "shows of hands" on this question at many conferences, I am confident claiming that hardly anybody cares about an "open-source" Java (whatever that means... Java is very much open-source enough for me).

And in the (unlikely) case where you would actually reach a 100% compatible version of J2SE, why would anyone use your version of it instead of Sun's?

I wish you would focus your energies where they are needed (e.g. Geronimo).

--
Cedric

Agree with Cedric, and even more so...

Why in God's name must the stereotype Java developer be such a die-hard Open Source afficinado? Is it the lure of expressing one's ego in code, and showing the world that you _actually_could_ do something no one ever asked for? Or is it the sheer satisfaction of taking a stand, making your voice heard on the barricades: "We the people demand software controlled by no one, maintained by no one".

For isn't it so, that after the initial period of enthusiasm has faded away and been replaced by nights of unpaid programming and finishing/debugging those last 10% percent of code, or when the bug reports start dropping in, that the true motives of each individual involved start to rear its ugly head?

The ego-driven open source programmers will, if not earlier, move on to other more creative and intellectually rewarding exercises - there's always a wheel to be reinvented or a not yet invented solution that has no demand.

The business-oriented open source programmers will, on the other hand, release a new version of the software and - surprise - its license has changed ever so slightly, to make its use in production environments subject to a license fee. As a coincidence, a new company has sprung to life that delivers enterprise services based on commercial open source software, the said software in fact.

Now, please don't get me wrong here. I'm all for open source. In fact, the project which I'm currently involved in is dependent upon 40 or so external jar files, all of which were "free" open source at the project's inception. However, four years down the line, the customer finds itself wanting to upgrade these libraries to a decently current version and realizes that he is being dependent upon 10+ libraries that are no longer being developed or maintained and about the same amount of libraries which have now entered the commercial arena.

So, now the customer is faced with the choices of:

1) not upgrading the libraries, which means taking the source code of them, if still available, and adding it to his existing repository. A considerable maintenance effort one might argue.

2) upgrading the libraries, which means a) finding replacement libraries for those that have kicked the bucket and b) unvoluntarily obtaining 10+ new software providers. (a) is a non-trivial and time-consuming task and (b) is a very non-optimal solution for an organization that has taken a lot of measures to consolidate its portfolio of software and hardware providers.

So, where did the customer go wrong? Should he had taken continuous measures to closely follow the development of each library and proactively made appropriate arrangements in each case? Or should he had developed a policy for open source that would have minimized the risk of ending up with orphan code packages by not letting them in the door in the first place? Or should he have avoided open source completely?

I don't have the answers to these questions but what is worse, I don't think the industry has either. People and organizations tend to skip quality and consequence analysis just because something is open source. "Hey, it's free. What does it matter if we use it?". Well, as code evolves so does dependencies, and then, when you find yourself having a substantial amount of your in-house applications being dependent upon a library which might no longer be supported, either because:

i) the people previously maintaining it went on to pursue new challenges,

ii) the code or its maintenance shows itself to be of unacceptable quality, or

iii) the company maintaining the code adopts a "professional open source" strategy, and pricing

, you'll find out the hard way that it DOES matter.

So people, could we please agree on the following:

1) Can be clear on the fact that no-one will EVER do something for free forever? Either someone will develop something because of ego-centric reasons: proving themselves to others, proving something to themselves, tasting the sweet fruits of solving an intellectual challenge, etc. These motives will hardly ensure long time maintenance. Or they will be driven by business reasons and the open source path is used to create a user base before going commercial. Use the drug dealer allegory - the first fix is free - if wou will.

The problem is not if any of these reasons would be questionable. The problem IS not accepting this fact and not being open about it, internally and externally, and pushing open source as a silver bullet and something of almost divine unselfish qualities. Failing to do so is hyprocricy and something that will have a strict adverse effect both on the project and its users/customers in the short term and the credibility of the whole industry at worst.

2) Before venturing into yet another open source project, could you please clarify:
   * Its external motivation - What will the proposed software (the product goals) do that other software doesn't? What will the benefits be to its customers (the effect goals)?
   * Its internal motivation - Do the project participants share a common goal or do they have different agendas, that will inevitabely lead to a clash or branch down the line.
   * The organization - Who will make decisions on the project's future (Change Control Board)? Who will be responsible for its maintenance? What will the terms of the maintenance be? Best effort? Case handled in max 5 business days? Or will it be based on an "if I feel like it"- or "if it's an interesting problem"-policy...?

Finally, this could be looked on at a higher level. If we believe that civilization develops based on an incremental knowledge model and that an individual should try to use his abilities where they are best utilized, and based on what others have contributed before him, wouldn't you agree that reimplementing something from the ground up just becasuse you think you could do it a little better that the previous is helping civilization and mankind forward? Could you even say that it's innovative?

Then again, one does not have to dedicate his every moment to help mankind forward, but then we are talking about something you do for fun or for your own sake, because you think its fun - more or less a hobby. Nothing wrong with that, but far from "professional open source" and nothing I would recommend my customer to use.

So, to all you talented open source Java developers out there: Your dedication and competence deserves all respect, it's just your motivation and business model that need clarification and perhaps even a redesign.

Sincerely
/Par

In fact, the project which I'm currently involved in is dependent upon 40 or so external jar files, all of which were "free" open source at the project's inception. However, four years down the line, the customer finds itself wanting to upgrade these libraries to a decently current version and realizes that he is being dependent upon 10+ libraries that are no longer being developed or maintained and about the same amount of libraries which have now entered the commercial arena.

Cry me a freaking river.

Just for fun, Par, why don't you do the same project again for your client, but this time introduce dependencies on 40 separate commercial products?

In four years, come back to us and report:

1) how many of those companies are still in business, and supporting the product
2) how many of those companies have raised licensing and support costs beyond what you consider reasonable
3) how many of those companies will give you access to the source, so that you can handle emergency support issues that the developer is not willing or able to

Oh, that's right, you probably won't get a chance to perform this experiment because for most clients acquiring licenses on the 40 commercial products will make the project prohibitively expensive out of the gate.

So the problem you describe is not specific to open-source, but rather a general issue of planning for future maintenance and support issues when implementing a software system. And this is an issue you seem to struggle with.

I don't have any interest in an open source J2SE implementation, but that doesn't give me a license to blame open source developers for my inadequacies as a consultant. Nor does it give me a license to tell open source developers how they should be spending their valuable time.

Corby,

If you re-read my post you will see that I'm not bashing open-source, and that your "freaking river" outburst is merely Don Quijote attacking a wind mill.

Actually, what I AM saying is that you should treat open source just as you treat commercial software and apply the same effort in evaluation and testing. If you do so, you probably won't end up the way my customer did, because you will have separated the ego-software from the "commercial software in disguise" and will have applied strategies accordingly. Now, isn't that a good thing? And, yes, struggle is part of my work, but not what you, erronously, are referring to.

It's also good that you are not blaming anyone for your inadequacies. Neither am I. If someone wants to reinvent the wheel for ego-centric or religious reasons instead of helping the Java industry forward or, even better, spending time with their families, it's their choice. As long as open source projects are evaluated on the same criteria as commercial software, the wheat will naturally be separated from the chaff.

Cheers
/Par

1) how many of those companies are still in business, and supporting the product

the drop out rate of commercial projects will still be much lower than the rate of OS projects, for reasons that were well explained in the original post

2) how many of those companies have raised licensing and support costs beyond what you consider reasonable

you face the same risk with OS projects as well (the ones that suddenly become "professional open source")

3) how many of those companies will give you access to the source, so that you can handle emergency support issues that the developer is not willing or able to

the point is - you don't have to care about that. All you should care about is providing the added value of your application and not about supporting and maintaining every piece of the underlying infrastructure. Do you think that having the sources of the 40+ libs your application depends on helps that much? I wonder how you find the time to ever develop your application if you spend that much time fixing the underlying infrastructure

Care to substantiate this claim?Because from my experience and after having seen several "shows of hands" on this question at many conferences, I am confident claiming that hardly anybody cares about an "open-source" Java (whatever that means... Java is very much open-source enough for me).

+1

It puzzles me when some people proclaim that Java needs to be 'open source' to 'survive'. It is obviously doing 'rather well' (English understatement) with current licensing. There seems to be a highly vocal group who should loudly for the need for an open source Java, but most of us are just happy that it is 'free as in beer' and use it without worry. I believe that Sun has done exactly the right thing with Java over the years.

Care to substantiate this claim?Because from my experience and after having seen several "shows of hands" on this question at many conferences, I am confident claiming that hardly anybody cares about an "open-source" Java (whatever that means... Java is very much open-source enough for me).

+1It puzzles me when some people proclaim that Java needs to be 'open source' to 'survive'. It is obviously doing 'rather well' (English understatement) with current licensing. There seems to be a highly vocal group who should loudly for the need for an open source Java, but most of us are just happy that it is 'free as in beer' and use it without worry. I believe that Sun has done exactly the right thing with Java over the years.

Well said Steve. Most people shouting for Sun to release Java as open source (in their definition) couldn't care less about Java. They're the traditional open source zealots, most of them are in fact proclaimed Java haters instead of users!
They don't want just an open source JVM (they could have built one years ago if they'd cared and this has in fact been done with variable success several times), they want to take control of the JLS so they can fork it into insignificance, removing Java as a threat to their beloved Perl and C.

Cedric Beust :

There is a clear need for an open-source version of Java 2, Standard Edition (J2SE) runtime platform

Care to substantiate this claim?

That's what we're trying to do in the Apache Harmony project. I'm not trying to dodge the question - I think the proof will be "in the pudding".

Because from my experience and after having seen several "shows of hands" on this question at many conferences, I am confident claiming that hardly anybody cares about an "open-source" Java (whatever that means... Java is very much open-source enough for me).And in the (unlikely) case where you would actually reach a 100% compatible version of J2SE, why would anyone use your version of it instead of Sun's?I wish you would focus your energies where they are needed (e.g. Geronimo).-- Cedric

Well, I'm not going away from Apache Geronimo, but that's unrelated to this.

As you note, the term "open-source Java" has different meaning for different people. To me, it means an independent implementation of the specification under an open source license. To others, it means something much different - related to the bigger questions around ownership, stewardship and participation - but that's not what we're doing w/ Harmony.

To me - and I'm just one out of many that's interested in seeing Apache Harmony succeed - I think the value of open source infrastructure is not that it's intrinsically open source for open source's sake, but rather the opportunities that it being open source provides in general. For that, I'm willing to put in a lot of work :) Others have different motivations, and that's just fine by me.

One important opportunity is that it enables collaboration in the parts of technology that are common to all, letting organizations reduce engineering costs and letting them focus on things that bring innovation or some other value over and above the common. That value can be something as general as services and support, or specific in terms of tailoring for an application profile or specific environment, or parting to hardware, or what-have-you. Or it can be using what's there, and building value on top, as we see happening in the J2EE space. The basic appserver is (and should be) a commodity - value comes from being more than just J2EE, but in support, performance, bundled functionality, whatever...

Why are there multiple versions of J2SE now? I think it's because the various vendors thought they could offer enough distinct value for their customers that it was worth the engineering effort. Do I think that they want to keep going this way, each with some derivative of Sun's or their own independent implementation? No - I think that it's too expensive, and that quite a bit of engineering resources can be freed to innovate if everyone can stop re-inventing the wheel.

I think J2SE should be a common "dial tone" on every platform (just like I think that basic J2EE should as well... see a pattern?). Developers should be able to count on a set of services available to them. Those creating the platforms should be able to focus on what makes them different, not what makes them the same, and share in the maintenance of that "commons" if they wish. Then they can make sure that developer's programs run as fast as possible, or as safe as possible, or as griddable as possible, or whatever the value-add is.

And for the Free Software people working to build a completely Free OS? They should be able to ensure that what they offer is as Free as possible, or whatever their goals are.(I have every interest in working with the other existing OSS Java projects that are out there in whatever way we can. That's one of the two major drivers of Apache Harmony - we have a lot to offer each other in working together...)

Anyway, there's at least some of my thinking on this. I think that "Why do OSS?" a really complicated subject as is "Why do OSS Java?", and I hope that while I can't seem to clearly nail things down, answering thoughtful challenges like this will help get my personal POV across, and get people to at least come to Apache Harmony and see what's going on.

-- geir

Those creating the platforms should be able to focus on what makes them different, not what makes them the same

This makes me nervous. I don't want Java implementations to be that different. Competing on the basis of performance and support sounds good, but the possibility of one vendor's Java - perhaps only available on one platform - having value-added features that, if used, would prevent portability sounds to much like what happened with Microsoft Java.

Those creating the platforms should be able to focus on what makes them different, not what makes them the same

This makes me nervous. I don't want Java implementations to be that different. Competing on the basis of performance and support sounds good, but the possibility of one vendor's Java - perhaps only available on one platform - having value-added features that, if used, would prevent portability sounds to much like what happened with Microsoft Java.

Right, and that's not what I meant at all. I fear the same thing. I keep trying to put "compatible implementation" everywhere I can, because I think that's important, but I forget, or don't want ot sound like a broken record.

So when I say "what makes them different", I mean things like integration to management systems (know how the VMs are doing), trace facilities, different performance profiles, different platforms, pluggable GC, whatever floats people's boats.

But yes - it's important to be compatible. The "compatibility promise" is one of the things that makes Java so valuable, and a safe investment for application development.

We have to approach this issue carefully, with open eyes, and as users of Java, demand portability and compatibility.

- geir

Those creating the platforms should be able to focus on what makes them different, not what makes them the same

This makes me nervous. I don't want Java implementations to be that different. Competing on the basis of performance and support sounds good, but the possibility of one vendor's Java - perhaps only available on one platform - having value-added features that, if used, would prevent portability sounds to much like what happened with Microsoft Java.

Right, and that's not what I meant at all. I fear the same thing. I keep trying to put "compatible implementation" everywhere I can, because I think that's important, but I forget, or don't want ot sound like a broken record.So when I say "what makes them different", I mean things like integration to management systems (know how the VMs are doing), trace facilities, different performance profiles, different platforms, pluggable GC, whatever floats people's boats.But yes - it's important to be compatible. The "compatibility promise" is one of the things that makes Java so valuable, and a safe investment for application development.We have to approach this issue carefully, with open eyes, and as users of Java, demand portability and compatibility.- geir

Thanks. I apologise if I was misunderstanding. This makes me a lot less nervous!

Those creating the platforms should be able to focus on what makes them different, not what makes them the same

This makes me nervous. I don't want Java implementations to be that different. Competing on the basis of performance and support sounds good, but the possibility of one vendor's Java - perhaps only available on one platform - having value-added features that, if used, would prevent portability sounds to much like what happened with Microsoft Java.

Right, and that's not what I meant at all. I fear the same thing. I keep trying to put "compatible implementation" everywhere I can, because I think that's important, but I forget, or don't want ot sound like a broken record.So when I say "what makes them different", I mean things like integration to management systems (know how the VMs are doing), trace facilities, different performance profiles, different platforms, pluggable GC, whatever floats people's boats.But yes - it's important to be compatible. The "compatibility promise" is one of the things that makes Java so valuable, and a safe investment for application development.We have to approach this issue carefully, with open eyes, and as users of Java, demand portability and compatibility.- geir

In that case you should ammend your proposal to include the requirement of the product passing the compatibility test suite before any release ships and again for each new release.

Geir,

the term "open-source Java" has different meaning for different people. To me, it means an independent implementation of the specification under an open source license. To others, it means something much different - related to the bigger questions around ownership, stewardship and participation - but that's not what we're doing w/ Harmony

So, regarding ownership and stewardhsip IIUC with Harmony:

1. Java is still Sun's property. They give/deny their seal of aproval to Java implementations.
2. Java is still desgined at large by Sun, like a cathedral.

One important opportunity is that it enables collaboration in the parts of technology that are common to all, letting organizations reduce engineering costs and letting them focus on things that bring innovation or some other value over and above the common.That value can be something as general as services and support, or specific in terms of tailoring for an application profile or specific environment, or parting to hardware, or what-have-you

I hope that while I can't seem to clearly nail things down, answering thoughtful challenges like this will help get my personal POV across

Here are some more (not so challenging) questions:


- Which are the organizations you have in mind when thinking on the oportunity regarding collaboration?

- How these oportunities relate to Joe Average Programmer?

- What are the users you see for an OS Java implementation?

- What are the use scenarios envisioned for Harmony?


TIA


Javier

...Because from my experience and after having seen several "shows of hands" on this question at many conferences, I am confident claiming that hardly anybody cares about an "open-source" Java (whatever that means... Java is very much open-source enough for me)....

The reason why you don't see a "show of hands" for "open-source" Java at Java conferences is because Java developers don't need an Open Source Java implementation - it's already free (as in beer). But Open Source Linux developers need it before they will develop Linux applications in Java, and IMHO that's a good enough reason to create an Open Source compatible Java implementation.

BTW is there any legal possibility of making the javax.* packages optional - as in you download them only if you need them? That would reduce the size of the basic JRE download and help make Java ubiquitous on the desktop - Windows, Apple and Linux.

But Open Source Linux developers need it before they will develop Linux applications in Java, and IMHO that's a good enough reason to create an Open Source compatible Java implementation.

This may be the case, but I would be interested if someone could point me to some evidence that this group is of any significant size. This is a group that shouts loudly about the need for an open source Java, but my impression is that it is a very small section of the whole developer community (not that this is a good reason for ignoring them).

BTW is there any legal possibility of making the javax.* packages optional - as in you download them only if you need them? That would reduce the size of the basic JRE download and help make Java ubiquitous on the desktop - Windows, Apple and Linux.

I think it would do the exact opposite, as the javax.* contain one of the most important Java desktop APIs - Swing!

This may be the case, but I would be interested if someone could point me to some evidence that this group is of any significant size...

Evans Data Corporation, in their Linux Development Survey dated Summer, 2004, shows that there are 1.2 Million Linux developers and growing.

I think it would do the exact opposite, as the javax.* contain one of the most important Java desktop APIs - Swing!

Okay, okay, let me rephrase - you could downlaod a JRE with only the APIs required for desktop Java. Happy?

This may be the case, but I would be interested if someone could point me to some evidence that this group is of any significant size...

Evans Data Corporation, in their Linux Development Survey dated Summer, 2004, shows that there are 1.2 Million Linux developers and growing.

That is interesting, but (not having seen the survey) I have no idea what those developers are using, or how much Open Source is or isn't a concern of that 1.2 million. Linux is, after all, a major platform for deployment of J2EE applications. I would be interested in more details.

 

I think it would do the exact opposite, as the javax.* contain one of the most important Java desktop APIs - Swing!

Okay, okay, let me rephrase - you could downlaod a JRE with only the APIs required for desktop Java. Happy?
I think there is likely to a wide range of views about what those APIs are.

Okay, okay, let me rephrase - you could downlaod a JRE with only the APIs required for desktop Java. Happy?

I think there is likely to a wide range of views about what those APIs are.

Spot on, Steve. For instance a lot of people suggested that CORBA should be moved off; heck I don't agree with that, from where I stand I'd like to get Swing out of the way. This is clearly not going to work out for everyone, there's no way to decide what stays and what goes in a manner that would suit every application.
The fact that you cannot build customised JREs and bundle those with your application really sucks. This is very good use case for GCJ & friends.

The fact that worries me the most about the ASF initiative is that there's no clear indication, mere suggestions though, that the FSF could double license the Classpath both under GPL/modified and the Apache license and thus open the door to reuse and collaboration.

I signed on to the Geronimo mailing list shortly after Geronimo was announced. Lately, many posts are from those feeling frustrated, shut out, and quite frankly pissed off with the apparent lack of progress.

I suggest Apache commit all available resources to completing Geronimo first, before they worry about starting another even more lofty project.

A reasonable request?

Chris.

Aside from possible academic gains of an open source version of J2SE, what will the mainstream developer gain? Will it be faster? Will it be more efficient than JRocket, IBM, or Sun? Heck, I don't have to pay to use any of the existing ones.

With Sun's recent efforts to bring the community in on Mustang development, why must this talented group of folks run off and create their own flavor of J2SE instead of helping along Sun's JVM?

I'm sorry to say it, but I can see this project discussion going the same route as the whole GlueCode/Geronimo banter. Only a few (companies) will actually gain from this project and I'm quickly losing respect for the ASF and its committee members-- that licensing stuff at the bottom is ridiculous coming from an "Apache" project.

-- Jacob

Aside from possible academic gains of an open source version of J2SE, what will the mainstream developer gain? Will it be faster? Will it be more efficient than JRocket, IBM, or Sun? Heck, I don't have to pay to use any of the existing ones.With Sun's recent efforts to bring the community in on Mustang development, why must this talented group of folks run off and create their own flavor of J2SE instead of helping along Sun's JVM?

+1

+1

Totally agree with Cedric on this one. The chance of success for that J2SE project is not that big and even if they can get it somehow, why should i use this implementation instead of SUNs one? Most java developers i know are not that religious to use it just because it has a ASF license. Whats next, a J2ME reimplementation?

The whole jakarta group should repeat one word over and over gain: "Focus...Focus....".

Marc Logemann
http://www.logemann.org

The chance of success for that J2SE project is not that big and even if they can get it somehow, why should i use this implementation instead of SUNs one?

You may (may, not will) find that a classpath that's not encumbered by Sun's licensing restrictions is very useful. For instance you could build/distribute parts of it, or link your application statically against the parts it needs.

why should i use this implementation instead of SUNs one?

Like Apple JRE? or what if you wanted to run Unix on PPC and wanted a good JRE?

This will help java be widley distributed. For example apache has two order of magintued market share in web:
http://news.netcraft.com/archives/web_server_survey.html

Also AFAIK the Linux comunity is larger then Java, and Fedora 4 ships with Struts, Tomcat and Eclipse, they all run Java, all without Sun license! The other Linux distros said they will follow, which means that now the java market will jump another order of magnitude.

It's good not to depend on Scott's execution, yes?
Lets say there is a 4 year Java bug, limiting deployment of your application, and thus reducing your profit. What if you could distribute your own JRE w/ the app? Or beg:
http://weblogs.java.net/blog/stanleyh/archive/2005/04/deployment_good.html
Looks like only in 6.0
Most sucessfull applications include JRE w/; such as Limewire. Clearly that's not working as is:
http://www.javalobby.org/java/forums/t18329.html

There are other doing the same, not real news, so if you don't like Apache's impl, no worries:
http://www.java-virtual-machine.net/other.html
http://lxer.com/module/newswire/view/5804

We can compete w/ Mono's and Glade# CLR better.
Time will tell if this spikes Java demand, I think it will. You still can use comercial JRE like jRockit, if you think it better.

By having more Java out there, it help establish Sun's langage even more, and it may reduce Sun's (mostly in Asia) development costs, since they too can re-use the popular OS parts.

.V

(I use OS when there are no good commercial alternatives, ex: Hessian vs Jax-Rpc 2 or JGoodies Forms vs Gridbag, iBatis vs EJB3 so choice == good. If I wanted to have a monolitici platform w/ no alternatives, I know how to where to get that. That is not suitable for profesional commercial development)

why should i use this implementation instead of SUNs one?

Like Apple JRE? or what if you wanted to run Unix on PPC and wanted a good JRE?

Aren't these JVMs based on Sun's code (and so on Sun's implementation)? (I know that others (such as HP's) aren't).

This will help java be widley distributed
[...]
By having more Java out there, it help establish Sun's langage even more

I am not convinced of this, as the evidence is that Java is already very widely distributed - it is now the most popular language for new IT development (at least based on Job adverts). My reading of things is that the number of developers who aren't using Java because it isn't open-source enough is small. I could be wrong.

Where I think this project (if it works) would help is that having an alternate source for a high-quality high-performance Java is always a good thing, because competition is important: I believe that Sun's Java and Apache's Java could drive each other on to higher quality and fewer bugs.

I am not convinced of this, as the evidence is that Java is already very widely distributed

As per netcarft link above, apache is not 10 times the market of Sun, but more than 20 times the size. That's good jump (+ Linux).

BEA's jRockit is not based on Sun's anything, other than that it's compatible. (it's based on an formely open j2SE source impl. Like Oracle's J2EE is based on Orion, which was at least semi open source )

I believe that Sun's Java and Apache's Java could drive each other on to higher quality and fewer bugs.

This would be 1st and likely last time we agree ;-)

It's a perfect storm: Mustang + JDNC + Apache JRE... all competing for application developers.


oh yeah, there's this:
http://channel9.msdn.com/ShowPost.aspx?PostID=62621

What's a Jedi to do?

.V

I am not convinced of this, as the evidence is that Java is already very widely distributed

As per netcarft link above, apache is not 10 times the market of Sun, but more than 20 times the size. That's good jump (+ Linux).

Yes, but this is just one project. However, I take your point - apache is a highly successful OS application.

I believe that Sun's Java and Apache's Java could drive each other on to higher quality and fewer bugs.

This would be 1st and likely last time we agree ;-)It's a perfect storm: Mustang + JDNC + Apache JRE... all competing for application developers.

I'm afraid I agree with you again!

Vic, you reallly are astoundingly retarded. Your grasp of basic facts is as masterful as Fred Grott's spelling. So for the sake of reality...

As per netcarft link above, apache is not 10 times the market of Sun, but more than 20 times the size. That's good jump (+ Linux)

How on earth can you compare apache and sun according to a netcraft survey? That's about as meaningful as comparing tss article length with german cars.

BEA's jRockit is not based on Sun's anything, other than that it's compatible. (it's based on an formely open j2SE source impl.

No, it isn't. It's a VM product, and uses the sun classlib (ie, big chunks of src.zip). It also never was open source, and has always been commercial.

Like Oracle's J2EE is based on Orion, which was at least semi open source

Nope, Orion was always closed source. It's free for development, not open source (and labelling free for dev as 'semi' open source requires a particularly hyperactive imagination).

Orion was always closed source. It's free for development, not open source (and labelling free for dev as 'semi' open source requires a particularly hyperactive imagination)

I was trying to make an illustration, and not invent, so thanks for the correction. My argumnent still stands hopefully, but I won't re-iteratate the standing points.
Linux distro and apache have a huge market share and now "Java" impls are under their umbrela. I have predicted fine in the past, so I stand by that.

In 2001, JRockit was not a BEA nor Sun License, backstep trough waybackmachine.org:
http://web.archive.org/web/20010813142004/www.jrockit.com/about/releases/2001-06-03.html
Is that right? no sun license in 2001, no bea till 03?
I used it just fine.
And... I used to use Orion ( before I wrote of EJB's)
http://web.archive.org/web/20010501042121/bugzilla.orionserver.com/bugzilla
it had bugzila, etc... and it worked just as a jar, free to develop, so
*I just confused it.*

why so upset mr Ejb and mr hashmap? oooh my self estem...
lets remember why some of us don't use .NET == single vendor!
this is about mutiple implementations. enjoy more diversity.

We seem agree that if it spikes up compatible java use, that would be good. I don't care for "Gucci shades" to impress someone.

.V

BEA's jRockit is not based on Sun's anything, other than that it's compatible.

Vic, you are incorrect. You should look at jRockit before you go around making random claims about it.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

BEA's jRockit is not based on Sun's anything, other than that it's compatible.

Vic, you are incorrect. You should look at jRockit before you go around making random claims about it.

Vic, I didn't intend for that to sound so nasty; sorry about that. (I should have read what I wrote before I posted it.)

Technically, if you look at jRockit, it comes with a ton of stuff from the Sun JRE distribution. In fact, almost all of jRockit is identical to the Sun JRE except for jvm.dll in the ./jre/bin/jrockit directory.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

BEA's jRockit is not based on Sun's anything, other than that it's compatible. (it's based on an formely open j2SE source impl. Like Oracle's J2EE is based on Orion, which was at least semi open source )

JRockit is not based on open source, it was developed in-house by the Stockholm-based company Appeal Virtual Machines, which was aquired by BEA in 2002, see this old thread for details. And in one sense it is based on Sun, since the JRockit JDK consists of the JRockit JVM bundled with Sun's class libraries (plus a few extras, like diagnostics tools).

Of course, it could be bundled with some other class library, if one were available, which would make it "independent" of Sun.

Hi!

what if you wanted to run Unix on PPC and wanted a good JRE?This will help java be widley distributed.

For new machines, I had the impression we were well covered with JVMs from Sun, IBM and HP. If you're refering to support on older platforms, I wonder how this would help to make Java more distributed.

AFAIK the Linux comunity is larger then Java, and Fedora 4 ships with Struts, Tomcat and Eclipse, they all run Java, all without Sun license! The other Linux distros said they will follow, which means that now the java market will jump another order of magnitude.

Taking in account that there are already thousands of developers doing their work on Windows and deploying on Linux/Unix, in my view, it's pretty unlikely that just because all the Linux distros ship an open source version of J2SE, Java marketshare will be increased 10 times and sudenly we had tens of thousands of new Java developers working on Linux.

Lets say there is a 4 year Java bug, limiting deployment of your application, and thus reducing your profit. What if you could distribute your own JRE w/ the app?

Good point, and that's why I appreciate the efforts made in Mustang, but since many people has been bited by those bugs, and the open source version will be 1.5 based, I can't see enourmous benefits because currently there are by a large figure more pre 1.5 Java installations.

so if you don't like Apache's impl, no worries:http://www.java-virtual-machine.net/other.html

I got lost somewhere, what's the point on this 5 years old page regarding not liking apache's implementation? It talks mostly about pre 1.3 JVMs.

We can compete w/ Mono's and Glade# CLR better.

IMHO, compared with Microsoft's CLR and tools deployments, they are pretty much inexistent. Why spend resources fighting a non major competitor?

Time will tell if this spikes Java demand, I think it will.

My heart is with you. My mind thinks otherwise. :-(

By having more Java out there, it help establish Sun's langage even more, and it may reduce Sun's (mostly in Asia) development costs, since they too can re-use the popular OS parts.

I'm sorry Vic, I'm still not getting it. Perhaps I'm misunderstanding, but there a re a lot of JVM out there running in cell phones and it's not clear to me how this could have helped establish more the language, at least more than server applications. And about the cost reducing, which OS parts could be reused by sun, since they already have all the required parts?


Cheers


Javier

which OS parts could be reused by sun, since they already have all the required parts?

(lets try to keep it constructive)
I have doubts that Sun would have opened Mustang or JDNC if it was not for IBM and Apache. This is an incentive for them to improve a product and I think they will.
 *I WILL USE MUSTANG* as much as possible.

Sun now in 1.5 includes formerly open source concurrency collections jar. That's a benefit for ALL and it's a good model. OS did not lose anything by that.

Sun does not include Jakarta DynaMaps, or Collections for OrderMap or Jakarta Lang String utils, or Digester, or IoC or Hessian (a binary protocol) or CoR.....
I would rather that best parts of open source are included with rt.jar so I do not have to download them w/ the app.
How maintainable is GridBagLayout? please give me something else.

What about jRockit's parallel GC so you do not freze the server? Sun did not have it untill jRockit!
 and I had an alternative impl to use.

Sun and JCP still have inflence over API, but I can implement a collection the way I like. Good? Hell Yeah!

Java needs to continue to evolve, and this is a saftey net in case of a buy out or re-structuring at Sun. That is what OS gives you, source, so if they decide to change direction, the community of users is not left dry.

I am not blind to danger. For example Linux kernel and a dozzen distro's seem to work. But if we start having mutiple JRE's (like now as per link I gave above) on people's PC's then it would prove to be a step in the wrong direction, and it would make my life as a developer harder.

Some of you may like .NET aproach of the ONE vendor, I am more libreterian. Room for both?

.V

Sun now in 1.5 includes formerly open source concurrency collections jar. That's a benefit for ALL and it's a good model. OS did not lose anything by that.

And how an open source implementation would improve this situation? By offering at least the same features as the standard kit, and additional features? That way Sun would be forced to include more libraries?

this is a saftey net in case of a buy out or re-structuring at Sun.

This is the argument that makes more sense to me. I wonder if BEA and IBM would throw a lot of resources in order to cut their dependency on Sun.

Some of you may like .NET aproach of the ONE vendor, I am more libreterian. Room for both? .V

I don't believe just because something is labeled OS it's success is warranted.


Javier

I had the impression we were well covered with JVMs from Sun, IBM and HP.

Where can I get an IBM or HP 1.5 from?

Is this satisfactory?
I have 2 PPC machines 64 bit runing Linux.... and nowhere can I find 1.5 impl. currently. Someone?

As per
https://www.theserverside.com/articles/article.tss?l=RiA , the JNLP in 1.5 is not working right, and it's better to use OS impls for WebStart.

I think once Kaffe and Apache have grown, many years from now, these type of issues won't exist.

For example, XBox-2 and PlayStation-3 have fast PPC/Cell chips, boy I'd love to write a game in Java w/ Looking glass and have it use WebServices to co-ordinate atack.


.V

I had the impression we were well covered with JVMs from Sun, IBM and HP.

Where can I get an IBM or HP 1.5 from? Is this satisfactory?I have 2 PPC machines 64 bit runing Linux.... and nowhere can I find 1.5 impl. currently.

And an open source implementation, just for the sake of being OS would provide timely a current release?

I agree that situation it's not satisfactory and I'm sorry for you, me and the people in similar situation. However I believe having the sources is not enough. We tried to implement Firebird on IBM Mainframe over Suse. We had the sources, but the available C compilers, dependencies and perhaps people in the team were not able to tackle the task in a way that made sense to build such thing instead of rewriting the simpler business application. Look at the Jonas home page, they state:

JavaTM Compliance Information: the certification of compliance against Sun J2EETM 1.4 Certification Test Suite has been successfully completed for (and only for) the following configuration: binary package jonas4.3.4-tomcat5.0.30.tgz running on Sun JDKTM 1.4.2_07, deployed on Linux kernel 2.4.9 with an OracleTM database version 10.0.1.4 and JDBCTM driver i-net ORANXOTM version 2.08.

Once we had compiled such thing, in order to assure we got a compliant JVM we would need to pass the compatibility tests. It's a big and complex task. As others have said, an OS implementation would benefit people in your situation and people in the consulting firms sponsoring the project. Perhaps another reason to start that endeavour.


Javier

By having more Java out there, it help establish Sun's langage even more, and it may reduce Sun's (mostly in Asia) development costs, since they too can re-use the popular OS parts.

The main problem with that is that this thing won't be compatible with Sun's Java specification if they implement it the way it reads...
That will HARM Java, not benefit it. We'd be back to the days of rewriting and retesting every line of code for every platform (and in this case every possible JVM version and installation options for every platform).

The main problem with that is that this thing won't be compatible with Sun's Java specification if they implement it the way it reads...That will HARM Java, not benefit it. We'd be back to the days of rewriting and retesting every line of code for every platform (and in this case every possible JVM version and installation options for every platform).

I think this is a bit harsh, after all the original post says: "create a Compatible, independent implementation of J2SE 5". I'm sure that people such as Danese Cooper (who until recently has been working at Sun) would not be endorsing this unless it was going to be a true compatible, fully tested, Java.

That will HARM Java, not benefit it. We'd be back to the days of rewriting and retesting every line of code for every platform (and in this case every possible JVM version and installation options for every platform).

Dude, start thinking for a second. If it doesn't pass the TCK IT IS NOT JAVA. Your wonderful programs will require JAVA to run, not everything that is a Java wannabe. Can you grasp the difference ? If your boss told you you have to make your code run on both Sun's VM and Apache's Java VM it would run, because it's called Java. If it's called Apache Vaja it's like you have to write your code to run on MIPS and have to write it in C, ok, only it will probably be much simpler. So what the heck is your problem ?
By the way, since you're in a bitching mood, go cry about the write-once-rewrite-everywhere mobile Java experience.

To Marc and Cedric,

You ask, paraphrased, "Why should anyone use Apache's J2SE implementation if Sun's is available?" You ask as if it is self-evident what the answer is. Well, it's not to me.

I think it's only fair to ask the question in reverse: Why should anyone use Sun's implementation if Apache's implementation of J2SE is available?

To Marc and Cedric,You ask, paraphrased, "Why should anyone use Apache's J2SE implementation if Sun's is available?"

My question was: "Show me evidence that there is a big demand for an open-source J2SE".

My observations tell me the answer is a unanimous "no".

 You ask as if it is self-evident what the answer is. Well, it's not to me.I think it's only fair to ask the question in reverse: Why should anyone use Sun's implementation if Apache's implementation of J2SE is available?

The fact that Sun has a nine-year headstart and is a corporation with a lot of resources and cash, for starters.

But you know, far from me the idea to discourage reinventing stuff. That's all fine and fun.

I just object to the pretext invoked, which is that "people are demanding for it".

It's just plain not true. The way I see it, the people who volunteered to participate in this project want to do something fun and they are going for it. Fine.

It's just not going to go anywhere.

Just my 1.75 eurocents.

--
Cedric

Cedric,
If you don't see any demand it doesn't mean it's not there.
I'm only going to point out that IBM's Jikes RVM and Intel's ORP (why oh why do these exist when there's Sun VM ?!) use Classpath, and at this point dozens of applications including Tomcat, Jonas and Eclipse run on free java runtimes. Red Hat distributes a native build of Eclipse with its enterprise Linux. If you really want to believe that Red Hat is braindead and all the people who see value in having the ability of running Java programs without using IBM or BEA or Sun's VMs are a bunch of wankers, that's cool with me, go put a comment on hani's blog.

This is NOT about reinventing the wheels. It's about choice, about having options for how you pack, deploy and run Java applications. It's about being able to build a custom VM for an embedded device, or deploy AOT compilation for all the platforms supported by GCC. It's about being able to make a trade-off between deploying your application like a 2MB exe that requires nothing else to run or an 100K jar that requires JRE 1.whatever and a 20 mb download.

Go read http://java.com/en/download/linux_manual.jsp and see what environments are used for testing the JRE and what environments are _supported_. Welcome back to 1998, it's great seeing you again!

.. at this point dozens of applications including Tomcat, Jonas and Eclipse run on free java runtimes.

Free runtimes, like Sun's, BEA's and IBM's?

Please don't abuse our English language by redefining words. Our language has enough problems already.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Cluster your POJOs!

.. at this point dozens of applications including Tomcat, Jonas and Eclipse run on free java runtimes.

Free runtimes, like Sun's, BEA's and IBM's?Please don't abuse our English language by redefining words. Our language has enough problems already.Peace,Cameron Purdy

I was obviously referring to the "free as in freedom" thing.
Hey, blame RMS !
Peace to you as well !

I agree with this. I don't believe that Apache creating its own implementation of J2se is actually contributing much to a community of software development. It's addressing a need that is largely alreday fulfilled by currently avaible, cost free implementations.

It sounds a lot like a case of "Not Invented Here" syndrome is taking root at ASF.

It sounds a lot like a case of "Not Invented Here" syndrome is taking root at ASF.

I'm inclined to think that this is already the case, past examples such as Apache Logging are there to show you this.

I don't see the point of developping an OpenSource implem of J2SE, but hey, if people have nothing else to do, why not?


a++ Cédric

I agree with this. I don't believe that Apache creating its own implementation of J2se is actually contributing much to a community of software development. It's addressing a need that is largely alreday fulfilled by currently avaible, cost free implementations.

Cost-free implementations that each have to maintain the entire codebase. (I don't think that there's as much in common w/ the three major distributions as many people think.)

Suppose that we could have one source base which was compatible, and generally fast. Then suppose that it could be taken by anyone and tailored for a given environment, or such. Wouldn't that be better? Wouldn't that make Java even more widely available?

It sounds a lot like a case of "Not Invented Here" syndrome is taking root at ASF.

I don't think so. We generally are happy to reuse as much as possible from elsewhere.

-geir

Cost-free implementations that each have to maintain the entire codebase. (I don't think that there's as much in common w/ the three major distributions as many people think.)

Introducing another codebase will not resolve this issue, but exacerbate it.

Suppose that we could have one source base which was compatible, and generally fast. Then suppose that it could be taken by anyone and tailored for a given environment, or such. Wouldn't that be better? Wouldn't that make Java even more widely available?

By "Environment" I assume operating system.If there are environments that currently don't have free jvms available and the Apache implementation-to-be is ported then yes, this makes java more available.

This might put pressure on commercial vendors to improve their products. The other possibilty might be that it aims to turn Apache into a one stop shop - jvm, application server, what have you. But as many posters have pointed out, getting there is not going to be easy, if possible at all.

It sounds a lot like a case of "Not Invented Here" syndrome is taking root at ASF.

I don't think so. We generally are happy to reuse as much as possible from elsewhere.

Apache does reuse - accepted. But my point was that this proposal is to build something that has already been successfully built elsewhere, and is freely available. The point relates to motivation. Now given that it is an open source effort, and that a lot of people give time voluntarily, they, quite seriously, can do what they want. I just wonder if their skills might not be better directed elsewhere.

All I've got to say is that if they are going to do this, I seriously hope that they have resources to actually make this happen in a timely manner. We don't need another half-implemented JVM/class libs that seem to take *forever* to complete.

If they can follow how quickly MONO got their stuff working, that might not be too bad.

Why the hell doesn't IBM just opensource their VM? That would solve this whole mess. People should stop pressuring Sun, they will probably never opensource their VM (although what they are doing with mustang has many of the benefits of open source).

This needs to be an all or nothing effort.

No half ass VMs that, 5 years later, are still 'almost' done.

But if this takes off then I wish them the best of luck in getting something working.

What would be the interaction with the much fanfared Javali project from Brazil? To find out what they are up to: http://www.javali.org.br/ - unfortunately, you need to be able to read Portuguese, because their English links are all dead.

Bruno Souza, one of the Project Harmony members, is also a member of the SouJava JUG, the JUG that is responsible for the Javali Project.

I can see the argument for an Apache licensed J2SE implementation. However, when I think about it, it seems like such a waste of time to put years of work into a piece of software that already exists today, just for licensing reasons. I feel the same towards projects like Mono and even Linux to some degree. For me, it is a sign that something isn't working quite right in this industry, when the most talented people put their effort into copying something as big as a J2SE runtime.

If there is any spirit of scientific progress left within Sun or even some smart commercial thinking, now is the time to come forward and say: Take our J2SE, make it an Apache project, have those Java desktop freaks move their beloved pixels where they think they belong, straighten out the ragged Cs, make the Windows file chooser work, and then let's move on to something a little more innovative and commercially interesting.

Does it mean BEA wants to open source their JRockit JVM ? I got to the conclusion after just looking at some of the names:
- Guy Churchward - one of directors in BEA
- Joakim Dahlstedt - BEA - afaik "the man behind JRockit", he is the JRockit architect
- Georges Saab - BEA engineering manager

IMHO not a bad idea - BEA has excellent reputation in dev community, good achievements in open source (XMLBeans, Beehive), so far has been playing fair with others (they are not "noisy Larry E. from Oracle" personalities) and particularly these guys (Joakim, Guy) 'guarantee' good output of the project.
No to mention that BEA could speed up the project, because they could just immediately share with the community majority of the JRockit code (majority, not all, because I don't believe they will share the features differentiating JRockit from other, i.e. high-performance, some of GC, Intel optimizations, Windows & Red Hat Linux optimizations).

Guy, Joakim, George - please position Harmony and JRockit.

BR,
Walt

I appreciate your comments on JRockit and BEA, we're all for driving and supporting open standards and innovation.

We're pleased to be involved in project Harmony; our role will become more apparent in the coming weeks.

Regards,


Guy

P.S for anyone seeking a mission critical server side JVM you might want to try www.jrockit.com, it's free to use.

My two cents:

The thought of competing JVMs scares me from a compatibility standpoint. If I have something running under Harmony, and communicating with a Sun JVM and there is any sort of incompatibility, I see it as a very big deterrent from having more than one JVM.

That said, if Harmony can pull the preverbial rabbit out of the hat, more power to you. Just understand that -- at least from my point of view -- the burden of compatibility is on Harmony, not Sun. Any Java program should run on either JVM with no problem. And in addition, I think it should be a goal of the Harmony project to see software writers continue to say that "ApplicationName 1.X requires Java <version>" not "ApplicationName 1.X requires Harmony Java <version>" There should be absolutely no difference in the way two are used -- only in issues like performance.

Aaron Craven :

My two cents:The thought of competing JVMs scares me from a compatibility standpoint. If I have something running under Harmony, and communicating with a Sun JVM and there is any sort of incompatibility, I see it as a very big deterrent from having more than one JVM.That said, if Harmony can pull the preverbial rabbit out of the hat, more power to you. Just understand that -- at least from my point of view -- the burden of compatibility is on Harmony, not Sun. Any Java program should run on either JVM with no problem. And in addition, I think it should be a goal of the Harmony project to see software writers continue to say that "ApplicationName 1.X requires Java <version>" not "ApplicationName 1.X requires Harmony Java <version>" There should be absolutely no difference in the way two are used -- only in issues like performance.

As we say at the ASF...

+1

Java should be Java should be Java

- geir

There are many wys that queens garage door repair helped me.  it made me a sensible and straight thgough things.

Whatever your point of view about whether this is a good idea, there seem to be 2 possible outcomes:

1) They manage to produce a JVM that works on at least some of the different hardware/os's. I leave what the exact definition of 'works' is to the reader, but I will use, 'isn't any worse than the equivalent Sun JVM' as my own personal reference point.
If this is the case, then we have another JVM to choose from, which can't be all bad.

2) This project doesn't produce a viable JVM. By this I mean a JVM that they can't produce a JVM on atl least one principal combination of OS/hardware. Again I will use the Sun JVM as a reference point for defining a valid JVM. If this is the case, we won't be any worse off than today as a result of this as we have the existing JVMs.

I think I am not in the minority when I say that all I want is a reliable JVM that works. It seems to me that this project has a small chance of producing something better than we might already get, and a reasonable chance of producing something unusable. An unusable JVM isn't a problem as we will stick with the JVM we are currently using. From my perspective, there is a tiny chance of an upside and no downside to this.

I don't wish anything bad on these people for wanting to work on this, I just can't work out why they expect anyone to be particularly affected by it.

Can someone please opensource opensource? It's getting so complex and political I do not understand how it works anymore ...

The fundamental reason why we don't see too many implementations of J2SE (including Open Source ones) is that J2SE hasn't had the commercial model of J2EE.

With J2EE, the commercial model has always been "Sun specifies, others implement". That approach forces the APIs to be interfaces rather than concrete classes. Modelling domains through interfaces turns out not only to be a great design approach but also a great breeder of implementations that can compete on quality.

With J2SE, on the other hand, Sun specifies *and* provides the technology. This leads to a Microsoft-like situation where the lines are blurred between interface and implementation, and the API reflects an approach of modelling through concrete implementations.

As proof, look at the cleanups that J2SE 1.5 has done. New interfaces like Iterable, Appendable, Readable, Closeable and Flushable are now being retrofitted onto concrete classes that previously just had the functionality implemented in them with no obvious reasoning. Now, not only is the API design cleaner, but user-defined classes can implement the same interfaces and have them interoperate with J2SE's core functions in a uniform way. That's power!

There's clearly a lot to be said for modelling domains through interfaces. Pity Sun didn't do it with J2SE. We'd have had the Open Source implementations (and a lot of commercial implementations too) a lot sooner, because it would have been obvious what to implement!

Regards,
Ganesh

Interesting,
I am not sure of what an opensource JVM could bring
especially for enterprise applications but here are some elements:

- it could lead to a true competitor to Longhorn/.Net with Linux/Gnome/Gtk-Java.
Linux distros and developers are reluctant to develop apps
on Java due to its non opensourceness.
Java could be the reference language to do rapid develop of applications on Gnome
See http://usefulinc.com/edd/blog/contents/2005/04/29-gnome-no-fun/read on Gnome
's lack of higher level language and lack of unity.
There could be managed apps built on Java bindings to GTK for rapid development and native apps in C
for core components.
But i doubt it would happen due to Novell's implication on mono and language religious(C#/Python/Java,C) wars
between Gnome developers....
- Ability to compile to native code on many platforms.
- Attraction of opensource developers and energy to the Java platform and consequently it would mean more opensource
frameworks/apps to the Java ecosystem.
- Addition of decent JVMs on more platforms than today although that with IBM/Sun/JRockit JVMs
many platforms are supported today.

Do you see any more benefits of an opensource Java ?

Anyway, this project is maybe too ambitious.

http://blog.blackdown.de/2005/04/20/blackdown-java-for-powerpc-status

.V

I am in favor if the product does not actually claim to be Java(tm). I think that's a waste of resources. I will explain.
An open specification achieves two things:

1) On the plus side, an open spec lowers the risk associated with the product (since you can theoretically switch vendors.)

2) On the minus side, an open spec constrains the product from solving problems effectively.

You put with 2) in order to get 1). That's the arithmetic when you are dealing with a commercial product. You need 1) because companies are greedy and/or go out of business.

With an open-source project, the risks are completely different. Therefore 1) is not needed and you can dispense with 2) also.

Of course, it's easier to rely on a spec that is already written, but the most exciting projects are those where the developers are allowed some freedom.

So I suggest you take the good ideas from the jvm, cli etc. but do even better. The people will migrate off java altogether. It can work.

Guglielmo

Of course, it's easier to rely on a spec that is already written, but the most exciting projects are those where the developers are allowed some freedom.So I suggest you take the good ideas from the jvm, cli etc. but do even better. The people will migrate off java altogether. It can work.Guglielmo

Which people do you think will migrate off Java? I'm afraid a lot of us aren't after too much excitement - we want something that is stable, reliable, portable and compatible. I believe that even something supposedly 'better' than Java would not have huge appeal unless it could provide the safety and security that many of us feel Java provides.

Which people do you think will migrate off Java?

It depends on what's in the new product. Of course, if it doesn't improve on Java, then nothing will change. Don't get me wrong, I think Java is a very good language. But it's not perfect.

I'm afraid a lot of us aren't after too much excitement - we want something that is stable, reliable, portable and compatible.

Stable and reliable always to happen with successful open source projects. Portable also, definitely: look at Linux. Even Apache.

Compatible with what?? If you mean vendor support, it happens eventually. For some uses the preferred platform for Oracle is Linux. Until recently that wasn't true. I suppose it takes time, but all worthwhile things usually take some time. Cloning the huge jdk 1.5 will also take time (a lot more time, in fact.)

>I believe that even something supposedly 'better' than Java would not have huge appeal unless it could provide the safety and security that many of us feel Java provides.

If you mean type safety, sure, why not?

Aren't there things you wish you had in Java? With an open source project we might be able to implement things much quicker. How many years did we have to wait for the entity bean spec to become usable? They had to wait for Hibernate.

Which people do you think will migrate off Java?

It depends on what's in the new product. Of course, if it doesn't improve on Java, then nothing will change. Don't get me wrong, I think Java is a very good language. But it's not perfect.

I'm afraid a lot of us aren't after too much excitement - we want something that is stable, reliable, portable and compatible.

Stable and reliable always to happen with successful open source projects.

Well, of course, because that is a circular definition, if you define 'successful' as providing a stable and reliable product. What about the unsuccessful ones?

Portable also, definitely: look at Linux. Even Apache.

It is easy to pick the most successful projects and assume that their qualities apply generally to open source.

Compatible with what?? If you mean vendor support, it happens eventually.

Compatible with existing Java implementations, and compatible between vendors.

>I believe that even something supposedly 'better' than Java would not have huge appeal unless it could provide the safety and security that many of us feel Java provides.

If you mean type safety, sure, why not?Aren't there things you wish you had in Java?

I don't mean anything as simple as 'type safety'. I mean that if you use Java your investment in your code is safe. You can get VMs from more than one vendor. You know that for almost all apps your code will be highly portable between VMs and between operating systems. That is what I call safety.

With an open source project we might be able to implement things much quicker. How many years did we have to wait for the entity bean spec to become usable? They had to wait for Hibernate.

There is a HUGE difference between adding POJO persistence to J2EE and re-implementing the entire J2SE, including a really high-performance VM.

I don't mean anything as simple as 'type safety'. I mean that if you use Java your investment in your code is safe. You can get VMs from more than one vendor. You know that for almost all apps your code will be highly portable between VMs and between operating systems. That is what I call safety.

I call it risk management. Again, the reason why you need that (beyond the rule which is etched into our brains) is that companies are not trustworthy. They go out of business, or try to force you to use their products. I say that the risk of using an open-source project with a critical mass in entirely different from that.

If you write your application in C or C++ and compile against gcc for 10 years in row, what risks are you running? There must be some, but gcc going out of business is not one of them.

I don't mean anything as simple as 'type safety'. I mean that if you use Java your investment in your code is safe. You can get VMs from more than one vendor. You know that for almost all apps your code will be highly portable between VMs and between operating systems. That is what I call safety.

I call it risk management. Again, the reason why you need that (beyond the rule which is etched into our brains) is that companies are not trustworthy. They go out of business, or try to force you to use their products.

That is why I prefer products that are available from more than one organisation. Like Java implementations. Open source does not remove the pressure to use one product. For example consider the variety of open source databases with differing degrees of incompatibilities and add-ons.

I say that the risk of using an open-source project with a critical mass in entirely different from that.If you write your application in C or C++ and compile against gcc for 10 years in row, what risks are you running? There must be some, but gcc going out of business is not one of them.

This is to do with the quality of gcc, and not necessarily anything intrinsic to open source. (I have had several interesting experiences with gcc in the past 10 years, with old code no-longer compiling after a version change, so this is perhaps not the best example).

This is to do with the quality of gcc, and not necessarily anything intrinsic to open source. (I have had several interesting experiences with gcc in the past 10 years, with old code no-longer compiling after a version change, so this is perhaps not the best example).

Steve I think that was not the point. The idea is sort of like this: your code is C++, right, now ten years from now you'd still have g++ available, whereas Kai sold its compiler division (if not all of itself) to Intel. Replace Kai with Sun , Intel with /dev/null, C++ with Java and you'll see what he means: if Sun decides to stop working on Java for whatever reason, having an open source implementation would still provide the Java language and your project a chance to survive. I know there's more than one Java VM provider and a whole bunch of C++ compilers, indeed. The point is still valid though, if you think about Smalltalk: a kid fresh out of college now has a chance to use and deploy Smalltalk applications should he choose to because he does not depend on the one or two major vendors that sell Smalltalk environments [for prohibitive prices] to either learn, develop nor deploy his application.

(Steve: the following is not addressed to you)
I fail to understand the violence of the comments against this project.
Firstly it denotes ignorance on the subject; the Classpath and GCJ and Kaffe and SableVM have been around for years. Nobody felt compelled to vomit narrow minded thoughts and call people "fuckface". Our favourite nazi was comfortably sleeping at his desk, occasionally waking up to reiterate his genitalia-and-handicapped-kids routine.
Secondly - hey, don't like it? don't use it.

I thought the battle was .Net vs. Java/J2EE.

I am beginning to learn that the J2EE community likes competing itself instead of working on a solid J2EE and J2SE standard platform that really stands out as a development platform.

Really, I don't see a need for this project: If you don't like J2SE or think yo can do things better, feed it in as a JSR and make your work part of the "real" J2SE platform.

Open Source is good because it comes with innovation and definitively is a space for people who like to think out-of-the-box. But would you also build a car from ground up just to replace a flat tire?

Frank

I think this comes down to "is it worth it".

I'm sure all participating here understand the value of open source, we use open source, and many of us have contributed to open source projects. The computing world is a better place thanks to open source. I hear all about the virtues of open source in this very thread, but I think it's tiresome because we all know those virtues, given the TSS.com audience.

We aren't at the beginning stages of Java (1995?). Perhaps then a compelling case for open source Java could be made. But at this time, you can run Java on an amazing variety of platforms. Admittedly many don't come with Java out of the box, but it can be had for free. The source code for the Java libraries is available to us all, and decompilers work well for those few Sun pieces that aren't available. The JVM source code isn't available but it wouldn't be helpful anyway since 99% of the time we Java developers want to see how a standard class library operates since that's primarily what we interface with. So what we have today is not a complete proprietary platform, not something completely open source, but something in the middle.

If an open source solution were introduced into this marketplace, it would play second fiddle to Sun's implementation in terms of compatibility. Sun's implementation would dictate the "correct" behavior, even bug-for-bug. So there is serious doubt if an open-source solution could offer a compelling advantage (say speed). I think we'd all like a single open source dominant VM that would dictate compatibility; there are some bugs many of us would want to fix instead of begging Sun to fix via their bug parade... but that just isn't going to happen. It's too late--assuming there ever was an opportunity for it to have happened in the beginning. The open-source Java could make headway on platforms where there isn't Java already, but I see little demand for that given the coverage Java commands today.

In Summary, I just don't think it's worth it to develop an open source Java implementation -- at this stage. It would take too much effort for the little gain to come of it over what we have now. Surely the talent and effort of those who propose to build it could better be served elsewhere.

Cheers,
  Dave Smiley

Such enormous expectations...

I agree with the basic tenet that this seems like a waste of time, but OSS is all about reinventing wheels.

There is no reason that the Apache runtime has to be a homerun right off the bat. It DOES have to be compatible. Specifically, it much be compatible with everything that they implement.

For example, they could implement all aspects of the JVM and the class library that has nothing to do with Swing or AWT. They can punt completely on those aspects and have a viable system for running Servelts and J2EE apps right off the bat.

Their JVM does NOT need to have class winning performance, but it must have predictable and usable performance.

There are a bunch of folks writing stuff in Python and Perl and what not everyday, and none of these are as performant as Java is today. So, the JVM needs only be as performant as Python, Mono, etc. to be competetive in the OSS space and to be used by OSS people. Their primary burdens will be threading and GC, then the JIT (but even a crude JIT can work if the threading and GC are efficient).

There's Enterprise Java and everything else Java. Not everyone is pushing their hardware to the limits, not all software has to be as fast as possible for it to be usable.

Apache must be compatible, that's the bottom line, but it doesn't have to be complete to be functional and useful.

The Apache team could well be bootstrapping off of something like JRockit, and need only have to develop the class library.

So, while it may seem insurmountable, it need only be done in stages, and those stages can be quite useful.

1) Build basic JVM interpreter to start work on GC and threading
2) Build javac compiler to compile into bytecodes
3) Start work on necessary java.* class library enough to support the compiler
4) self host compiler on your own JVM (start eating your own dog food).
5) port Ant, Jakarta Commons, and Tomcat.
6) Improve JVM

When I say "port Ant..." I mean, fix your JDK until these compile and work out of the box (don't change Ant or Tomcat...).

Save for being able to create graphs, that alone meets a HUGE segment of the small Java server market.

When your distro can run Tomcat (a non-trivial application), you're pretty far along and you're useful for a lot of people.

So, it doesn't have to be a home run out of the box, they can make incremental steps.

I agree with the basic tenet that this seems like a waste of time, but OSS is all about reinventing wheels.

That is _such_ an idiotic statement... The rest of the comments are quite on the subject though. I'm sure you already know what you're describing there is where Classpath+GCJ/Kaffe already is today, even further actually.

http://www.activewin.com/awin/comments.asp?HeadlineIndex=29527&Group=1

So... how long before Linux and JRE are on it?
3 months is my guess.

Sept.!

.V

Why on earth should everything be Open Source. I mean come on.. if I don't like Sun's implementation of java.util.List, can't I create my own? I never felt like Java lacks something, Sun has given it a decent shape and wait a sec... its not Sun alone its called the Java Community Process.
I don't see any reason why anyone would dump java and pick harmony.

I wonder ... if no Swing? SWT now!?
it used to suck, but SwingX/JDNC fixes it.
w/ IBM behind the scenes.... I wonder.

I hope not, but it may go that way, lots of people gave up on Swing. I don't like the native part of SWT. And what of jGoodies?

oh no. that's a dager. SwingX is better then SWT (but I understand, no one want's to date the X-wife, even is she loses weight)

Can we dump the corba package in J2SE at least? make my download smaller. That should be depreacted.
And dates? Use joda time package.

he, he, he. Since each applciation allready ships it's own JRE (like limewire ), we have the source, we can do as we please. Fix the classloader too. JNLP patch.
Dell can include Dell branded Harmony on their machines.

this is deep. Like Wyblur Pascal code would not compile w/ Turbo Pascal. eeeeh.

Maybe go for ANSI cert. for Harmony.

Sun never made Java cross platform deployable (WebStart bugs) so http://www.limewire.com/english/content/downloadfree.shtml (JRE + App) it's now coming back to bite.

This is current situation, muti JRE:
http://www.javalobby.org/java/forums/t18329.html
It can't get worse than that.

.V

Vic, you're talking in your sleep again.
As it's been said already, by people a bit more coherent, you _cannot_ make a win/win decision on what you should drop officially from the JRE. We do use Corba and SWT, you don't; think about it.
The only valuable proposition - at least the way I see it - is to be able to bundle stripped-down runtimes with the application download.

We do use Corba
...
 be able to bundle stripped-down runtimes with the application download.

Corba application on the client side? In J2EE yes, but give me an url of a client side corba?

Yes, a striped down runtime to download w/ app.
 or fix web start classloader so it can share jre.

.V

Vic, I don't have to give you anything.
The point in case you've missed it is that you cannot just go around picking one use case of the JRE and decide what stays and what doesn't.
The stripped down bundled JRE is forbidden.

Like many who have contributed to this thread of discussion, I too question the wisdom of the proposed open source project. The existing solutions (JVMs) seem fine and not a limitation to various cutting edge efforts like Spring, Eclipse, etc… And in time Sun may very well spin-off Java into a semi open source organization.

However, it has been over ten years from the time of Java’s original conception.

A "Next Generation Java" is a much more likely area Apache could really make a difference and excel at. Let go of direct reverse compatibility: it is too much of a boat-anchor into earlier paradigms. Make something that is SIGNIFICANTLY better and probably a bit different.

Steven Punte
CTO
JXReports

Like many who have contributed to this thread of discussion, I too question the wisdom of the proposed open source project.

I am just wondering, just how many JVMs are there?
Another one can't possibly do any harm.
Don't need it,don't use it.
If some people are in the process of making an 'open-source' java(God knows what that means,java is open enough for me),let's stand back and watch the fun,Maybe something good will come up from this effort.

A "Next Generation Java" is a much more likely area Apache could really make a difference and excel at. Let go of direct reverse compatibility: it is too much of a boat-anchor into earlier paradigms. Make something that is SIGNIFICANTLY better and probably a bit different

We have it. It's called Java 5

People, please. The damn JVM is already free. One can obtain the source code. There is no need to go splitting Java up for your own vanity. Jesus, there's already a choice of implementations. I am, have always been (since before this Jakarta bullshit), and always will be a big fan of the ASF and many of it's projects, but this is vanity, pure and simple. Who asked for this? Who wants it? Who needs it? Will it need reams of XML configuration? What's the point?

Just when we're really realising the potential of bytecode and what Java can do, you guys have to hit the refactor button and move the goalposts. Apache needs to stop the 'pump out as much shite as possible' routine and concentrate instead on a smaller number of /good/ solutions. Well engineered solutions. Solutions that /aren't/ written in compiled [email protected]%!&$g-hell and documented by copulating dogs with pencils stuck up their arses.

I urge one of the more right-thinking people at Apache (I know you're still there...) to veto this or whatever the hell it is you do there - this has got to be stopped.

It pains me to say this but this is one project I hope to see fail, fast.

Sorry. :(

(Freelance developer and consultant specialising in enterprise open source / ASF solutions. Although why, I wonder more with each passing day).

I'm not too sure about how this will benefit to us, for various reasons :

- compatibility : we already have trouble have apps 1.3/1.4 running on 1.5 because of slight changes that were made in the implementation...so imagine another valid JVM, that will also evolve on its own, then compute the possibilities : A's 1.4 to A's 1.5, B's 1.4 to B's 1.5, A's 1.4 to B's 1.4, etc...

you'll end up in a total nightmare...

- function coverage : what about SWING support for instance ? or API such as Drag&Drop, i18n or others ?

- ego and personnal problems : no offense to you guys who are trying to set up something nice, but there is something I wonder : how do you think a handfull of motivated programmers will achieve to make, in a timely manner, something that is 100% compatible, has the same function coverage, and works even better that sun's ? in other words, how do you think 20-30 regular commiters will produce something better that hundred's of developper at Sun ?

In one hand I got something produce by the entity that specifies J2SE, something that has been tweaked carrefully for a long time, that is the de facto implementation reference, that is free (no cost) and now that is opened enought (if I see a bug, I can access the sources, and patch it...which is enough for a lot of people).

On the other hand I get something that is just a project, something that is new and that will require a lot of time to reach at least the same quality as current Sun JVM, that will also be free and totally opened...

Given the time it'll take you to get working 1.5 implementation, we'll be in 1.6 by the time, and you'll end up with the typicall "one version behind" lag inherent to any project trying to follow a well established standard...

When I read "oh it'll be quicker to execute thant sun 's VM" or " yeah we'll even be able to tweak it and add spanking new features" I wonder if people realize how much work it's gonna take to have a 1.5 compliant thing working at least as well as Sun's VM. Add even more time to allow in depth tweaking (and I wonder if this could be possible given that if obvious tweaks could be made, Sun would likely already have them)...by the time this will be finished, we may be one or two major version ahead...

Provided Sun's VM is free (and there is no sign at all that this will ever change), given it's now freely patchable, given you can access code, which mean you can see how things are done, and then this make you totally free to implement your own way and make a jar out of this ("you don't like the way ArrayList are implemented ? fine, you can design you own, make a jar out of it...Sun's VM allows that)
, I don't see the point of a new VM, that given what I said will just lag behind, unless big actors like IBM or BEA put a lot of efforts in it...

what a detailed post ....wow

<a href="Villas" rel="nofollow">http://www.holiday-rentals.co.uk/Spain/r58.htm">Villas in Spain</a> | <a href="Ibiza" rel="nofollow">http://www.holiday-rentals.co.uk/Spain/Ibiza/r116.htm">Ibiza apartments</a> | <a href="Apartments" rel="nofollow">http://www.holiday-rentals.co.uk/Spain/Costa-del-Sol-Malaga/r355.htm">Apartments in Costa Del Sol</a>

what is the 'CLEAR' need for a new JVM implementation??? enlighten us please.
apache is quickly becoming a hog - that's what it is. reminds me of ayn rand's fountainhead.

great blog, i just have no words.:)

<p><a href="China" rel="nofollow">http://www.chinaitinerary.com">China travel</a><br>

<a href="China" rel="nofollow">http://www.tourochina.com.au">China tours</a></p>

http://www.chinaitinerary.com

Guys, I just want to ask is is safe to use old versioned Apache?  Whch are more stable the new one or the old one?

The initial code base from which to create this project is from the commercial product called IBM Cloudscape. The history of this product is that it was developed at Cloudscape Inc. starting in 1996. The Cloudscape product was purchased along with the Cloudscape company by Informix Software in 1999. In 2001, IBM purchased the database assets of Informix Software, including the Cloudscape product.

IBM plans to contribute the Derby code base, test cases, build files, and documentation to the ASF under the terms specified in the ASF Corporate Contributor License. Once at Apache, the project will be licensed under the ASF license.

 

Cheers,

George

 

I meant executing code faster. Now I'll qualify what I'm about to say by stating that I'm not familiar with the performance comparison history of Sun's jvm vs. others. I am simply basing this on a single personal experience. If my experience is not normal, please correct me.

Where I worked up until recently we have always used sun on xeons. We have always found that performance suffers when hyperthreading is turned on so we leave it off. We were looking for ways to improve so we gave ibm and bea a try. Both resulted in very significant performance increases for both an ejb based data repository application and another that is more data throughput: lots of xsl transforms with xalan and queuing messages in the db. I think that our applications are generic enough to conclude that we weren't benefitting from some fluke critical piece that sun happened to not implement well.

In this case, ibm's didn't seem to care if ht was turned on while bea's definitely benefitted from it. I was also told (and again, not claiming any definitive knowledge here) that sun has optimized largely for amd while bea has paid special attention to intel.

non profit cpa

Well I think the ideas of this project is great. But there is a lot work required to be done to accomplish goal. 

 

Let us know if we could be of any help regarding this project as we love to contibute to open source proejcts.

The Cuillin Collective