Skip to main content

Worried about Java 7? Go with Hudson (or Jeskins)

Posted by fabriziogiudici on August 2, 2011 at 1:34 PM PDT

A few days ago Java 7 has been released and there has been some discussion about a few critical bugs discovered by the Lucene team. As usual, the thing got amplified by some other blogs and media, with titles such as "Don't use Java 7" or "Java 7 is buggy". Well, if you read the details, the point is that some optimizations of Hotspot, now active by default, can lead to a crash or - worse - incorrect computation results. But so far only the Lucene guys seem to having substantially experienced the problem. One of the involved bugs was discovered a couple of months ago, but it was filed with low priority by Oracle since it was supposed to happen seldom - until they discovered that Lucene triggers it continuously. The other two bugs were discovered a few days before the release.

Now, Java 7 is probably buggy as any other piece of software (this holds true unless others experience serious problems). Java 6 and all the previous VMs suffered from HotSpot bugs as well, and we happily lived so far. The point, in fact, is how high are the chances to have them triggered.

But my point is another. There's a new major Java release out there and, as usual:

 

If you didn't test it, it doesn't work. Period.

 

I bet there are chances you'll find other integration problems with your software and Java 7, rather than the HotSpot ones that got the media hotspot (pardon the pun). For instance, if you read the above mentioned Uwe's blog you'll learn some interesting stuff about tests failing because of the order of invocation of methods.

 

So what? Should you go out and running in the streets screaming in panic because "Java 7 is buggy"? I think there are more interesting things to do.

Since I've not tested any of my pieces of software with Java 7, I suppose they just don't work. I'm not particularly pressed to use the new Java in production and my FLOSS software is not at the top of the popular open source list, so I don't think there are high chances I'll receive in a short time a request for fixing an eventual bug with my stuff running on Java 7. 

But since I have a CI system I can anticipate the issue without too much effort. I think this is the real point that everybody should address about Java 7:  don't worry (too much) about others' bugs; just run your test suites against Java 7 and draw your conclusions.

With Hudson / Jeskins it's pretty easy, thanks to "multi-configuration projects". In a few words, they allow you to define some "axis" associated to a property with different values, so you can repeat the build and the test run for each value of the property. One of the values of the property can be, you guess, the JDK.

 

 

I've used multi-configuration projects in the past, when Java 6 came out, so I could make sure my stuff was both compatible with Java 5 and 6. Then I disabled them when Java 5 reached EOL. Today I've resumed them, with some new feature to improve things. In particular, I've configured this POM fragment in my superpom (hence I get it in all my projects, given an upgrade):

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <executions>
            <execution>
                <id>generate-and-print-build-properties</id>
                <phase>validate</phase>
                <goals>
                    <goal>run</goal>
                </goals>
                <configuration>
                    <target>
                        <echo>Java Version: ${java.version}</echo>
                    </target>
                </configuration>
            </execution>
        </executions>
    </plugin>

This confirms to the console the JDK used by each build (well, it's something of overkill to use the maven-antrun-plugin just to echo a message, but I'm not aware of other solutions that allow property interpolation - in any case, in my builds I have some other things done by that plugin, so it makes sense for me to use Ant).

One problem with multi-configuration projects is that they are not compatible with first-class Maven jobs (this is true up to Hudson 2.0.1 for what I know, didn't check the latest release). But it's not really a problem. In a serious software factory you have multiple, staged jobs for each project. Whenever I commit, a Maven job kicks in to compile and run tests as fast as possible, with the JDK 6 that is my reference. Another job runs the Cobertura, Findbugs and all the metrics stuff, scheduled overnight. It's precisely this job that I configured for trying multiple JDKs.

 

Now I'm adding the JDK 1.7.0 configuration for my projects, and so far no apparent problems (but I've just started with the smaller ones).

 

 

Related Topics >>

Comments

&nbsp;Instead of using maven-antrun-plugin just to echo the ...

Instead of using maven-antrun-plugin just to echo the Java version property, check out the maven-enforcer-plugin:display-info goal. It will output information about Maven and Java versions in a nice, compact, 3-line block.

http://maven.apache.org/plugins/maven-enforcer-plugin/display-info-mojo.html

&nbsp;Instead of using maven-antrun-plugin just to echo the ...

Cool tip, thanks.

&nbsp;Jenkins not Jeskins. http://jenkins-ci.org

Jenkins not Jeskins.

http://jenkins-ci.org

<p>Java7 breaks not only&nbsp; Lucene's staff - this is not ...

Java7 breaks not only Lucene's staff - this is not quite correct statement. Try to run, for example, jhepwork (http://weblogs.java.net/blog/editor/archive/2011/05/16/jhepwork-powerful...) project on Linux and you will find that it's broaken (while it works fine with Java7 on Windows - this is a clear indication of a bug!): All examples in [Tools]->[JHplot] are failing . This is a rather serious bug which seems related to repaint of JComponent. The main reason of the bug is the VectorGraphics package http://java.freehep.org/vectorgraphics/ which does not work anymore with Java7 on Linux. To see it, grab VectorGraphics binary files, , or even compile them, and run the standalone example in src/main/examples/ExportDialogExample.java). The VectorGraphics package is in the core of many applications which are now broken on Linux. Note that the bug was reported repeatedly.

<p>For Lucene I was explicitly referring to the HotSpot ...

For Lucene I was explicitly referring to the HotSpot bugs. I don't have doubts that many other pieces of software will experience problems with a major upgrade of Java: it's the meaning of my whole post (summed up in the sentence "I bet there are chances you'll find other integration problems with your software and Java 7, rather than the HotSpot ones...!).