On May 8, 2005, at 7:03 PM, Sven de Marothy wrote:
Hello all, I've contributed a line or two of code to Classpath, and so obviously I'm pretty interested in seeing a free implementation of Java, and I'm all for cooperation.
Yay!
But, I'm going to nasty and critical now and take a 'devil's advocate' view here, just to get things clear for myself..
The "motivation" in the proposal lists Classpath, Kaffe, GCJ, etc and states:
"All of these efforts provide a diversity of solutions, which is
healthy, but barriers exist which prevent these efforts from reaching a
greater potential."
Could you give some examples of barriers? In my experience our #1
problem is that the implementation of the class libraries is incomplete.
I think the biggest barriers are various licensing issues, the fact that there isn't a "full stack project", and completeness.
None of these are aspects that I consider any kind of failing or criticism. We've always had licensing differences and continue to work on the, we're happy to give the "full stack project" a try, and "incompleteness" is the normal state of affairs until "completion" is reached - any project is incomplete until it's done. A project near and dear to my heart, Geronimo, is incomplete (as of now...)
All these projects use the GNU Classpath set of class libraries, in harmony with the Classpath license (GPL+exception).
How does starting a new project under a different and incompatible license (Goal #1 in the proposal) help?
We're starting a project to do a full tested, compatible implementation of J2SE (which will need a class library). I don't know of any projects out there that are doing that. Yes, we *write* software and license it with the Apache License, but we always like to *use* software from elsewhere that is under acceptable licenses because - well - we're lazy.
Goal 2 in the proposal is to "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".
GNU Classpath already has a stable and documented VM interface and is already being used by a number of independent runtimes of radically different types. I think there already is lots of independent innovation.
It was my understanding that there was room for further work here, as well as intra-library modularity. VM modularity is going to be important too, and we probably have to consider the two subjects concurrently.
We're trying to get lots of people that have an interest and understanding in this issue to talk about it here. I'm really interested in how the problems you've solved resonate with the problems others have, and if there is anything we can learn from each other.
So much for points a) and d). Then there's b): "a test suite for interoperability testing of the modules"
Classpath already has testsuites; Mauve and Jacks.
IIRC, Mauve tests the Java API, and the test suite imagined above is to test the modular components - to see if implementations of modules support the interfaces they claim. This isn't the Java API. As you say, there is Mauve, and there's always the Sun TCK as well. I'm fine with using Mauve (and contributing to Mauve) until TCK testing time.
Remember, the goal of modularity is important, and we wanted to be sure that modules interoperable. The only way (off the top of our heads) that we could be sure things would work is a test kit.
Does it have to be here at the ASF? No - we're happy to use tools from elsewhere. JUnit (for example) is very popular w/ ASF Java projects. <plug_for_cedric>TestNG will probably be too someday</ plug_for_cedric>
As for the IP issues raised; Classpath is clean-room.
Great. Everything we do here must be clean room, and any dependencies we have on external software - and as we are fundamentally lazy people, we want to use things from elsewhere rather than re-write - would need to satisfy our usual requirements for distribution and licensing, and we'd probably add more inspection, such as clean-room-ness. We feel responsible to our downstream users for what our distributions contain.
So, in summary I'm wondering:
1) The proposal is proposing to do essentially the same work we've done,
only under the Apache v2 license. How is this supposed to solve our
problems? Because Apache can do everything better? ;-)
No. We don't do _everything_ better. ;)
We're going to need a class library to include with our full implementation, just like we'll need a VM. So far, no decisions have been made on what to use and from where.
Remember, the goal is to create J2SE 5. That isn't GNU Classpath's goal (nor Kaffe's, GCJs, etc...)
2) If not, and Harmony is to make use of Classpath, what's in it for Classpath?
I don't understand the question. What does GNU Classpath want in exchange for being used? Nothing, I hope.
The "Apache stamp of approval"? More developers? Something
like 15 different VMs are already using GNU Classpath, is yours going to
make such a big difference?
There is no "Apache stamp of approval". Apache makes no technical decisions. Everything like that (modulo legal risk) is pushed down to the communities doing the work - the people that make the decisions are those working in the projects. *We* (you, me, everyone else) make the technical decisions.
The only time Apache will step in is if there is a legal problem, such as questions about ownership of a piece of donated code or such...
3) What, exactly is wrong about the GNU Classpath license? The proposal
and several posts on this list don't seem to specifiy more than "Not
Invented Here". GNU Classpath is being used by projects licensed under
the GPL, LGPL, CPL the Intel Open Source License, etc.
I'm game - what *is* wrong with the GNU Classpath License? :)
I really don't want to debate licenses now. I'd rather discuss technology.
The ASF has some rather clear rules about what we distribute. We'll have to distribute whatever we choose as part of the full implementation. This isn't like using glibc or something, where that's an implementation of a standard interface that you can expect to be found on the various target platforms.
There's lots of interesting discussion to be had here - and we have to have it - but I don't want to declare defeat before we even get started.
So what's so special about Harmony that it needs a ASL class library?
It doesn't necessarily need a class library under the Apache License - just use a class library under a license that complies with our use and distribution requirements.
It's clear we're all not going to see eye-to-eye on license philosophy. I'm hoping that we can find ways to work together where those differences don't get in the way of doing something productive.
Geir, you do know Janteloven, don't you? ;-) (Reference for non-scandinavians: http://www.lysator.liu.se/nordic/scn/faq26.html )
I actually don't. :) I am US-born, and was raised here in the US all my life. Thanks for the link... I'll read on the plane.
Ok, and before someone flames me, again, that was all conciously provocative.
I am not trying to sow any dischord here or be nasty to the
ASF. I'm all for cooperation, I'm just trying to figure out where people
stand.
These are good questions, but they do presume a bit. I encourage you to keep going with this so we can learn more about each other. Thanks for spending the time on this.
geir
/Sven
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
