GNU Classpath is a project to create free core class libraries for use with virtual machines and compilers for Java. Changelog of version 0.14: Base core class library for upcoming GCC 4.0 and Kaffe 1.1.5 releases. ImageIO support through gdkpixbuf, many new nio character encoders and decoders, fully automated class documentation generation, generic VMStackWalker support for runtimes, many bugfixes, optimizations, and new Swing support.
GNU Classpath 0.14 Released
Submitted by Mark Wielaard 2005-03-17 Java 11 Comments
With GCC 4.0 on the horizon, it’ll be interesting to see what kind of speedups GCJ gets
It is being a good year for java in the opensource world. Eclipse compiled natively included in coming fedora and ubuntu releases (though I will believe in the real progress of this when they get to compile it completely from source and not from jars, and they get support for the java debuging interface in gcj so that you could use the IDE debuger. I think the new gcjx will make the former possible eventually).
I am also looking for the progress of free swing, being a NetBeans user mainly, I would like to see it run natively (eclipse envy?).
I also like the progress with free interpreters like jamVM and SableVM, does anyone know if any of them have support for java debuging protocol? Any plans?
I gave a quick look around the classpath page and couldn’t find any more information on swing. Is this using SwingWT, or something different?
They have come a long way. In combination with Java-GNOME, it looks like I can finally write GNOME applications with what they have accomplished. I am delighted.
Answers to some questions in the comments:
The major focus for gcj in the 4.0 timeframe was
not performance but instead the new binary compatibility
ABI, which makes it simpler to do things like precompile
Eclipse (or jonas or derby or …). We’ll probably have
some better java-specific optimizations starting in 4.1.
As far as I know, nobody has tried NetBeans on the Classpath
swing yet. I would suspect that not enough of swing works
yet, but it would be interesting to get details.
As I understand it, SableVM has implemented some of JDWP.
Etienne posted on the Sable list about this recently.
The Classpath swing implementation does not use SwingWT.
It is “plain old swing”, written in Java and running on
top of the Classpath AWT implementation.
Pretty nice! Especially the fact that AWT is getting far enough along to run Swing on top of it. I have to admit, I’ve been getting more intested in Java recently. I haven’t really used it since the early 1.2 days, and this seems like a good reason to get myself back up to speed.
in java so that they can fix any problems and get a more standards compliant runtime?
Nope, not SwingWT. It’s real Swing, you know, the grey-purple one. They’re implementing an OSS Swing, which is a whole lotta work.
Will the visibility option in gcc 4 be used in gcj? I think that if it can help C++, it can also help Java a lot (and in Java there is no need for extensions to the language to define the visibility of a method).
Short answer: No.
Long answer: The license changes in JRL and JDL, two of the three announced licenses compared to SCSL are rather minimal. They are essentially SCSL clones without cruft that’s not specific to their use domain. So they are useless for anyone working on free runtimes, as they are still non-free, and highly ambiguous. If you intend to hack on a free runtime, run, don’t walk away from those licenses.
The third license, JIUL, has been announced in rough form by Sun as well, and sounds like just another SCSL-clone, as well. Nothing exciting or useful there.
In any case, I don’t think Sun’s code is really relevant any more any way.
It would have been interesting a few years ago, while there were still significant contributions Sun could have made, had they desired to do so, and steered the development of the free platfroms, but now I’m afraid digging through a hypothetical large source code dump from Sun would be more of a waste of time for me than anything else, unless it is really good, well documented code.
Short answer: No.
This is a short, but incorrect answer.
From http://java.net/jrl.html :
18. Does the JRL prevent you from being able to create an independent implementation of J2SE?
The JRL is not a tainting license, and includes an express “residual knowledge” clause. Under the JRL, merely looking at Sun’s code does not prevent you from being able to create your own independent implementation of J2SE, and in any event, you can terminate the JRL at any time for any reason. So, yes, you can look at Sun source code and then later on go and work on an open-source J2SE implementation.