Dear me, there was a real flurry of totally futuristic Java Specification Requests recently!
Watching Sun Microsystems turn into the mother of JSR invention recently was quite exciting. So far, it seems that Sun has said goodbye to earlier conservativism on all things regarding Java or the JVM, so apparently nothing is too outlandish to get into J2SE any more.
Embedding XML into the language? Sure, go help yourself. Adding new bytecodes to the JVM that are pretty pointless for running actual Java applications? Null problemo. Doing OSGi only sorta different with a twist? The JCP will let you have several JSRs for that. Loudly thinking that applying the idea of inner classes onto packages would be kinda cool on your blog? Woppiedoo, there is a JSR for you, too.
Last time someone tried to get people excited around one of those ueber-exciting JSRs that will totally reshape the future of Java (deployment), was JSR 277. That's the one where OSGi meets Maven, and they have a love child that is like a CPAN for Java, only with small JARs. Sorta. Kinda. It's hard to tell since the JSR 277 has not produced anything since its inception last summer, besides enthusiastic exclamations of support when it was announced. No drafts, no mails, no announcements, no calls for contributions, no nothing at all. Not even a java.net project, afaict. I guess it's one of those situations where JCP's approach to transparency via spec-leads really shines. So, yeah, if someone knows if JSR 277 is officially dead, or just looks like it, please do post a blog entry, or, preferrably, the JSR 277 mailing list archives. I am seriously morbidly curious if it was eaten by a grue, or something else happened to it.
What else does the future hold? Ah, "invokedynamic". A whole whopping new bytecode. The first one in approximately 10 years, afair.
So, it turns out that the whole "there is no Java in Ruby (on Rails) or PHP or Python" thing actually irks someone at Sun enough to do something about it, to give all those potential deflectors from the JVM something to hold on to, while the JVM gets rebranded as the language independant platform of the future. Since those programming languages are characterized as "dynamic" languages, someone at Sun thought really hard how to associate that cool, new buzzword with the not-really-well-known-for-its-dynamism JVM, and came up with a new bytecode, invoke ... tada ... dynamic!
Personally, I'd have gone with simply reserving bytecodes for "invokeweb", "invokeweb_2" etc. without specifying their behaviour, which would let future JVM designers easily choose which hype they want to invoke an association with. Less of a hassle with reworking the verifier.
And you know what? I'll let you submit that JSR. Consider this blog a draft spec, and go claim your five minutes of JSR fame.
Every now and then, people like to speculate over Sun Microsystems releasing their implementation of J2SE under a sane, open source license. Sun's executives used to say "No" to such speculation each time that sort of issue was brought up over the past 10 years.
That tune has changed to a more undetermined "You Never Know" recently. That has, in turn, led some people to assume that the funniest things will happen for Java One. To those of us writing free software in Java, that's a familar ritual: each year, a few months before Java One, someone will start drumming up the Java developers with "they'll totally open source Java for real this year! You just have to totally believe in it!", usually based on someone at Sun getting tired of saying "No", and chosing the easier answer, that leaves no room for counter arguments: "You Never Know".
So, here is a my take, why Sun will not, any time soon, relase their Java implementation under an open source license, and how you'd notice if they were planning something like it:
a) Marketing. In 2006, Sun Microsystems will be interested in migrating their customers to the next release of their implementation, i.e. Java 6. Opening up an older version would take away momentum from that. Opening Java 6 would only lead to higher support costs on Sun's side, without getting more migration to Java 6 done. I.e. less money for Sun.
b) Support. Sun could not just open up their former crown jewels and let them bitrot in public without earning some bad press. I've watched people struggle majorly on Mustang forums to build Sun's 1.6 betas at all, and I doubt Sun could just push out the source they have for 1.6 with anyone outside Sun being able to build it without massively cleaning it up. But otoh, supporting people building and hacking on an old release would take away momentum from the new release, and simply costs good money for the support engineers that Sun would probably rather invest into supporting their 1.6 release or into 1.7. Again, less money for Sun.
c) Nowhere to go with patches. It's unlikely that Sun would want or be able to accept community patches for an old release, while they work on Java 7, due to the way the Java trademark is tied with compatibility requirements. Making any release based on community patches would either require extensive compatibility testing, or, if Sun deliberately released untested, possibly incompatible implementations, dillute the Java brand's positive connotations. The real, licensing-cash-worthy value for Sun is in the brand, not in a particular implementation they give away gratis.
d) Legal. Sun's implementation contains several million lines of source code. Just like with Open Solaris, Sun would have to undergo a lengthy, costly process of securing relicensing rights/copyrights to each line of code it does not hold copyrights or relicensing rights to. That takes time, as one can see with OpenSolaris: work on opening all of Solaris up started a few years ago, and is not finished yet, afaik. It would be pointless for Sun to say they'd open up anything but their Java implementation, and then spend their resources doing it the other way round, wasting the positive PR effect.
e) Community. Sun would first try to build up a community around the code base, before they push it out in the open. Since there is no pilot program for Sun's implementation, there is nothing in the works of that sort. Note that the Mustang 'JRL community' is explicitely designed to not be an 'open source' community, but to encourage collaboration with VM researchers and small bug fixes on Sun's proprietary code base. There is nothing on the Mustang forums from Sun's employees that indicates that Sun Microsystems would have an interest in transforming the Mustang code base into an open source offering in the near future, and there have been no such remarks from anyone who'd know in public, for all I know. They would contradict the official statements from Schwartz, McNealy, Gosling, Hamilton and others, anyway, and last time someone said something like that in public, his superiors were quick to rectify the mistake.
On the other hand, I know that a lot of great people inside Sun would welcome being able to work with an open source community on J2SE as well, just like developers outside Sun, but I assume that Sun's management would prefer to proceed gradually and see how the JINI, OpenSolaris, GlassFish and JES transitions work out before they tackle the big one. If ever.
f) No real need for Sun. Sun's implementation gets 20 million downloads per month, according to a statement from Schwartz at the Sun/Google press conference last October. It's hard to see for Sun how relicensing their implementation would buy them more 'volume', as the maker of the dominant desktop software platform, Microsoft, is not going to ship Sun's implementation, no matter what the license is. They've got their own offering in the managed runtime space to promote with their upcoming operating system release, Vista.
For other popular software platforms, Sun either provide a compatible implementation themselves, or have a contract with someone with a financial interest in a seing compatible Java implementation on their platform, like Apple or IBM. If Sun opened up their implementation, and started to include ports to platforms where their licensees have financial interests of their own, they could cut into that licensing income. Not a good thing.
g) Licensing revenue. Sun monetizes their investment in Java technology just like any other proprietary software company: by selling restricted usage, modification and redistribution licenses. Sun sells licenses for their Java-based products, the RIs, the test suites, and sells support services. That very lucrative revenue stream would most likely stop, if Sun released their implementation under an open source license.
In particular, in the mobile market, there are many devices, many carriers, and many manfacturers, so there is a lot of (potential) licensing revenue to be made. Since J2SE is a superset of J2ME, where the licensing revenue is, if Sun opened up their J2SE implementation, they'd be inviting competitors for that license revenue. That's the last thing Sun needs.
So, there you have it, a handy reference for why Sun's implementation won't be open source any time soon, i.e. for as long as Java really matters: It would make Sun no money to open it up. The only way for Sun to keep extracting the licensing revenues for their J2SE implementation is to keep it proprietary and keep control over what Java is.
It's that simple.
Phew. That was one fun weekend. But finally, Kaffe 1.1.7 is out.
While waiting for the bugs reports for the release candidate to come in rolling, I've ported Kaffe to the two remaining platforms (save from OpenVMS, which is way too alien for me) it was not running on HP's testdrive site: FreeBSD 6.0 on Alpha and IA64. Porting Kaffe turned out to be as easygoing as I remembered it: a bit of copying of files from FreeBSD's amd64 port, a bit of tweaking of sigcontext entries, and the ports were up and running.
Kurt Miller added the 60th in-tree port of Kaffe, to OpenBSD running on powerpc CPUs. There is a post-relase patch pending to actually make that work with all regression tests passing, as the default stack size was too low.
After a few weeks of cleaning up, fixing bugs, polishing, resyncing around, Kaffe's 1.1.7 rc2 is up, with all the goodies from GNU Classpath 0.90, and some more niceties, like the beginning of a port to blackfin CPU architecture, various fixes for Cygwin, OpenBSD, etc. The majority of build issues we had during the transition to use fastjar, embedded zip and merged in GNU Classpath are fixed now.
The tarball is up for download at http://www.kaffe.org/~robilad/kaffe-1.1.7-rc2.tar.gz
Sunday at FOSDEM started with me sleeping in, and Wolfgang Bär politely banging on the door to make sure I don't miss the five slices of bread and a slice of cheese at CHAB. More accurately, since Roman Kennke, who was staying there as well, was scheduled to talk at 9 AM, we scrambled to have breakfast, check out, ride with Michael Koch to ULB and pop in just in time for Roman to start his presentation. It worked.
Roman showed how far GNU Classpath's SWING implementation has gone from early last year, when we had demos somewhat running, to today, when BeanShell, JUnit and other applications work fine. A lot of people have hacked on Swing in GNU Classpath, and put in hours of work to fill in the stubs with working implementations, and it shows. I am looking forward to running at least the NetBeans RCP on Kaffe OpenVM this year, given the amazing amount of progress by Roman, Lillian, Anthony, and many others.
Another area of huge activity in the past year was CORBA support. Dr. Audrius Meskauskas picked up the ball when it became clear that we can't use OMG's org.omg code due to their non-free license, which prohibts modification. As it turned out that all the other free software CORBA implementations written in the Java programming language had the issue that they depended on or included the non-free code from OMG, GNU Classpath had to write its own implementation, written from scratch, and free from non-free dependencies. Audrius created a largely complete, compatible CORBA implementation in GNU Classpath in a couple of months almost single-handedly, and has plans to add better tool support and some interesting ideas to improve the performance using dynamically generated proxies.
Then it was time for the battle of GNU Classpath interpreters for the 'state-of-the-art' crown: Robert Laugher's JamVM vs. Christian Thallinger's Cacao. First Robert explained some of the tricks used to make JamVM really fast, and then Christian showed the results of using vmgen to generate an interpreter that's about as fast as JamVM automatically. I'd be very interested in seing the vmgen-generated interpreter merged into Kaffe, as an additional interpreter, in particular for the platforms where we don't have a working jit yet. The code looks nicely mergeable, we'd just have to figure out how to best deal with the different internal representation used in Cacao.
Finally, the day was wrapped up with a discussion to see what everyone is working on. During the dicussion, a fim crew dropped in to film it, and asked the participants where they were from, etc. They seemed a bit surprised that a free software developer meeting in Belgium would draw participants from all over Europe, and the US. It must feel weird to see that free software development is a social activity, if one does not expect it.
I had to leave a little early, to catch the last trains back to Saarbrücken, so I missed out on the last pub stop and related discussions. All in all, FOSDEM was great, like every year. Thanks to Pascal and the rest of the FOSDEM team for having us.
FOSDEM is a great free software developer meeting taking place each year towards the end of February in Bruxelles. It's every year an awesome experience, and has turned for GNU Classpath into the equivalent of a yearly developer conference, where we meet to celebrate the achievements from the past year, and to pick up on the latest, newest things everyone is working on.
This year, we've had a bigger room than last year, so we didn't quite manage to pack it overflowing with people like the last year, but the attendance has been slightly higher from my counts. In particular, this year we had a documentary film crew filming the GNU Classpath future planning talk on Sunday afternoon, and enjoying it all, apparently.
We've had many regulars, this being the third year of GNU Classpath sessions at FOSDEM. We've also had many new developers who joined us for the first time, and interested visitors, who came in to see how far GNU Classpath is, when they can expect to see their code liberated from the proprietary Java trap, and what they can do to help.
Friday had the traditional social evening, this time in "A La Mort Subite". My train had an engine failure on the way to Bruxelles, so joined tromey, mjw and the rest of the hackers a little later than I had hoped. It was a nice evening, with Geuze and all that.
Saturday started off with Richard Stallman's talk on GPLv3, software patents, digital restriction management and treacherous computing. Richard was fun to listen to, as he did little theatrical stunts to illustrate his points, and he seemed to have a good time. His talk, and many others (valgrind! rife! darcs!) should be available online at the Belnet FOSDEM video mirror site.
Then we headed to the GNU Classpath room, to get treated to David Gilbert's story of JFreeChart's liberation, starring GNU Classpath, Cairo and David's CairoGraphics2D implementation, and shining a spotlight on how awesome the Mauve compatiblity testing project has developed in the past years. JFreeChart looks great on GNU Classpath+CairoGraphics2D. The slides are up on the FODEM page on the GNU Classpath wiki.
He was followed by tromey demonstrating how to hack use Eclipse to hack on GNU Classpath, Mauve and all that, and how to bootstrap oneself into that environment. That was a fun show and tell talk, and it's great to see how far things have come, and how easy it has become to tie various components together into a nice working setup.
Saturday's final talk was a demonstration of debugging of gcj'ed binaries using nothing but emacs & gdb. It turns out that gdb is pretty nice for the task, in particular in combination with the _Jv_Debug function, which dumps and unrolls objects. Gdb can deal with about anything thrown in its way, so one can literally walk all the way down the stack from a Java application compiled to native with gcj, to libc code performing the actual work.
I was particularly happy to meet Guilhem Lavaux, who's been doing all the hard work on Kaffe for a long while. He's as great in real life as he's on IRC, and currently hacking on improving the native code in GNU Classpath on a separate branch, among other things.
Saturday rang out with an evening at the BLX cafe, and the restaurant next to it, whose claim to obscure fame is that it has a literal "Vegetarian Dish" on the menue, though I have no idea what that is supposed to be, and nice Stoemp and Belgian beers. I've had some good conversations with Apache Harmony's David Taenzer, Jeroen Frijters from IKVM and Chris Gray of Wonka fame, during dinner.
More on FOSDEM tomorrow.
I guess every planet aggregator reaches a critical point, when memes start sweeping it. It's a regular feature on planet.debian, so, without much ado, I'll join in the fun on planet.classpath with my quiz score: Social Liberal (91% permissive) and Economic Liberal (8% permissive).
I was hoping to score the full 100% on Social Liberal, having grown up in a Third-Way country, but I guess the test is wrong.:)
One of the positive things about using the Java programming language is the mass of Free Software libraries and applications written in that programming language. There are even several certified Free Software J2EE environments, like JOnAS. Since Free Software written in the Java programming language needs to be liberated from the Java trap, I play off and on with software that I haven't tested against Kaffe successfully yet.
With a lot of help from Andrew Haley from gcj (who spent a lot of time making JOnAS work well on gcj and GNU Classpath since last FOSDEM) and Florent Benoit from JOnAS, I managed to get the JOnAS to fire up, and wiggle around on Kaffe's CVS head (with a patch or two). Instructions are at the Kaffe OpenVM mailing list, and may work for other GNU Classpath runtimes as well.
If you are using text mode browsers, you should then be able to use links to connect to port 9000 on localhost and get an impressively styled down, cool retro screenshot
If you are using Firefox, then you can see the JOnAS console in its full whaling glory.
I guess Kaffe 1.1.6 is now really ready for release, and I am ready for the GNU Classpath DevJam.
I've excercised my hardly fought for right to vote (I only got the German citizenship a few years ago), and ... it looks like there is no winner. None of the highly advertised coalitions of socialists and greens or christian democrats and liberals has the necessary votes for the majority. The undeclared winner of the election is the "left" party, who managed to sneak into the parliament on a wave of "leftist street-credibility" mix of anger over social reforms and miserable economic performance of the current governing coalition. They managed to get more votes than the established greens, thereby making both "red-green" and "black-yellow" governments impossible.
The remaining, possible combinations for government coalitions are not desired by the politicians, after a fast and partially bitter election campaign. The campaign got started after the socialist chancellor Schroeder, in a fit of panic after losing his home-state to the christian democrats in regional elections, decided to walk a constitutionally questionable thin line towards the reelections in hope that he'll be able to regain voter confidence.
So much for that brilliantly desperate and pointless plan: it didn't work at all. Quite to the contrary, both the socialists and the greens lost seats in the parliament, losing their majority by a huge margin.
On the other side of the German bipartisan divide, the challenger Merkel, starting off with a healthy majority a few months ago, managed to see it dwindle away while the socialists campaigned increasingly aggressively and effectively against her, and her party's badly communicated reform plans. She ended up scoring one of the worst results for christian democrats ever.
The margin between the socialists and christian democrats is around a percent in favour of the christian democrats. It is small enough for Schroeder to openly challenge Merkel's ability to form any government, without his participation. It seems that in a (most likely) coalition between socialists and christian democrats, there would be no place for both Schroeder and Merkel, so one of them will have to find a way to step down in dignity. Given that the German elections are not over yet, since the vote in a part of Dresden is delayed for two weeks due to the unexpected death of an extreme-right direct candidate (the German voting system is complex. Really complex. I'll mention just one word "Überhangmandat" and let you google for it if you need to know one of several weird bits and pieces of the German voting system), we are bound to see two more weeks of heavy trash talk from all parties, fighting for another 100000 votes and one sure seat.
If tonight's TV debates between the party leaders are an indication, it's going to be some heavy, irrational trash talk time. A coalition between christian democrats and socialists won't work, since they can not agree who would be heading it. A coalition between socialists, greens and liberals or a coalition between christian democrats, greens and liberals (which would be a novum) won't work since the liberals have refused to enter a coalition with any member of the current socialist-green government. A coalition between any of the blocks with the "left" party won't work either, since they are despised by all the other parties for ruining it for everyone (and being way too contrarian with their opposition towards social reforms and pacifism), and the leftists seem to be quite happy about it.
Chances are, if the politicians continue playing their love-hate relationship games, we'll have another indecisive election for christmas. Yay. Too bad that elections are not a cure for a lack of comprehensive leadership and good ideas in all the camps.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!