The GNU Classpath project is proud to release version 0.13. New features include a new inetlib which offers HTTP/1.1 support, and added FTP. java.beans has been updated to 1.4 including support for XMLEncoder and XMLDecoder, and javax.xml.* have been updated in general.

New in release 0.13

* The http url protocol handler has been replaced with a full HTTP/1.1 version from GNU inetlib.
* A new ftp url protocol handler has been added also from GNU inetlib.
* java.beans has been updated to 1.4 including support for XMLEncoder and XMLDecoder.
* The java.util.Locale support is now based on the Common Locale Data Repository (CLDR) Project (see http://www.unicode.org/cldr/). GNU Classpath provides support for more than 250 locales now. This new support is experimental and the GNU Classpath hackers are working together with runtime developers and the unicode consortium to improve them in the future. If your runtime misdetects your locale or if the default locale gives problems please try running with -Duser.language=en and -Duser.region=US to fall back on a known good locale.
* Added implementations of javax.xml (JAXP 1.3), org.xml.sax (SAX2) and org.w3c.dom (DOM Level 3) interfaces. It is possible to switch between different implementations AElfred2, GNU DOM, GNU XSL, libxmlj SAX, libxmlj DOM and libxmlj XSL by setting different system properties. Also provided is a preliminary XPath 1.0 implementation. The libxmlj versions are build around libxml2 and libxslt and have to be enabled during build time by the --enable-xmlj configure flag. The current support is equal to the last released GNU JAXP 1.3 release. These packages will be maintained as part of the GNU Classpath core classes in the future. For more information, conformance results and documentation on selecting different implementations see doc/README.jaxp.
* More AWT accessible support.
* AWT gtk+ peers component layout, dialog placement, keyboard focus handling and text positioning have been improved.
* ImageIO interfaces are more complete.
* JList, JTable and JTree have been hugely improved.
* java.awt.Robot support with GdkRobot in the gtk+ awt peers. Needs XTest Extension (libXtst) XServer support.
* New --disable-examples configure argument.

Runtime interface changes:

* Added a new method (VMRuntime.enableShutdownHooks) that enables the VM to lazily register an exit handler.
* The java.lang.Class constructor now automatically sets the protection domain for array classes, based on the protection domain of the component type class.
* New gnu.classpath.VMSystemProperties class. This replaces the system properties initialization in VMRuntime. Note that it is now the VMs responsibility to set one additional property: gnu.cpu.endian should be set to "big" or "little".
* VMRuntime.nativeGetLibname() has been renamed to VMRuntime.mapLibraryName() and has only one argument, the name of the library.
* String and StringBuffer now call VMSystem.arraycopy() directly and don't go through java.lang.System. Be careful to not initialize java.lang.System early in the bootstrap sequence in your VM runtime interface classes.
* Some (wrong) documentation about the behavior of VMThread.sleep(0, 0) has been updated. Also, VMThread.sleep() now has a default non-native implementation, but it is a generic implementation that ignores the nano-seconds argument. Runtime hackers are encouraged to provide a more efficient version.
* There is prelimenary support for nio direct byte buffers. See VMDirectByteBuffer. Please contact the GNU Classpath mailinglist when you add support for this to your runtime.

GNU Classpath home page

Tis Open Source Java, like Mono.
W/O Sun License...

GNU is not Linux.

Classpath is not Java ?

.V

I get the feeling that one-day we'll be glad that these guys did this.

I actually like Sun being in charge and steering Java, it gives it a nice commercial edge that keeps it fairly practical to use on commercial projects. That said, it's comforting to know that if Microsoft purchases Sun one day that I could still keep programming in Java ;-)

Has anyone used this in anger and if so what have your experiences been?

used in conjuction with IKVM to run POI in a .Net web application and this worked out pretty well.

Thanks for replying.

Did you find it stable? And was the language coverage what you needed or did you miss anything.

For what we were doing, that is generating excel spreadsheets serverside using Apache POI, we were able to do so without any limitations meaning the language coverage was what we needed.

HTH

Thanks, it's good to here of actual experiences.

Readers may be interested to know that Apache Gump does a daily run against the latest builds of Kaffe+Classpath. This gives you an easy way to
see what works and what doesn't.

That's not bad really.

That's not bad really.

It will be a bit better :). There is some SMP trouble nagging on Kaffe, ocassionally, that's getting shaked out in Kaffe's CVS by Guilhem & Helmer.

On the GNU Classpath side, Michael Koch and the gcj developers are great, an awesome bunch of people fixing all sorts of bugs that have been discovered using the gump.

cheers,
dalibor topic

they did a very good job,but the license is preventing any seriuos software vendor to use it, as it GPL with exception
even the mono class library is under bsd
but to b practical, nothing under the gnu umbrella will change its license
so for now this is good for amatours and such use , no company will involve in such effort
sorry ,but this is my opinion

Dear Mr. Joe,
You may want to make a less informed comment next time.

IANAL, but to me the actual license reads a bit differently.

Doesn't it ?

TSS: can we PLEASE have an EDIT POST feature ffs ?
Obviously it was "a less uninformed".

Also see this FAQ entry. Quote:

2.3 What does the exception allow me to do?

If you combine GNU Classpath with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice.

So you can use and distribute GNU Classpath as is in your program without changing the license of your software.

I think that settles it.

One of the things I would like to do on occasion is compile Java source into .NET clients (all the server-side stuff is strickly Java/J2EE with my clients being .NET).

So am wondering if the GNU Classpath library in conjunction to j# would be a viable means to do that.

Microsoft says j# is backward compatible to their own j++ product but that was built back in the early days of Java and its class library is rather dated by now. Perhaps GNU Classpath would get one much closer to JDK 1.4.

The end goal would be to use a tool such as JAXB and generate Java source code for marshalling classes that is compiled into both the server and client side implementations. I also need to locate an open source JAXB-like tool so that would be able to compile its runtime libraries with j# and GNU Classpath to build suitable runtime support for .NET side of equation.

I think folks can begin to see where this is going.

One of the reasons I use .NET for clients is that .NET remains much more adept for programming Windows. I need to use things like PBX and streaming video solutions where their runtime support is always provided by vendors as COM ActiveX controls. I've tried extensive experiments in building Java-only clients that use such mechanisms with a third party tool doing the COM JNI wrapping. But it failed. So .NET gives me a language comparable in benefits to of Java while being much more capable of dealing with Windows-specific programming.

If GNU Classpath and J# worked well together, then I could at least write my clients entirely (or in part) in Java source code. That would be pretty nice in and of itself.