Hi, On Fri, 2005-07-22 at 10:18 +0100, Tim Ellison wrote: > It seems that all roads lead back to the discussion of licensing and > philosophy. Even that has degenerated into name calling which is > unhelpful for building a harmonious and inclusive community. > > While I understand perfectly that unifying the existing efforts in > J2SE-space is a goal of Harmony, I believe we need more visibility on > this list of the progress and successes in this space. Without such > visibility we appear to be going in circles, and many people who > initially expressed great interest in the project will walk away.
Thanks for trying to move forward with a positive message. I was indeed about to give up, not really because I personally feel excluded, but because we seem to completely fail to reach out to the 50/80 people working on the existing free efforts. And I cannot do it without the support of these people. They have worked for years on all aspects of what Harmony wants to do. They are very bright, smart people. And they are clearly proud that things like Tomcat, Eclipse, Jonas, Lucene, Axis, etc and all those other large free programs actually work now on the free systems. The community around harmony seems to sometimes dismiss some of this work. And I do feel we won't have a healthy community if we cannot bridge the gap with all those existing hackers (some of which already work on all this stuff full time). Some of the people around the GNU Classpath projects really don't feel that they are part of Harmony. And I do try to bring them in. But when some of these people tried to get a feeling how/what people thought about what they have been working on for the last few years there wasn't any real technical feedback. The only feedback given is that it wasn't distributed under the Apache License. Which a lot of people interpreted as being offensive and hostile. My mistake was that I kind of tried to show (probably too aggressively) how annoying and uncooperative that is. Almost every existing project has a problem with the Apache License just because it isn't compatible with the GPL. This is infuriating (to both sides!). I don't believe I got my point across and I believe people now think it is all about licensing. But it really was about dismissing (not properly investigating) the work already done this last decade by other free software groups. And those groups do have some really nice ideas in their designs. And it is backed up with real free code and real free runtimes on very different platforms that use it. And from working with these people for some years now I know they like comparing and discussing technical details. Show their own strengths were they can and cooperate on common code when it makes sense. Please investigate what people have been working on all these years, and please give real technical feedback. Maybe the designs of Kaffe, GCJ, IKVM, JCVM, JamVM, JikesRVM, SableVM, JNode, Kissme, CACAO, etc. are really bad. And maybe they are really completely unportable to different systems/platforms. But if so then I am sure the designers would like to know about that. Lets try to engage them into a discussion. And there are often interface design discussions on the classpath mailinglist, please monitor that list (http://lists.gnu.org/archive/html/classpath/). Andrew Hughes really worked hard to document our current interfaces as now published with the latest GNU Classpath release at: http://www.gnu.org/software/classpath/docs/vmintegration.html Please discuss what seems impractical in this design for adoption of GNU Classpath as core library set. Then I will stop mentioning the war^Wlicenses. I talked to a couple of people who assured me that people really want to work this out as soon as possible. I'll assume it will for now. And just concentrate on the technical issues, goals and the roadmap. > Hopefully we can all discuss something like the relative importance of > tools and capabilities in an SDK (javac, javadoc, apt, browser plug-in, > etc), which of these exists and what order to implement those that do > not. That is a good thing to start with. Lets go over the list: - compiler: Several candidates. - jikes http://www.jikes.org/ Fast an pretty compliant source to byte code compiler written in C++. Ideal for bootstrapping a system quickly. - ecj http://www.eclipse.org/ The compiler of the Eclipse project. Written in java. Some people are surprised that this compiler can be used stand alone. But it actually is the default compiler on Fedora Core systems now. (Compiled with gcj no native code to make it as fast, if not faster then jikes). Already supports most of the 1.5 language constructs. - gcj(x) http://gcc.gnu.org/java/ This is not just a source to byte code compiler, but also a gcc frontend so that it can produce native code. gcjx, the next generation gcj, will also be able to generate jni and cni header files from source. And will support the new 1.5 language constructs. (Tom Tromey, who is on this list is the main developer, so I will let him hype it some more.) For GNU Classpath we support compiling with the latest releases of all the above. We try to make sure that we don't depend on any of these compilers, although gcj is the default. When a bug is found in the latest version of any of the above we add a workaround (and clearly mark that in the source, so it can be removed when the compilers get fixed) to give people the freedom to choose their own preferred compiler (on arm for example jikes has some problems, but gcj works fine). The GNU Classpath generics branch can currently only be compiled with ecj, but gcjx is catching up. - javadoc replacement. - gjdoc http://www.gnu.org/software/classpath/cp-tools/ This is the GNU documentation generation framework for java source files. It should be command line compatible with javadoc and comes with a full Taglet and Doclet interface. We use it to generate the documentation on http://developer.classpath.org/doc/ (Julian Scheid does most of the work on this these days.) There is also texidoclet A "doclet" for converting comments into GNU TexInfo source. - browser plug-in. - gcjwebplugin and gcjappletviewer http://www.nongnu.org/gcjwebplugin/ Despite the name it isn't gcj specific. I have been told the name actually stands for "Groovy Cool Jive". It works nicely with mozilla. It does depend on the GNU EmbeddedWindow awt extensions that GNU Classpath provides. (Michael Koch and Thomas Fitzsimmons work on this. Sven de Marothy is writing Qt-AWT-peers to make embedding into konqueror on the KDE platform nicer.) - jar replacement. - fastjar as shipped with gcc. - kaffe jar. Both seem pretty complete. What seems to be missing is a good testsuite for all the corner cases. - javah replacement. - gcjh as shipped with gcc. Written in C which makes bootstrapping easier in some cases. - kaffeh as shipped with kaffe. There were recently lots of bug fixes here. Written in java. - javah as shipped with GNU Classpath Tools, written in java. - gcjx (as mentioned above) will be able to generate jni and cni headers from java source files. Written in C++. - native2ascii replacement. - Kaffe, GNU Classpath Tools and gcc have this. All written in java. The one that comes with gcc is called jv-convert. - javap replacement. - GNU Classpath Tools comes with a javap implementation in java. - GCC comes with jcf-dump written in C, which is a bit more powerful then the one in GNU Classpath Tools and is a really nice tool when bootstrapping stuff. - serialver replacement. - GNU Classpath Tools comes with a very simple one written in java. - rmic and rmiregistry - GNU Classpath Tools comes with grmic and grmiregistry. (These were recently rewritten by Archit Shah) Both are also shipped with gcc and kaffe. I probably forget something. But I these are the tools that I know of from the top of my head. We don't have most of the sercurity tools yet (jarsigner, keytool and policytool), although the support classes for these are already available in GNU Classpath so if written in java these should not be such big tasks. Cheers, Mark
signature.asc
Description: This is a digitally signed message part
