It includes the following minor fixes and updates:

1. Do not follow symlinks when cleaning a directory.
2. Avoid potential NPE when cleaning a directory.
3. Allow annotation processing of class files in jtreg directives.
   New option /process for @compile tag disables requirement that one or more *.java files must be given to @compile.
4. Set test.src and test.classes properties for @compile tasks.
   These properties can now be used by annotation processors invoked by the @compile task.
5. Recategorize -e option as a general option instead of a JDK one.
6. Set MKS to use case-sensitive compare in launcher script.
7. Remove obsolete reference to JAVA_HOME from launcher script.
8. (jtdiff) Avoid NPE in standard jtdiff if no output file given.

At least according to Symantec.

I want to make a screenshot, but I don’t know how to do this in Windows XP. I probably need the Ultimate Edition or so. God, this crappy OS doesn’t even have the most basic functionality, or it hides it so well that nobody finds it. No, the print key doesn’t work.

Folks, I really gave this OS another serious chance. Actually I was more or less forced to, due to my new job and new hardware and lack of Linux install CDs for 2 weeks in the US. But it so gets in the way of everything and is generally so unusable, I think I really do the same update that David Gilbert (*) mentioned in the article above.

Interesting side detail: I tried a couple of games in Windows that I tried in Wine before, it must be said that nowadays almost all games I would want to play work perfect in Wine (Heroes series, Starcraft, Baldur’s Gate, Settlers series), some show the same buggy behaviour in Windows as in Wine (SimCity4) and some others actually work better in Wine (!!), namely Settlers IV and Baldur’s Gate I. As far as I found out it’s a bug in the NVidia driver not supporting DirectDraw properly.

* David, is that you: http://en.wikipedia.org/wiki/David_Gilbert ?

Update: Ok, thanks to Robert I managed to make the print key work. Here is the screenshot:

With the release of OpenJDK, Sun donated to the World not only a big piece of Software and some gigazillion of men hours (and so money), they donated knowledge. This knowledge will be forever part of the humanity, because Java is a Free Software project now.

I have read since day 0 about Apache‘s childish complains about how bad is that or that other. The same childish complains that made Harmony one of the most significant Open Source failures of all the time, despite all the good intentions and efforts we put into it.

Now I read this article from Stephen Colebourne, linked here. This comes after a series of similar articles. Now, I follow Stephen since quite some time, and he is a really smart guy, with lots of experience, and I really do not intend to start a personal crusade, specially against him. The reason I chose his blog is because he describes things that are both of general interest and seem to share the point of view of Apache. I just ask myself few questions so.

Why Sun should, for whatever reason, give Apache access to the TCK? I mean, OpenJDK is already there, and nobody in the community needs anything else, with the few problems that still remain being addressed (Thye even let us run the TCK for Cacio, and this was before Roman joined Sun). Apache instead thinks Sun should just give access to the TCK, for free… Apache may be a non profit foundation, but it‘s backed by IBM and Intel, and can count on lots of money. Intel and IBM (above all) that have big interest there so much that they screwed on harmony when we tried to collaborate on it. Look at the Harmony code repository. Silent for months, at some point tons of code hits it, at least very weird.

Of course, it‘s all about the licenses, I realise it very well. With Harmony passing the TCK (come on, even if sun gives you access to it, I bet Harmony will never be able to pass a simple test from the suit anyway!), IBM/Intel would not need to be a Sun licensee anymore. They could use Harmony, call it Java, and never have the need to give back any code (because the funny Apache license allows that). As Radiohead would say, “We suck young blood“.

But what I don‘t really understand is this sentence, also from one of Stephen‘s blog entries:

“All the evidence I see is that Java SE is no longer an open standard and the next release will be JDK 7, not Java 7.”.

So, Java was an open standard? Cool, I never realised that, I‘m so bad. But now that the development is in the open for real, and Stephen should know, because he classified bronze on the Challenge with something that will be part of the JDK 7 code, I see the complains from companies like IBM (ops, I meant Apache…). Even Google, basically the only remaining big Harmony user in the World, is more clever, open and collaborative with the OpenJDK community, than IBM (ops again, Apache).

