Re: Sun Java and GPL

[Andrew Haley <aph at redhat dot com>]

Per Bothner writes:
 > Mohan Embar wrote:
 > > Hi All,
 > > 
 > > This question is either extremely dumb or extreemly
 > > obvious, and I'm not sure whether it's been asked before,
 > > but what is the future of gcj and Classpath, especially
 > > on Linux, now that Sun is GPLing its codebase?
 > 
 > I don't think it it is either dumb or obvious.  But note that Sun
 > isn't GPL-ing *all* of its codebase.  From the Tim Bray interview
 > here http://blogs.zdnet.com/Burnette/?p=200 it is implied there
 > will be holes in the class libraries that Classpath will need to
 > fill.
 > 
 > It seems plausible that we would merge in much but not all of Sun's
 > code as Sun frees it.  gcj and ahead-of-time-Java is still
 > valuable, depending on the application, it may need less memory
 > footprint, faster startup-time, or faster execution, because we can
 > optimize ahead-of-time code better, at least potentially.

Potentially, perhaps, but meeting all the finer details of Java's
speciication is hard with fully static compilation, and we've had to
add a lot of indirection to make it happen.  In may ways, the
specification assumes dynamic compilation.

 > Can we combine ahead-of-time compilation with Sun's HotSpot
 > technology?  Is it worth attempting?  I don't know.
 > 
 > We might want to reconsider the decision to use ecj to compile Java
 > source - perhaps it now makes more sense to use Sun's javac.  But
 > possibly ecj is preferable - that is partly a technical question,
 > partly a licensing/political one, and partly one of pragmatics.

ecj is fine.  Besides, if someone wants to put some other source
compiler in there, why should we care?  They're nearly
feature-identical and they're both free software.  The Sun version,
being GPL, may be linked rather than exec()'d, but I don't know if
that's useful.

Another nice thing we have is CNI.  Writing JNI methods is a pain, and
the nice way we play with standard linkers, assemblers, loaders and so
on is a benefit, particularly with Link-Time Optimization in the
future.

The standard way to do native integration for high-performance
implementations seems to be adding intrinsics to the VM to avoid the
overhead of calling native methods.  We potentially have something
much better than that.

Andrew.