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.
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.
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.
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:
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:
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.
Use the org.jcp.draft.* namespace for the draft specs, then.
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.
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.
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?
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.
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.
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.
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.
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!