Roman Kennke decided to show off the ultra cool HyperTree library on top of GNU Classpath, jamvm and the libgcj gui branch.
Graydon Hoare then decided that it was time to show how much Free Swing has matured.
And you can join the fun by testing Thomas Fitzsimmons his GCJ-based GUI development environment with JHBuild.
Go team! Go!
Jim Huang does it again!
The FrozenBubble applet works with gcjwebplugin on kaffe.
Read his instructions or watch the screenshot.
Since it seems every 6 months or so Sun makes some noise about Java and Free Software I asked Dalibor Topic and Ean Schuessler about their recent experiences with getting access to the TCK for Kaffe and Ean his encounter with Simon Phipps at FISL. Dalibor still hasn’t heard anything about how he or the rest of the Kaffe team can get access to the TCK. And Ean his story about what Sun told him about supporting Free Software and the Kaffe project didn’t convince me they are really serious. Ean asked me to put in a little disclaimer if I wanted to quote him. “Feel free to reproduce this message in any channels you consider relevant to the cause. Keep in mind that my memory is most certainly imperfect and this little story may bend or extend the facts. That said, I’ve tried to represent what I experienced factually. Include this notice.” So with that out of the way, here is part of what Ean said:
In essence, Simon said everything that a Free Java fan would like to hear. Sun supports Free Software, Sun thinks Kaffe is a good thing, Sun would like to find a way to certify Kaffe and go team go. This isn’t suprising considering that Simon’s title is “Open Source Evangelist” or something along those lines. I found the subtext of the conversation less encouraging.
Simon continued to harp on the same cliche reasons for not releasing the source to the JVM. Microsoft would subvert it by forking, the Free Software community would subvert it by forking, IBM would subvert it by forking and so on. I naturally pointed out to Simon that Free Software is entirely held together by standards (POSIX, TCP/IP, etc.) and that some of the most important Java standards were based on Free Software (SAX, DOM, etc.). He resisted these points mostly by repeating himself. To me that signals that he was reiterating the corporate position and not his personal one. He also had a tendency to obliquely refer to some point in the future where he might abandon his position at Sun if they don’t do something significant with Free Software and Java.
To me this looks like they (Sun the company) aren’t really serious about supporting the Free Software implementations. Tom Tromey pointed out some questions you might want to ask when attending any debate about free implementations of java. But for now it seems it is better to concentrate on our Free Software implementations then to go into debate again and again with Sun about what they want to do. I cannot force them to do anything they don’t want to. So I just concentrate on making sure that the next GNU Classpath 0.10 “Independence” release will rock!
Sorry, only in Dutch. Hoop softwareindustrie gevestigd op de magie van de ossenhoorn. For those that don’t read Dutch, you can look at these pictures to see how some people are preparing to blow away patents on software from the Netherlands. For those that do read Dutch, there is some more background info.
When reading the Native Eclipse article I had to think back to my visit to Red Hat in Toronto. Since I was going to the GCC Summit in Ottawa anyway I really wanted to meet some of the people working there that I had never seen in person. And I am very glad I did. I used to think that the “I am Red Hat” buttons that all these Red Hat drones had put on their weblogs were just stupid. But after meeting so many nice, intelligent and passionate Red Hat hackers in Canada I see they really mean it. The Free Software spirit is so strong in the people working for Red Hat. And they are very serious about making sure that what they are working on is commercially viable. It made me feel a lot better about the “big bad evil corporation” that I used to make so much fun of on irc.
It was also nice to be able to give a little presentation on GNU Classpath history, current state, goals and future (based on the presentation Sascha and I had already done at FOSDEM) for Red Hat engineers, interns, and managers (some still new to GCJ and GNU Classpath), and to point out how working with Red Hat on all this is both fun and confusing.
Native Eclipse is a very good example of this. We were all really happy when it won the Fast Free Eclipse Prize back in August 2003. It really looked like this was the future of Eclipse on the GNU platform. There were still some little issues to work out before all this nice work would be integrated with the upstream projects. But from the start (and even now!) Native Eclipse was on the schedule of Fedora Core 2. So we assumed that was being worked on. And it looked like it was going reasonably well since each new Fedora Core 2 test release had more and more native gcj packages (native versions of ant, bcel, jakarta-commons, cup, gnu-jaf, jakarta-regexp, gnu-javamail, junit, mx4j, mysql-jdbc, servletapi, struts, tomcat, xalan-j and xerces-j are now included).
Fedora Core 2 final was just released before I went to Toronto, so I thought it would be nice to install it and show my presentation and demo on this distribution that claims more Java software using gcj (Ant, Tomcat, Jakarta, Eclipse). But sadly no Native Eclipse in the default install. So I tried to get and install the old Natively Compiled Eclipse RPMs. It installed, but it crashed immediatly when I tried to run it. Since I was able to get native eclipse working fine on my Debian system, I then tried to just rebuild the whole thing from source. Just to find out that only the runtime libraries are available, but the special versions of gcc-ssa and gcj-ssa aren’t there any more. (This is really bad since this was the only way that I know of to compile Eclipse from source using a free toolchain!). Then I just gave up and gave my presentation and demo from my Debian installation. [For people wanting to try anyway look at the native-eclipse mailinglist, lots of people trying, nobody succeeding it seems…]
Not having the time or resources to work on a project isn’t a crime. It is really understandable for a company that has as its first priority its customers. But not being clear about the direction of a project and promising that it will be included in the next “community project” release, but not following up on those promises and not clearly telling anybody that there is a change of direction doesn’t make you very loved by the community that you claim to support. And it made us feel a bit cheated since if we would have known that the work on native eclipse was in limbo and that it wouldn’t actually appear in Fedora then we could have encourage and worked on other ways to free eclipse.
It was very good to actually talk about this and other issues that make the free software community go hmmmmm, not because RH does something bad, but because they sometimes do things that seem just strange [*]. But it was also very good to finally being able to give a very big “Thank You!” for all the nice cooperation going on. And it also works the other way around (just imagine being dragged into the little dark room that Thomas Fitzsimmons calls his office and being cornered by Graydon and Bryce so they know you are actually listening to them). Luckily after that we went out for drinks and we did have a very good time. Thanks Red Hat hackers for everything you do and for listening!
[*] For anyone working in a larger community it is always important to keep in mind what Axelrod said about clarity:
Too much complexity can appear to be total chaos. If you are using a strategy that appears random, then you also appear unresponsive to the other player. If you are unresponsive, then the other player has no incentive to cooperate with you. So being so complex as to be incomprehensible is very dangerous.
Another article about GCJ and CNI (Programmer’s Toolchest) in the July number of Dr. Dobb’s Journal by Gene Sally. It compares CNI with traditional JNI:
CNI contains well thought out constructs for method invocation, property access, exception handling, and synchronization. Using these constructs instead of their JNI procedural equivalents means you can get the same work done using less code. […] the philosophy behind how you interact with java from a native perspective is much different, in a good, geeky kind of way. […] When workig in CNI, you have the feeling of working in situ with the java class; gone is the messy code necessary to bridge the two languages. […] CNI offers a great way to program in native code when working with the GCJ compiler front end. The way CNI maps your java classes into C++ classes reliefs you from the drudgery typically associated with JNI-coded interfaces and lets you use the constructs offered by C++ in concert with your java code. If you have a chance, give this technology a try. You won’t be disappointed.
Note that th article refers to the old CNI name, these days CNI stands for ‘Compiled Native Interface’. And the old paper that the article mentions has been updated and incorporated into the GCJ reference manual (About CNI).
LinuxJournal published the article ”Eclipse Goes Native” by John Healy, Andrew Haley and Tom Tromey:
Red Hat’s Eclipse Engineering team has freed the popular integrated development environment from its ties to a proprietary Java Virtual Machine.
To compile Eclipse natively, Red Hat’s Eclipse Engineering team used GCJ, a free, optimizing, ahead-of-time compiler for Java. GCJ can compile Java source code to native machine code, Java source code to Java bytecode and Java bytecode to native machine code. The approach we took involves using GCJ to compile Java bytecode to native machine code.
This article discusses why native compilation was an attractive choice; explains what we had to do to GCJ, libgcj and Eclipse to make it possible […]
Chris Burdess worked like a dog and made some very fine releases of GNU JAF (javax.activation), GNU JavaMail (javax.mail, plus extra NNTP, mbox, and Maildir providers) and GNU inetlib (finger, gopher and ftp URL stream handlers, plus utility classes for nntp, imap, pop3 and smtp client support). These packages can use GNU Crypto and Jessie for SASL and TLS support. And Casey Marshall released Jessie 1.0.0 this weekend. Also interesting to see that more and more traditional GNU packages like the GNU IDN Library now come with wrappers for the java language.
