The OpenJDK Regression Test Harness, also known as jtreg, is the test harness used in the OpenJDK for running unit and regression tests. Jtreg is a wrapper around JT Harness which simplifies its use. Documentation is on the jtreg harness home page.

How is this important? Previously jtreg had been available under the most liberal closed source binary license you could imagine. The license said you can do essentially anything you want with the binary jtreg distribution. No matter how liberal that binary license, it interfered with the ability of some Linux distros to make use of the unit and regression tests. I wish to thank the project members of these Linux distros for explaining the importance and distinction between the most liberal binary license you can imagine and a proper open source license. Once I groked the distinction it deepened my understanding of the open source culture.

In the end what is important is that OpenJDK builds are as high quality as possible. Enabling the distro's to run the unit and regression tests help them have comfort in knowing the tests passed.

We should be clear, however, that this appears not to be an open source announcement despite Adobe's use of the word 'Open'. Not being a lawyer the following is my best understanding - the documents are under a restrictive license that allows you to print the document once, and you cannot redistribute those documents. So the specification is openly published, as they say, but not open source. I couldn't find any software source code, FWIW.

Oh, and, 13949712720901ForOSX

I'm giving a session at JavaOne this year titled "Hacking the OpenJDK" and it's been very interesting sitting with this topic these last few months. Much of the presentation is an overview of the developer guide, source repositories and other infrastructure on openjdk.java.net which anybody 'hacking' the OpenJDK will need to get started. All that is pretty straightforward and obvious what to cover and how to present it. What's been interesting is what might be some common hacking scenarios with the OpenJDK code.

My co-presenter is the one preparing the demos, and while we have some interesting demos lined up he wanted to know if y'all had any thoughts on "hacks" you'd like to see. The comment box below is available for y'all to leave us ideas. And please remember that we have 50 minutes for the session, 30 minutes will be taken with me talking through the OpenJDK project overview, leaving 20 minutes for demos and questions.

The most interesting and most controversial idea in the session is: how to remove CORBA. I thought it's obvious, the most common change people want in the Java platform is to ditch CORBA. That is, unless you're one of the two people who actually use CORBA, I suppose. Feedback from colleagues was a "are you sure it's our party line to suggest making incompatible changes?" While that's a fair criticism I a) wanted to make it clear the OpenJDK is an open source project and any change is fair game, and b) that some changes create incompatibilities and that there is value in maintaining compatibility with the platform spec. In any case it's not too hard to hack the OpenJDK to remove CORBA, but I'll leave the details until my session at JavaOne.

The session ID is: TS-5230

Maybe all the Doctor Who episodes I've been watching recently has something to do with this interplanetary exchange.

"??Less Filling??" .. that's modern flotsom that popped into mind as I thought about the encumbrance issues. We are on the cusp of having the binary encumbrances cleared. While the OpenJDK represented a huge chunk of open source code, it was only 95% open source. The remaining bits coming from source we hadn't been able to open source. In the months since we've been working on replacement code or on gaining the rights sufficient to open source those encumbered pieces. And the last of those is on the verge of being resolved.

There is a lot of exciting stuff in 6u10 (formerly known as 6uN) .. there is a lot more here than the typical update release. Unlike most update releases where the work is limited to critical fixes, for 6u10 the changes are pretty dramatic, will be affecting a lot of things, which leaves us wanting to hear about regressions or other kinds of bugs we may have created along the path of getting to 6u10.

