Older blog entries for robilad (starting at number 103)

16 Aug 2006 (updated 16 Aug 2006 at 12:00 UTC) »
I Bet You Look Good On The Dancefloor / Open Source Java

I guess I am late to the party, and noone told me to dress formally, so ... let me just say for the start that I think, like tromey does, that it's awesome news.

Whatever People Say I Am, That's What I'm Not / Angst in Javaland

There is a huge amount of angst in some areas of Java user and developer base about free software, and free software VMs forking, breaking, smashing Java to pieces literally. Or it's RubyOnRails, or .NET, or whatever the fear of the year is. That's rather irrational, but that's how fears work. So I'm interested to see if the feedback Sun receives will be couloured in the terms of the struggle of good vs. evil, as an inversion of sides in the struggle Simon describes as a blatantly false metaphor for what's actually an ongoing process.

Meanwhile, going with the "healing" theme, that Simon set, I've contributed my first ever patch to the Sun JDK yesterday. I managed to pull that feat off without looking at Sun's non-free code, by fixing the BSD-licensed Java2D demo to build on top of Kaffe, through refactoring it to use standard image io interfaces, instead of VM-specific extensions. There is a nice little thread on JavaLobby, of all places, starting with Sun's Dmitri Trembovetski's curiosity about our Java2D implementation, our own David Gilbert pointed out that the Java2D demo in Sun's distribution won't compile on a free runtime due to the lack of those VM-specific classes, I stepped in with a patch and a bug report in Sun's implementation, and Dmitri confirmed that the imageio bug I stumbled upon was fixed in Sun's Mustang builds. So now I've got a fix for the JDK waiting for review on Sun's bug parade, and if the stars align right, it may even go in.

I would not have gone through the effort to improve the Java2D demo and contribute my fix back to Sun if it wasn't free software.I would have investigated the bug I observed (Duke's nose was the wrong colour in the flipped image) had Sun's class library been free software, but without being able to use the fixed code in Kaffe due to its non-free, GPL-incompatible license, I had no particular interest in doing that.

Perhaps Vampires Is a Bit Strong But... / Licensing

There is a simple lesson about licensing in all that: chosing a software license that allows people to reuse a work motivates them to contribute, while chosing one that prohibits them from using a work keeps them away.

In that respect, JRL, SCSL, etc. worked great for keeping all those dozens of GNU Classpath developers away from Sun's JDK sources for almost 10 years, and dozens of developers working on other projects. That's quite unfortunate.

Apache Harmony offers another demonstration why the simple lesson above is so important. Back when we started the project, we thought we'd be able to find an easy way to make the source code contributed to Apache Harmony reusable between all the different free and non-free VMs, by using a GPL-compatible and Apache-compatible license for the contributions, and reproducing the success of GNU Classpath's innovative approach to permeable development in a larger setting.

Trying to get Apache to be flexible on the licensing turned out to be a complete desaster, due to the way the Apache Foundation works, so we ended up having to pick between being able to have GPLd VMs using a mostly complete class library, or having to prohibit GPLd VMs and use an infant class library under a GPL-incompatible license. The binary choice, encouraged by an odd "Apache License or bust" attitude on the Apache Harmony mailing list, led to a lot of potential contributors packing and giving Harmony up. Fortunately, Geir rescued Harmony by sucessfully soliciting contributions from Intel and IBM, and now it's a very lively project in incubation. It's mildly amusing to think that we'd be finished with open source Java already, if it wasn't for this fraction of efforts.

It'd be great if Sun could avoid the mistakes we made. One thing is to avoid adding yet another license to the mix: Use the GPL+linking exception, or a dual license with GPL+linking exceprion and ASL. Please don't add a third GPL or ASL incompatible license to the mix that makes sharing between those projects harder than necessary, as then their developers will have no incentive to help you, and we'll end up with three different competing efforts. Yikes.

