harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Wielaard <m...@klomp.org>
Subject a harmonious and inclusive community
Date Fri, 22 Jul 2005 23:59:05 GMT

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

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
Andrew Hughes really worked hard to document our current interfaces as
now published with the latest GNU Classpath release at:
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.



View raw message