(um.. before the wags get ahold of what I just wrote -- any time you write new code it's common to write some bugs as well)

Let's go over some of the new features:-

Java Deployment Toolkit:- hooboy the description is pretty hairy but says a few interesting things. "allows developers to easily deploy applets and applications to a large variety of clients with JavaScripts.... makes it possible to automatically install Java Platform for Java Plug-in applets and Java Web Start applications. The script exposes a single object, named deployJava" and the deplyJava object has a buncha useful functions to reduce the complexity of deploying an applet across multiple browsers.

The Java Kernel (FAQ) makes for a tiny Java platform which can be more quickly downloaded & installed while still allowing the full Java SE platform to be available, requiring downloads of missing pieces as required.

The next generation Java plugin looks really cool and ought to drastically improve applet and javawebstart functionality and behavior. It is a ground-up reimplementation of the venerable plugin which uses a more intelligent architecture which immediately fixes several outstanding glaring bugs and problems. I think that while in most cases incremental improvements and bug fixes are good, there are times where it's better to just start over from scratch and that this is one of those times.

The most critical part of 6u10 to test is this new plugin.

In the pre-open source days .. the old days, back when we were arguing it wasn't necessary to open source the Java implementation .. to be honest I thought of Dalibor as a bit of a nuisance. Always asking embarrassing questions and I also thought the name 'Dalibor' had to be one of these made up screen names, and always wondered what his real name was. However over time we made our open source the Java implementation announcement. That made his questions less embarrassing, and I grew to know Dalibor, I learned that's his real name and I learned that he is a really nice guy with what I think of as an amazing approach to manifesting his vision for the world.

Dalibor, welcome to the team. I predict great fun.

Clearly women are under-represented in software development jobs. What I did not know is that women are even more under-represented in open source software development. This is a little surprising given that Free and Open Source Software (FOSS) stems from a yearning for freedom, but at the same time the FOSS community seems overly stereotyped to a male-dominated environment. They claimed that only 3% of open source developers are female. A bit of yahoogling turns up We assume FOSS benefits all equally. But does it really? and Ontario Linux Fest 2007 - Women In Open Source, Angela Byron (2007) and Opening doors to open source for women and linuxchix.org/ and Debian Women and Bridging the gender digital divide in FOSS and LXer Feature: Survival Tactics For Women In FOSS, part 1 ...etc...

Why is this important? I think the clearest answer is one they gave -- diversity. Diversity of experience should probably lead to better solutions than if the people involved have a narrow range of experience. Diversity means having people of all kinds within an organization, of all races, genders, intelligence levels, interests, sexual orientations, etc.

It's also kind of a strange situation -- there's nothing I can think of which makes men more suitable for software development than women. It's not a matter of upper body strength nor who can pee standing up. It's a matter of people possessing intelligence, the ability to conceptualize abstract thingymajobs, and describe those abstractions in software. Of course women are capable of these things.

This reminds me of a blog posting by Lillian Angel last fall ... how are women supposed to feel comfortable entering this male dominated field knowing they'll just be hit on because they're the only woman in the room? Lillian was sitting in the room and it was funny when Mark, the Classpath project leader, recounted how some Classpath project members just assumed Lillian was a guy. Ah, shades of Neo meeting Trinity... ("You're Trinity..the Trinity? I always thought you were a guy... Most guys do")

However there was an interesting angle to their presentation. The statistics presented were about percentages of software developers in software projects. However as in any endeavor there is more involved with creating a software project, whether it's FOSS or not, than just writing the software. Some critical pieces to a successful software project is documentation, testing, quality, marketing, graphics, logos, etc. Their claim is that while Women are under-represented in software development, they do tend to hold other jobs inside software org's like QA and documentation. I am struggling over whether this is good or bad or just is what it is. Yeah, that women tend to be under-represented in coding jobs is a concern and it would be great to even this out a bit, however in the bigger picture women are present in software development organizations. I wondered listening to their talk if they carried an idea that coding jobs have higher prestige or importance to the resulting software than the other jobs.

In any case as tomorrow is International Womens Day I thought to assist making this issue more widely known.

The thing I'm pondering the most right now is under which model we can collaborate about Quality in the OpenJDK. The immediate issue is the OpenJDK 6 project, and clearly it is not (yet) beta quality and does not (yet) meet JCK6a conformance. The quality is pretty good but there are some known bugs and it would be nice to fix these.

There is: Exchanging bug data up/down-stream .. test execution on OpenJDK, and sharing test results .. test development ..

At FOSDEM I hope to discuss these and other ideas ...

This is a very early release, there are bugs, and if you build from these sources they do not yet produce a compliant binary. The latter is being worked on.

Another recent related and important bit of news is the clearing of a major encumbrance .. [OpenJDK 2D-Dev] imaging and color classes binary plugs no longer needed (soon) discusses how we've recently gotten the rights necessary to relicense under the GPL the source for some classes critical to image and graphics rendering. The code is not yet in the OpenJDK6 release, we expect to get it there soon.

This 'end' is just the beginning of a new phase, because there is more work ahead in this. We have made an important step, but we are on a journey and this is only one of the steps along this path.


(11:09:40 AM) mr: http://mail.openjdk.java.net/pipermail/announce/2008-February/000056.html
...
(12:23:11 PM) rkennke: roman@mercury:~/src/openjdk6/control/make$ ../build/linux-i586/bin/java -cp ~/src/test HelloWorld
(12:23:11 PM) rkennke: Hello World
(12:23:18 PM) rkennke: hurray!


Suggests to me a model of using XML for server-server interchange, and then using XSLT to transform it to JSON when squirting data to a browser.

But then he gets to security. JSON relies on using eval() to run javascript commands and that squirts out a javascript object. Um.. that looks like a gaping security problem because that JSON could contain anything and a nefarious website operator (phishing anyone?) could wreak havoc. Maybe.

He does claim that XML data is secure because There is never a possibility that parsing XML data will result in code being executed. ... uh, gee, I have been looking at SVG files recently and the W3C official SVG test suite contains SVG files that use Javascript to do animation. It appears to me that in some instances XML files do contain executable code.

I'm generally agreeable with this.. I think the moves we've made to make for stronger support of other languages on the JVM is brilliant. I think the important thing is the platform, and really the virtual machine and the ecosystem of existing libraries that run on this platform. That fabled 'network effect' is helping us here.

But 'freeze' the Java language? Hmm.. unsure about that. The language changes which have been made have a poor history of causing adoption problems. But I think it's quite possible to add features to a language where they slide in and feel like a natural part of the langauge. I don't think, as Bruce suggests, that the only time to do language design is at the very beginning of a new language. I do think the early years of a language is critical to forming the language, but that to freeze any changes later may be a mistake. In general I think that frozen things, things which cannot change, are in an inevitable death spiral and that 'life' always means the ability to change and grow.

A couple thoughts I have are:-

Other languages running on the JVM ought to do a good job of integrating with existing Java classes.. the big value of the Java ecosystem is the existing stuff, and that's the big value the JVM offers to a language designer.

Changes to the Java language could be coupled with tools that help to convert source code to the new language features. This could especially make use of the compiler API that is now available and/or the jackpot tooling that is now in Netbeans. I think one of the issues making previous language changes difficult is the existing body of source code, and that if tools existed which robustly and simply made code changes then the migration ought to be easier.

Bruce made an interesting point about compatibility -- as a former member of the CCC team here inside Java SE engineering, I had a few years experience reviewing and approving platform changes. So, heck, compatibility when taken to the extreme we've taken it is really a double edged thingymajob isn't it? It provides some of the value to the Java ecosystem, that theoretically (absent bugs) you can take Java class files compiled in the stone age and still run them today. But it also provides resistance to fixing bugs or adding features, in some cases. This kind of compatibility may well be a heavy weight that over time interferes with the necessary change required to keep the Java ecosystem a living and breathing entity.

But this compatibility requirement goes beyond the language. It includes the runtime libraries of the core classes (java.* and javax.*) and behavior and signatures of the classes and methods therein. Even other languages running on the JVM are affected by binary compatibility requirements.

Hurm.. it occurs to me off the top of my head that a conversion tool could help here as well. Say for Java 8 the goal were to remove all deprecated methods and a few other changes. It could be declared that class file version n corresponds with that change. The JVM could then recognize "oh that's an old class file" and do something automatic like pull in a compatibility library, or do byte code transformations that changes the class files before execution, etc.

In any case the core thing I want to say is one general principle I understand is that things which cannot change are in a death pattern, and things which can change are in a living pattern. Which tells me that to suggest freezing a thing (the Java language) means to say this thing (the Java language) needs to die.

So maybe this is a brain fart..

I think the analogy might be that if Java-the-language doesn't support 'properties' then the only ones who can code in a property-like fashion are those programmers witty enough to implement the property-like features themselves. Those programmers could be analogized to be the 'bourgoisie' of marx's philosophy, and that there is a conspiracy preventing the proletariat from enjoying property in Java-land.

Or something like that... or it could be a brain fart on the last day before christmas break.

button.text = "Click me" as syntactic sugar for button.setText("Click me!") seems like a small improvement but it would set the stage for larger capabilities. Joe Nuxoll has talked about this at length in javaposse podcasts, especially regarding component-oriented programming. You can browse all the proposals on one wiki site and even vote on them.

Myself I find it tedious to continually write the boilerplate ..


private String name;
/**
* Gets the name of this widget
* @return the name of this widget
*/
public String getName() { return name; }
/**
* Sets the name of this widget
* @param name the new name of this widget
*/
public void setName(String name) { this.name = name; }


This kind of thing seems like prime territory for syntactic sugar.

On the #openjdk IRC channel one day last week we had an impromptu debate along these lines. One or more people were claiming Java (the language) sucks, that it should have several different uber-features, and basically that since it's not Haskell or some such it's a complete failure. As a language, that is.

Java the platform, Java the runtime environment, that is clearly one of the most successful cross platform runtime systems of all times. Cross-platform runtime systems have a long history, and my earliest knowledge of them is with Forth and with the UCSD p-System Pascal (which I ran, not on an AppleII but on a Terak PDP-11). Java the platform is near-ubiquitous, offers ever-increasing capabilities and performance, supports dozens of different programming languages, and does a great (not perfect) job of behaving well across platform.

Java should stay Java (?|!): Draws an interesting distinction between the uberprogrammers ("übergeeks that think in monads") and the rest of us. Tim Bray in On Closures draws a similar distinction. "My argument is simple: Java worked so well because it hit the 80/20 point; for my money one of the loudest, cleanest 80/20 technology victories ever. Subsequent attempts to fill in the 20% were, well, mostly harmless. Until generics, which are a disaster; they have made Java harder to learn and to understand, and you can’t avoid them."

I am very much in agreement with the points raised by these two. I can't help but remember Beta-versus-VHS being on the losing end by having bought the superior Beta VCR. This is my example of how the 'Best' is not necessarily 'Best'.

Just because some particular language has wonderful ubergeek features, does that make it 'Best'? There was a distinction Graham Hamilton promoted to the Java SE -- that there are a lot more average programmers than there are ubergeek programmers. If this thing we call Java were to be targeted only to the ubergeek programmers it would limit the potential audience for Java. Now, why is that important to anybody but Sun? Clearly this is important to Sun because the more Java appeals to a broad spectrum of developers the bigger a market we have to sell services into. However to the rest of y'all, this is also important because the bigger the Java market is the more work there is for Java programmers. It serves everybody if the Java market were to be as large as possible.

The nice thing about the Java ecosystem architecture is that it supports multiple languages. One can have a range of languages for the average programmer, and one can have language(s) for the ubergeeks, and through the magic of the underlying platform they can work together.

A practical example ... there are a couple ways to run PHP programs on top of the Java platform. This offers you an opportunity to hire PHP programmers to do the front end of a web application, while the business logic and enterprise scalability is written as Java services somewhere in the back.

So.. back to the debate of 'Should Java stay Java'... I don't have the technical background to properly evaluate the different Closure proposals. I have recently learned Groovy and like the way Closures are implemented there, and that's about as far as my preferences go.

But ... I think there's a distinction to be drawn here between Java-the-Language and Java-the-Platform. This distinction is, I think, sometimes lost on people.