Java issues, and Microsoft.NET compatibility (was Re: [DotGNU]Choice of bytecode spec (was: Support Java for .GNU))

[Bradley M. Kuhn]

There has been some talk about whether or not the Java platform should be
considered for DotGNU, and some talk about whether or not we should
deviate from Microsoft.NET's ECMA specifications.  I would like to address
the Java issues first, and the specification issue second, as it relates
in some interesting ways.

First, let me clear the air on Java licensing concerns.  The Java platform
does indeed have a (nearly) complete Free Software implementation, which
you get by putting together GCC 3.0, Kaffe, Classpath, and (jikes|Kopi)
together.  The only thing missing, AFAIK, is the Java 2.x SWING libraries,
which are being worked on.  So, the issue of licensing isn't a problem.
We have a full Free Software system that's almost entirely GPL-compatible
to work with.

The issue, though, is technical.  I can speak with some authority on this.
For the past (mumble mumble,
not-wanting-to-admit-how-long-but-more-than-2) years, I have been trying
and mostly failing to port Perl to the JVM.  Before my tries, Larry Wall
even gave his hand at it and determined it was pretty damn hard.  Through
Kawa [0], I finally found a solution that I believe is workable, it's now
just a Simple Matter Of Programming.  (Read my thesis for long, gory,
torrid details, if you really want.  ;)

The VES and CLI that Microsoft has proposed isn't perfect, but it's a big
step up from what the Java platform provides.  It's true that Microsoft's
biggest target with Microsoft.NET is not the Free Software Movement, it's
SUN.  (Recall that internal development on Microsoft.NET started when the
Free Software and Open Source Movements were barely on Microsoft's radar
screen.)

Microsoft built the killer application for language integration.
Microsoft hires some of the best minds in the field---basically all the
great minds who hold money as a motive (which, I guess is only a minority,
but enough).  They designed a system that is not prefect, but pretty good.
Microsoft may be unfriendly to freedom, but they aren't completely
clueless technologically.

Trust me, if I thought it could work, I would be pushing a Kawa/JVM [0]
based solution for DotGNU.  In fact, in the days before DotGNU and Mono, I
had been talking with RMS about starting a project to match Microsoft.NET,
based on Kawa/JVM.  RMS finally convinced me that to win, we'd have to
make a system that was API-compatible with Microsoft.NET, which would
include using their VES, their CLI, and any other specification that we
could get our hands on without putting ourselves in legal jeopardy.

Now, that's not to say we shouldn't keep an eye out for integration at
every step.  If we could build DotGNU in such a way that would could port
the Kawa infrastructure to it later, so that you could use systems based
around Kawa with our bytecode interpreter rather than a JVM---hey, that
would kick some major ass.  When it doesn't slow us down, we should make
design decisions that can get us there.

But, IMO, we can't make these pie-in-the-sky ideas a reality at first.
The first order of business is to make something that works more-or-less
just like Microsoft.NET for the developers who are adopting the
technology.  Second, we build the services and applications that run on
Microsoft.NET as Free Software, to get adoption by users.

Of course, as we work through the process of applications and services,
there will be times when the "Microsoft.NET way" is a threat to the users'
privacy and freedom.  In those cases (and only those case, IMO), we should
deviate from Microsoft.NET and make the system protect freedom and privacy
instead.


But, for the developer tools (bytecodes, languages, CLI, etc.), we should
be compatible.  Of course, we should port every darn language we can think
of to the system, so that developers can take their pick for DotGNU:
Scheme, Perl, C, C++, Java, C#...  You name it, we should make it work on
DotGNU, but, all the while adhering to the ECMA specifications.


[0] Kawa is an intermediate compiler representation for VHLLs.  It's a
    tree-based, Scheme like system.  It basically does for dynamicly,
    late-bound languages what GCC's internal tree representation does for
    static and/or early-bound languages.  It's a marvelous hack, and if we
    could change it in such a way that it is portable to other VMs than
    the JVM, that would be amazing.  In fact, I still plan to put a little
    hacking time into finishing my Perl port to Kawa, because I really
    like the infrastructure.

    See http://www.gnu.org/software/kawa/ for details on GNU Kawa.

   -- bkuhn

pgpP0TOiFxisS.pgp
Description: PGP signature