There is a giant window of opportunity right there for Sun to come riding in on a white horse and be the missing link between the various free Java communities, starting from the leading position, and ensuring compatibility by encouraging everyone to work together with them on a liberally licensed code base. It'll be interesting if Sun sees and captures it. One can hope.

As an additional note on licensing, it may make sense to consider what communities they want to engage with their source code releases, and license accordingly. Javac offers an interesting intersection point between Eclipse and Sun, for example.

When The Sun Goes Down / Governance

I've posted before on JCP's problems, with a bunch of constructive suggestions how to fix them. I'm a deliberate outsider to the JCP since it forces NDAs on participants per default, and offers little real value to members as most communication takes place behind closed doors anyway, and each JSR is a small, walled off garden. That's at least what the people inside that process are saying.

Since I am familar with other standardisation bodies like ISO's C and C++ WGs, and the work being done in various places at the W3C, I've got a rather high level of expectations from standardisation groups, and I hope the JCP will move towards an improved, more transparent, quality and developer-oriented approach in the future.

As far as governance of Sun's project goes, tromey said all that needs saying. If in doubt, ask the NetBeans, Opensolaris, GlassFish and OpenOffice.org teams and compare the results.

Red Light Indicates Doors Are Secured / Compatibility

What tromey said, basically. We need an open source TCK. The distributions trying to figure out if they are in compliance with the DLJ need an open source TCK. The people fixing Sun's opened up code next year will need an open source TCK.

This is so basic, that I am afraid I'm telling Sun the obvious when I say: open up the test suite. But who knows, maybe there are still some folks left under some rock who think the open source Java developer community doesn't care about compatibility, or something equally weird. People get the strangest ideas when they don't communicate, and naturally, the amount of communication between Sun's gated community, and us outside has been limited. So I hope to see some movement on that, and the things David Herron talks about are quite encouraging.

The View from the Afternoon / Branding

That's a non-issue for me, as Kaffe has never been Java(TM)-branded. Whatever works best for those needing the brand, works for me, as long as it doesn't impact the actual source code license in odd ways.

For example, most distributions rebuild their software from scratch, to avoid all sorts of problems. A branding requirement that insists on a single pristine binary that must not be touched will not work for them. That's one of the issues that made me think that pursuit of certification under current TCK rules is something for people with very specific needs only: no distribution would package a random binary off the web, so noone would distribute a certified Kaffe or Harmony build, when they can rebuild it from scratch and optimise it for their distribution. They'd build their own, uncertified packages, so the certification would be pointless for the majority of multiplicators, under current rules.

That would obviously change if the TCK was open source, and could be run as part of the build process. Then a simple peek at the build logs would be sufficient to judge the quality and compatibility of the package.

Still Take You Home / Operation Issues

Well, a few of these things are rather simple: as my little contribution above shows, there should be a way for people to contribute to the opened up portions of the source code, without having to accept the non-free JRL/SCSL licenses. I chose Sun's bug parade, as that was the only way to do it, but as a source code contribution system, the bug parade is lacking in very useful features, like a simple text attachment feature. I'm not sure if the servlet didn't munge up my patch submission, but without a BugID, I can't verify it. The official review time for a bug parade submission is three weeks, I believe, so in the worst case, I'd have to wait up to three weeks to see if my patch arrived in a good state. Yikes.

Who the Fuck Are Arctic Monkeys / Closing Thoughts

The Arctic Monkeys have their own Wikipedia page that tells it all. I've used song titles from one of their albums as headers, as I am currently listening to their live shows, and like it for the time being.

The Arctic Monkeys are a nice little band, if you are into the sort of music. But they are also a massive hype phenomenon, selling out concerts in minutes, which leads to very high expectations. In Sun's case, the expectations are huge, and diverse. I hope they figure out how to meet them and all this feedback ends up being useful and used.

13 Aug 2006 (updated 13 Aug 2006 at 21:11 UTC) »
Ready, Set, Tag