I think they should not be worried so much, if they can pay for the license, the TCK is a tool for driving money, they can make their business. Or if they cannot, well, they can just sit and code a better product, with less politics, people will eventually use it. Eventually.

Update: pun intended :)

"What do you want me to do?  LEAVE?  Then they'll keep being wrong!"

Back to the code :)

One thing that was always quite painful with Classpath (eh…) was mixing awt and swing components in the same application.

This is by definition painful, because of the heavyweight vs lightweight approach, and in Classpath we reverted to all sort of tricks to try to make it work correctly, often with poor results even.

The JDK support some mixing, but they also have problems in some corner cases. Today I wrote one of those corner case. It‘s a stupid app that has two panels, a swing and an awt one. In the panels there are few different widgets, some awt and some swing for each panel. There is a jlist that should cover the bottom panel and the awt/swing components when something from the list is shown, so there is pretty much everything. This setup doesn‘t work with the JDK, I get some painting problems with the widgets, the reason is that the app is poorly coded of course, no body would fix a bug report cause by this code, and I did on purpose to test what happens if…

Surprisingly, with Cacio on SDL it just work. SDL doesn‘t support multiple windows yet, so this came as a surprise, because we have to do the clipping by ourself and fake all the stuff, more or less like we did in Classpath back then. Because Roman wrote most of the clipping code and the full screen managed window, my kudos go to him! Here are some screenshots, left is the JDK and right Cacio.

Thanks to the generous sponsorship of the GNOME Foundation and GNOME Travel Committee, on Thursday I’m heading to the Gran Canaria Desktop Summit. This conference is a combination of GUADEC and Akademy and promises to be an excellent week of discussions, presentations, etc.

I’ll be giving a talk on Eclipse, focusing on our work at the Linux Tools project and of course showing the CDT and Mylyn and all the other awesome stuff I can fit into 30 minutes. I’ve been to GUADEC twice before and was really impressed with everyone’s enthusiasm. I’m sure this year will be just as good and I look forward to the inspiration that comes from conferences like this.

And the hardest part
Was letting go not taking part
Was the hardest part
And the strangest thing
Was waiting for that bell to ring
It was the strangest start

I could feel it go down
Bittersweet I could taste in my mouth
Silver lining the clouds
Oh, and I,
I wish that I could work it out

And the hardest part
Was letting go not taking part
You really broke my heart
And I tried to sing
But I couldn't think of anything
And that was the hardest part

I could feel it go down
You left the sweetest taste in my mouth
Silver lining the cloud
Oh, and I,
Oh, and I,
I wonder what it's all about
I wonder what it's all about

Everything I know is wrong
Everything I do it just comes undone
And everything is torn apart
Oh and that's the hardest part
That's the hardest part
Yeah, that's the hardest part
That's the hardest part

Coldplay

I guess I should say something too… Let‘s this speak instead…

