Sun Java and GPL

Mon Nov 13 10:41:00 GMT 2006

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.