Sun's Tom Marble has posted a folksonomy for feedback on Sun's efforts around Java Libre. That may be an indication that tomorrow's not widely circulated event may have a feedback-worthy item, or two, as Simon Phipps also keeps his lips sealed with a smile.

tan: Check out Marco Trudel's packaged gcj build for Windows with a GUI, UPX support and all that.
Fear: This Obsession Of Ours

vorlon: From Biljana Plavsić's plea of guilt at the ICTY on December 17th, 2002:

In this obsession of ours to never again become victims, we had allowed ourselves to become victimisers.

She was eventually convicted for crimes against humanity.

Her quotes from her active days in politics are precious little gems of hatemongering, and remind me very much of the disgusting rationalizations used to justify the crimes on both sides of the current conflict in Lebanon and Israel.

20 Jul 2006 (updated 20 Jul 2006 at 22:24 UTC) »
Principles, Principles, Principles!

Microsoft has decided to creatively reinvent themselves as a company, pledging to not do so much evil any more, for a change. Or at least they seem to pledge to implement some of the things they have been forced to by various antitrust rulings against them anyway, and call them the "Windows Principles". Ahem.

So, for example, Microsoft wants to tell you that it recognizes that "Ultimately, end users are free to choose which software they prefer to use.", or that "Microsoft will not retaliate against any computer manufacturer that supports non-Microsoft software.", and even "More generally, we want the developer community to know that it is free to develop, support and promote products that compete with any part of Windows."

I have thorougly enjoyed Microsoft's use of the verb 'to retaliate' all over that piece of corporate propaganda. Priceless.

Debian Cross-Compiler Toolchains

There is a repository of prebuilt toolchains for various Debian architectures over at http://debian.speedblue.org/. Since I am trying to fix the reported build breakage in Kaffe on ia64 with gcc 4.1.1, having an apt-gettable cross-compilation toolchain is very handy.

12 Jul 2006 (updated 12 Jul 2006 at 13:10 UTC) »
Just a bunch of small improvements to the JCP

Simon Phipps talked about having a level playing field a while ago, and Sun's Rich Green indicated at Java One that the JCP would like to see more members. Ken Arnold talked about the reforms necessary in the JCP to make it happen. Let me throw a few softballs as well.

Compatibility is great. Everyone wants that. In practice compatibility is easy, too. It just takes a few things:

  1. there is non-discriminatory licensed code to look at and/or reuse
  2. there are non-discriminatory licensed specs, which are implementable, and are detailed enough to allow interoperability
  3. there are non-discrimininatory licensed, extensive test suites to verify that the end result interoperates correctly with whatever else is out there
. With the Java 1.5 JSR, we've finally got one of the three, sorta, as that was the first Java specification release under a license that allows free software implementations. The official implementation and test suite have licences that fall short of the non-discriminatory goal.

The problem that Simon talks about, is real. A quasi-monopolist can ruin a platform for others. See the ongoing fight of the EU vs. Microsoft to ensure a level playing field in the Windows arena. Or see the fight Apache had with Sun to ensure that specifications coming out of the JCP can be implemented as free software, to allow a level playing field to exist between free and proprietary implementations of the 'industry standards'. As the times have changed, now it's Sun that's afraid of someone else putting the pressure on them by tilting the playing field to their favour, shifting the thinking from building a 'community' to creating good 'governance'.

For Java to be safe from someone tilting the playing field in their favour in the future, the JCP will need to open up radically, to embrace participation from new members on all levels. It needs to grow much further than the few hundred individuals and vendors that are in it today. It needs to put some power into the hands of the membership, so that anti-social behaviour by vendors can be dealt with effectively and publicly.

For that, it needs to come with full, mandated transparency on every JSR, no-strings-attached access to specifications and test suites, like W3C does. It needs to have a patent policy that requires disclosure of patents embedded in specified technology, and creates a patent covenant around each JSR.

It needs to make the life of Java developers and easier, not harder, as it does currently.