I have done a massive amount of fixes to IKVM.Reflection.Emit to make it full featured (even though it still doesn't implement all Reflection.Emit APIs, the functionality should (almost) all be there, for example via different overloads).

I completed support for generics (I think) and fixed many bugs in that area, ikvmc only uses a very small amount of generics so these fixes are unlikely to affect it.

It's worth explicitly stating the design goals of IKVM.Reflection.Emit:

• It's a write-only API. Some GetXXX methods or properties may be implemented, but that's mostly for its internal convenience.
• There is intentionally no error checking. During ikvm development the error checking in System.Reflection.Emit has cost me a huge amount of time, it is generally much easier to diagnose the problem when you have a broken assembly file. PEverify and ILDASM are your friends.
• Code that uses System.Reflection.Emit in a write-only way is supposed to "just work" (modulo missing APIs, but those changes should be trivial).

I've done some pretty heavy duty testing on it. It should be ready for external (i.e. non-ikvmc) usage now. If you decide to use it (or consider using it), please let me know. As always, feedback is appreciated.

Changes:

• Added support for ByRef and Pointer types.
• Completed support for all literal field constant types and fixed null literal fields.
• Added ModuleBuilder.DefineInitializedData().
• Fixed many generics related bugs.
• Added a (non-standard) API to ModuleBuilder to set the PE image base address.
• Added TypeBuilder.SetParent().
• Added TypeBuilder.GetMethod() and TypeBuilder.GetConstructor() to instantiate methods on generic types.
• Added a (non-standard) API to ILGenerator to disable the "helpful" automatic leave/endfinally instructions in exception blocks.
• Added support for pinned local variables.
• Added UIntPtr and TypedReference signature encodings.
• Fixed handling of TypeBuilder enums in custom attributes.
• Added MethodBuilder.SetSignature().
• Added GenericTypeParameterBuilder.SetInterfaceConstraints() and .SetGenericParameterAttributes().
• Fixed (Method|Type)Builder.SetCustomAttribute() to set HasSecurity flag when SuppressUnmanagedCodeSecurityAttribute is set.
• Added support for defining events.

Binary available here: ikvm-refemit-0.41.3464.zip

Survivor: Eclipse DemoCamp Toronto Edition

On what was the hottest day of the year so far (at the time), about 25 intrepid souls braved the heat of the Red Hat Toronto conference room to attend the Eclipse Galileo DemoCamp Toronto. The group of attendees was very diverse with representatives from small companies, big companies, academia, and government. We had some great demos from some of the Eclipse Linux Tools Project team include Jeff Johnston on autotools and libhover, Kent Sebastian on OProfile integration, and Elliott Baron on Valgrind tools. Ioan Salau then demonstrated his eHealth Software Production Line followed by Remy Chi Jian Suen demonstrating fancy-schmancy ECF project collaboration. Andrew Ross brought some swag to give away and recorded the talks. They’re available for download here Thanks, Andrew and FOSSLC!

Afterwards, we went to the Rose and Crown for some refreshments courtesy of the Eclipse Foundation.

Thanks to everyone who came out.

Fedora 11 Release Party

It seems like we always have events on hot days. Last week, a bunch of us packed into the awesome Linux Caffe for a look at what Fedora 11 has to offer. Chris Tyler spoke about Fedora’s four foundations and I followed it up with a run through of the awesome Fedora 11 feature list. Much fun was had trying to fix things on odd hardware and many CDs, DVDs, and USB keys were turned into Fedora goodness. I didn’t manage to get any pictures or a headcount, but I think we had around 15 or 20 people hang out for a few hours and managed to attract some people who happened to be at the Linux Caffe anyway. Thanks to David Patrick for letting us host there and for the great food and drinks courtesy of Fedora. See you in 6 months for the Fedora 12 party.

"Wait, no, that one also loses. How about a nice game of chess?"

Short summary of happened and happening things:

• JavaOne2009: Great. Lots of faces to finally put on email addresses, IRC nicknames, etc.
• San Francisco: Great. Includes previous point. Plus: Seafood (oh my!). Extremely poor vs. extremely rich people. Lots of things that I almost got done, but not quite. Some photos.
• Cacio: Great: Of course. BOF went good, but attendence was low. Should have invited all the audience for beer instead. Seems we are not that famous after all Many small things improved before, during and after JavaOne.
• East Coast: Great. New job. Setting up stuff. Not much real work so far. Couple of interesting dinners and philosophic chats with new boss. And Terminator.
• Neil Young Archives: Great! First seen at JavaOne (yay). Seen again in record store. Could not resist. Must watch trailer.
• FontManager: Still trying to set a record for pushing the largest patch ever into OpenJDK Round 5.
• Family: Not great. Miss them quite badly. 3 more days to go…

I know I am supposed to write about JavaOne, my new Job at Sun, the USA, all the cool stuff that happens in Cacio, etc, but this is probably much more interesting: Is there an artificial god?

Did you see Bill's FindBugs slides from JavaONE 2009? You should create some step by step directions on getting started with NetBeans, FindBugs and the OpenJDK. We need to get developers working on this.
Humm, Ok, I'll look into that.
Don't just "look into it", do it!
Ok ok already, I'll "do it".
And try and talk about how to fix warnings, and especially the FindBugs errors, maybe talk about some kind of best practices.
Yeah yeah, and I'll take care of the world peace problem too.
Smart ass, how did you ever get this job in the first place.
Everything else I wanted to do was illegal, creating software seemed like the most criminal thing I could do that wouldn't put be in jail.
Oh geez, why does this seem like a Dilbert comic? Get to work!
Aye aye Captain! Batton down the hatches, full speed ahead, we be looking for the White Whale...
"Drink, ye harpooners! drink and swear, ye men that man the deathful whaleboat's bow -- Death to Moby Dick!"
Oh for heavens sake, maybe you should look into a mental institution.

Ok folks here we go...

My sincere apologies to the Whales and Whale lovers out there, just remember Moby Dick is just a fictional story and I am in no way condoning the slaughter of those innocent and fantastic animals.

NetBeans, FindBugs, and Hunting Moby Dick

For a developer that wants to actually change the source code, the very best way to work with a tool like FindBugs is through an IDE.

1. Get .

   Download and install NetBeans 6.5.1, I used the smallest "Java SE" version but any one of the "Java" versions will do. It installs quickly and easily. I would normally recommend the newer NetBeans 6.7, and I am trying 6.7 myself right now, but so far I have been unable to get the other steps below to work with 6.7, so I'd stick with 6.5.1 for now.

2. Turbo charge it .

   Configure the NetBeans memory settings for the best performance, this is optional. See my NetBeans performance blog. Effectively we want to boost the memory sizes to improve the interactive experience. Of course, if you have less than 1Gb RAM, you may want to avoid this completely or adjust the -Xmx number down:

   
   Mac1> mkdir -p ${HOME}/.netbeans/6.5/etc
   Mac2> cat >> ${HOME}/.netbeans/6.5/etc/netbeans.conf
   netbeans_default_options="-J-Xms256m -J-Xmx768m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m
   -J-Xverify:none -J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC
   -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled"
   

   NOTE: Keep in mind that if you run FindBugs inside NetBeans as I am suggesting here, you may need to adjust the above -Xmx number even higher depending on what you are running FindBugs on (e.g. how many class files or the size of the jar file). Running FindBugs as a separate process allows you to avoid using NetBeans heap space, but you won't get the good integration with the IDE that I'm advertising here, and what I think you need to actively work on fixing the bugs. FindBugs does use up some heap space, just make sure you have enough.

3. Get FindBugs .

   The NetBeans FindBugs plugin is a bit hard to find. You need to tell NetBeans where the UpdateCenter center is that has this plugin. The NetBeans plugin is not maintained by the FindBugs developers. To do this you need to start up NetBeans 6.5.1 and do the following:

   1. Select "Tools->Plugins".
   2. Select "Settings".
   3. Select "Add"
   4. Enter any name you want in the "Name:" field, and for the "URL:" field use:

      https://sqe.dev.java.net/updatecenters/sqe/updates.xml

      then select "OK".
   5. Select "Available Plugins", select the "SQE Java" plugin, select "Install", and go through the plugin install process.
   You should now see several new icons in NetBeans, specifically the icons for the SQE site , the FindBugs tool , and the PMD tool . My experience with FindBugs has been very positive and I trust this tool completely, rarely has it been wrong or given bad advice. On PMD, you will note that the PMD tool has the image of a gun in it's icon, for a good reason, be very careful with PMD, shooting yourself in the foot is pretty easy to do.

4. Find a NetBeans project to play with. My first example is jmake, a small Java project available from kenai.com. Get yourself a clone with:

   hg clone https://kenai.com/hg/jmake~mercurial ${HOME}/jmake

   Then use the NetBeans "Open Project..." to open up this directory ${HOME}/jmake as a NetBeans project. It should load up fine, build cleanly, and you can try using FindBugs to look at and even fix some of the bugs.
   Note: You need to be a developer member of the jmake project to push changes back.

   Or you can get sources, and either find a NetBeans project or create one. I chose to create one and picked the jdwpgen tool in the jdk/make/tools/ directory. So I did this:

   1. Cloned the OpenJDK sources (just a partial forest):

      hg clone http://hg.openjdk.java.net/jdk7/jdk7 ${HOME}/myjdk7
      cd ${HOME}/myjdk7
      hg clone http://hg.openjdk.java.net/jdk7/jdk7/jdk

   2. Tell NetBeans to create a "New Project", pick "Java Project with Existing Sources", naming the project "jdwpgen", and I'll locate this throw away project at ${HOME}/jdwpgen, then select "Next".
   3. Then I tell it to use the source directory ${HOME}/myjdk7/jdk/make/tools/src/, and select "Next".
   4. Then I specify build/tools/jdwpgen/** in the "Includes", and select "Finish" to complete the project definition. This process should work for any clean subset of Java sources in the OpenJDK, but I can't attest to that fact, yet.
   5. Try a build (should compile 50 files or so), run FindBugs, try and fix something.
      Note: You will need to be a member of the OpenJDK project and be able to create correct changesets to push changes back, this normally requires a BugID, and will require that certain changeset comment and whitespace rules are followed. (Yeah yeah, I know we are working on this, someday I'll be able to describe this better and it will all be open and completely logical ;^). Anyone outside of Sun that has tried to push changes into OpenJDK will confirm how difficult this currently is, but we are working on it.

That's it, play with it, try fixing FindBugs errors or compiler warning errors. Aye, we didn't manage to kill Moby Dick, but we sure sunk in a few good harpoons.

Command Line Usage

The FindBugs and PMD tools can be run from the command line to create all kinds of reports. You will need to download and install FindBugs and/or PMD of course.

Some sample FindBugs command lines:

findbugs -maxHeap 512 -textui -effort:default -low -exitcode ${HOME}/jdwpgen/dist/jdwpgen.jar
findbugs -maxHeap 512 -textui -effort:default -low -exitcode -xml:withMessages -output ${HOME}/jdwpgen/build/findbugs.xml ${HOME}/jdwpgen/dist/jdwpgen.jar

Some sample PMD command lines:

pmd.sh ${HOME}/myjdk7/jdk/make/tools/src text basic,imports,unusedcode
pmd.sh ${HOME}/myjdk7/jdk/make/tools/src xml basic,imports,unusedcode > ${HOME}/jdwpgen/build/pmd_out.xml

I use the command line versions when I just want the data for statistic purposes or as part of a batch build process, which I'll talk about later.

Mac, NetBeans/Ant, and PATHs

FYI... anyone that works with Ant scripts (all NetBeans users) has found out that the best way to get the Ant <exec> to work well is to set PATH properly, but controlling PATH from a GUI launch is tricky. For the Mac see my previous post on NetBeans, Mac and PATHs, which explains the Mac tricks needed to set the PATH for NetBeans.

For Developers, Hudson IS The Answer...

Have you used Hudson? If you haven't, you should, I'll blog about it more very soon, but to get yourself started, do this:

1. Download Hudson (hudson.war)
2. In a separate shell window, run:

   java -jar hudson.war

3. Go to http://localhost:8080/ and play with your very own Hudson, create a new job, browse the many plugins available,...

I'll talk about Hudson and how to connect it up to FindBugs, PMD, Warning Messages, etc. in a future blog...

-kto

The more I saw of this talk, the more I realize the scope here is ambitious - there is a pretty coherent vision in this demo and it’s broader reaching than I had previously understood. The vision includes a complete overhaul of how we compile, package, and startup our Java applications.

I was particularly impressed with the Project Jigsaw, the JDK modularisation effort going since Christmas last year. At Devoxx, Reinhold just talked about it, at this year's JavaOne conference, he demonstrated it with Ubuntu Jaunty Jakolope. The first that vowed was the removable of the CLASSPATH that had the crowd in "oohs and aahs". Reinhold show the JDK can be pulled from Ubuntu repository in stages and the JMOD command. He built a simple application that required the installation of the compilation, awt and swing modules. Jigsaw finally made a lot of common sense.

Further more Mark showed us a nice demo of the packaging and distribution of Java apps on ubuntu. De JDK modules will be normal debian packages and you will be able to create your own Java application, export it to a debian package and define a dependency towards the java modules you need to run your app. Quite nice.

The one significant project was "Jigsaw" which reduces the JDK into much smaller modules. For example desktop profile made up of base; awt and swing. Really does cut down on the core download. Oh for the day we don't have to download the Corba support all those useless classes which pollute code insight.

Mark Reinhold took over the presentation to discuss the JDK7 features. The focus is on modularity and multi-lingual capabilities. The modularity features (project Jigsaw) are intended to decrease download size for people without broadband (apparently more than a few), as well as supporting constrained devices. He performed a lengthy but very clear demonstration of the functionality provided by Jigsaw.

The main reasons to introduce Jigsaw into JDK 7 are the following:

* Eliminate classpath complexity (classpath/jar hell problem already discussed).
* Increase performance. The VM download size can be made smaller, and startup time should improve because for small programs (say HelloWorld) unnecessary classes don’t have to be loaded at all. Mark showed how he could run HelloWorld by only using 2 modules listed by the new jmod command; jdk.base@7-ea and jdk.boot@7-ea.
* Enable native integration for installing modules.

Then about Jigsaw. It is very focused on breaking up the JDK into modules. I like the native installers but I dislike the fact that they put this native packaging stuff in my face.

Highlights from my perspective:
* Project Jigsaw (Java 7 modules) – the modularization of the JVM and application libraries has a lot of promise, and can help cut down on bloat. The keynote demo of this went well.

One more thing to add - I have been following the Project Jigsaw public email list, and from what I could gather what was presented at Java One was more or less equivalent to what they could manage to get done by then.

A minor update.

Changes:

• Changed version to 0.40.0.2
• Changed build to generate rmi stubs instead of depend on .class files in openjdk6-b12-stripped-IKVM-0.40.zip. Thanks to Jo Shields for helping with this.
• Fixed verifier bugs. Thanks to Brian Heineman for reporting this.

Binaries available here: ikvmbin-0.40.0.2.zip.

Sources: ikvm-0.40.0.2.zip, classpath-0.95-stripped.zip, openjdk6-b12-stripped-IKVM-0.40.zip

L4 also has quite pretty threads, and each thread can have individual mappings. For instance, they can have each its own stack exactly in the same place of the address space. But in general it is a very tiny kernel; apart maps, threads and interprocess pipes there is almost nothing more there. This is not because of incompleteness, it is more a kind of concept.

However drivers seems being a biggest problem, even if we restrict interface to the network alone. It was a not so bad network driver for the NSLU2 chipset in the provided package, but the problem is that this hacker-loved slug seems no longer in production. Some German groups try to run existing Linux drivers under L4 in some emulation mode.

As we reported at JavaOne, a lot has been going on for javac over the past year.

Under the auspices of Project Coin, various small language changes are being considered: strings in switch, arm blocks, binary literals, large arrays, and the diamond and "elvis" operators. Project Jigsaw is investigating the use of modules; JSR 292 is providing support for the "invoke-dynamic" bytecode, and JSR 308 will provide support for annotations on types.

In addition, within javac, we've been finding and fixing bugs, including issues in the type system, and improving the diagnostics that may be generated. We've worked to produce an ANTRL-based grammar for the compiler, and we've worked with the OpenJDK release team to release javac as part of OpenJDK 6.