Older blog entries for robilad (starting at number 95)


I came accross an interesting paper on using Jumbo to optimize marshalling in Kaffe's ObjectOutputStream by a factor of magnitude, or two.

Makes me wonder what it would do for speeding up reflection, as well.

6 Jul 2006 (updated 6 Jul 2006 at 16:23 UTC) »
How not to license specification drafts

I've recently thought I should take a peek at what's happening with the Java Compiler API JSR, to see what all the years of effort have led to. It turned out that the recently published JSR spec draft is under one of those bogus licenses that the JCP uses per default, that make you promise to give up your freedom to develop what you want, in exchange for the opportunity to comment and help improve the respective specification.

That's bogus, of course, but that's how the JCP works. In particular, the Java Compiler API draft has the following gem of legalese in its license text:

"The grant set forth above concerning your distribution of implementations of the specification is contingent upon your agreement to terminate development and distribution of your implementation of early draft upon final completion of the specification. If you fail to do so, the foregoing grant shall be considered null and void."

Well, I don't think I'll be taking part in reviewing that spec's public draft, then, if I can't try to implement it, and keep developing my own work, after some arbitrary date.

The wisdom of creating specs behind firmly shut doors, like Sun does in most of the JSRs they lead, and simultaneously making specification review impossible for independant implementors unless they agree to stop development on their independant implementations, is rather questionable. That way, the only thing that's for sure, is that a specification gets next to no public review from people who'd be able to comment on it with practical experiences implementing it.

If the independant implementors are not supposed to be able to comment on the drafts, why publish them in the first place, or have the whole JCP system at all?

Unfortunately, the self-defeating licensing conditions of the Java Compiler API JSR public draft are no exception. In fact, the whole Mustang spec is licensed under the same conditions, judging by the license for the spec.

19 May 2006 (updated 20 May 2006 at 00:43 UTC) »
GNU Classpath At Java One At Last

Fernando did a podcast/talk at this year's Java One on the state of free runtimes, and associated projects. Nice stuff, though listening to demos of GNU Classpath feels weird, because I can 'see' what's being demoed.

Next year, I'll have to try to get a "Smashing The Java Trap: An Illustrated HowTo" talk accepted.

19 May 2006 (updated 20 May 2006 at 00:44 UTC) »
We've Come A Long Way, Baby

One of the benefits of Kaffe is that it is wildly portable. Almost any combination of cpu and os has got a port somewhere, and new ports keep coming in at a steady rate. In particular, you can now shortcut Sun's complicated build process for their proprietary 1.5 release using Kaffe, at least on x86_64-openbsd.

Fun, in a twisted way.

17 May 2006 (updated 17 May 2006 at 16:32 UTC) »

So, according to the last big news, the big question is no longer if, but how. This is how:

The closest collaboration point between free software Java developers outside Sun and the engineers on the other side would be the test suites. Since the free software projects like GNU Classpath and Apache Harmony, just like Sun's developers consider compatibility to be one of their prime goals, a merge of the respective test suite code to a common, free software, compatibility & regression test suite for the core Java specifications would be pretty useful for all implementors, as well as distributions using the DLJ.

Meanwhile, the simplest thing Sun could do to make open source Java reality a little sooner, and create a collaboration effort, would be to modify the current "Read Only" JCK license to allow compilation and execution of Sun's official test suite by independent implementations.

17 May 2006 (updated 17 May 2006 at 13:15 UTC) »

It's JavaOne time again, and Sun's collection of Java technology licenses includes a new addition, the Distro License for Java, aka DLJ.

On a cursory glance, I'd agree with what David Walluck said on debian-legal, it's a rather odd license choice, which seems to in part address some of the problems from the BCL, but in exchange seems to add a bunch of new ones.

I hope the forthcoming discussion on debian-legal will clear it up.


Some time after introducing Glasnost, there is a small substitution at Sun's leadership.

In the best Sun PR tradition of not letting facts get too much in the way of a PR message, the press release credits Sun for "the open sourcing of Java[tm]", something Sun never did.

Au contraire, mes amis: Here is a characteristic quote from McNealy on 'open sourcing Java': "I don't know what problem that would solve apart from IBM's childhood envy". Schwartz has been more diplomatic in explaining Sun's reasoning in the past, with quotes like "Our refusal has nothing to do with Sun being proprietary and everything to do with wanting to keep Java from forking", but has still sayed true to the party line.

Looking at Sun's handling of J2SE and the JCP, and Sun's lack of good fortune, last April's "Schwartz also predicted that companies that pledge support for open-source software but that keep their own products proprietary will eventually be exposed as hypocrites and fall by the wayside" sounds a bit ominous for Sun's future. As much as I hope that Sun does not fall by wayside, I doubt that Schwartz sees the need for a full-fledged open source Perestroika.

Who needs specifications, anyway?

Wontfixing standards

7 Apr 2006 (updated 7 Apr 2006 at 11:23 UTC) »
Hey, dude, where's my JSR??

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.

Speculating About Sun

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.

86 older entries...

New Advogato Features

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!