So, here is a small list of items to fix in an upcoming JCP 2.7:

  1. The JSPA legalese required to participate is way too long, way too NDA-ish. I want to help improve specifications. Making all the individuals who'd be able to help spend their time dissecting 10 pages of dense legalese before they can help is not such a great idea.

    The JCP should either drop the JSPA for participating on the JSRs, or cut it down to one page with clearly spelled out rights and obligations of the membership.

  2. The legal restrictions on participants in JSRs are unclear. When the call went around to join the Mustang JSR, I asked the spec lead what the legal implications would be on me as an independant implementor, but got no real reply. If Sun's spec lead on the Mustang JSR can't figure out what the legalese means, then there is someting seriously flawed with the system. It seems that those restrictions largely exist to resolve problems coming from the lack of a separate name space for draft specifications, and the resulting potential for confusion between partial and full implementations of the specs.

    Use the org.jcp.draft.* namespace for the draft specs, then.

  3. Most core Java JSRs are not transparent, for members and non-members alike. If I want to know what's being cooked in JSR 277, to pick an example, I wouldn't be any wiser than I am now if I joined the JCP, as the spec lead is not encouraging public participation on that JSR, within or outside the JCP.

    JCP should mandate full transparency on JSRs by default, and have a jcp.java.net project associated with each JSR, with a public mailing list archive, RI source code archive and the TCK, as they are being developped, rather than leaving it up to spec leads to set their own rules on transparency.

  4. JCP is currently focused on quantity, rather than quality of the specs. In particular in the area I am familiar with, Java 1.5, there are several APIs that are very poorly specified, and should have never become part of Java. Stuff like this is rather bad in an industry standard.

    There should be some effort to ensure quality: require two independant and interoperable implementations of a JSR for it to be allowed to move to the final vote, and require a certain amount of test and assertion coverage in the TCK.

10 Jul 2006 (updated 10 Jul 2006 at 20:11 UTC) »
Java Modularity Pointers

Every now and then, there is some thread somewhere where Java developers get to exclaim their demand for interesting features. It seems that modularisation is going to be a hot topic, judging by the JCP struggle between Sun and OSGi, i.e. JSR 277 and JSR 291, and talk at the various 'community' sites.

Looking at Richard S. Hall's slides from ApacheCon Europe, which lifts some of the NDA veils that Sun keeps for whatever weird reason on JSR 277, a lot of the thinking behind the various plans seems to work towards enabling annotations of the code with various constructs, be it annotations to describe module structure, versions, or bundles. If it requires manual labor, I'm not sure if it is going to take over the world, though. See Maven, OSGI bundles, Ivy, etc. all of which are pretty nice, but require someone to do some work to take care of the metadata, and keep it all up to date, which has kept the repositories relatively small.

So, what else is out there, that tries to solve the problem more automatically?

Beside Luca Cardelli's foundational work in the area, there has been a lot of interesting work done at DISI in Genua.

In an ideal world, my compiled classes would have additional information on their dependencies for rebuilding and linkage, in form of type constraints, so that I could query a module repository's database for the set of classes that would safely link, while preserving binary compatiblity, and refine the set to only the classes fullfilling constraints on their tagged versions, binary hashes, etc. The module repository database of type information would be largely automatically compiled by extracting exported types and their linkage constraints from the class files, and allow annotating them with some manual versioning information, for additional convenience. The module repository would be able to translate module names between its own format, and my local packaging system, and detect that it doesn't have to download a class that Debian already packages in a suitable bytecode version, or as a suitable gcj-ed native DSO. It'd be able to degrade gracefuly on systems without native software packaging mechanisms. In an ideal world, the module repository would figure out which native library to load based on the native linkage symbols in the class file, without requiring an explicit System.loadLibrary() call in the Java code, and the guessing game of DSO names.

That's what I'd like to see a future Java module system do or at least make possible.

Jumbo

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.

94 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!