Java 10, already!

Java 9 we hardly knew ye, yet here we are and today was the GA release of Java 10. This is especially true for those of us using Spring boot as we just got official Java 9 support a couple of weeks ago and now 10 is out. From my standpoint the big features of the release are the Root Certificates. Java 9 shipped without root certificates if you used OpenJDK which in my mind makes it less useable as now you have to with that, you can’t just run it and go. That is what was keeping me on Oracle’s releases of Java. Now in Java 10 there is no difference with the oracle JDK and the OpenJDK so I will probably just deploy my apps on OpenJDK in the future. That simplifies Linux installation as now you can just run apt-get install and go. Before I used to have to add the ppa for Oracles and install it and then deal with the strong crypto policy files. All those old pain points are gone.

The next big change is Parallel Full GC support in G1GC. In Java 9 they changed the default VM to G1 and now they have enhanced it so that if you have to run a full collection it will at least run in parallel and reduce the pause time for your application.

The feature all the developers are talking about is local variable type inference. So now you can write:

var list = new ArrayList<String>();

Instead of:

List<String> list = new ArrayList<>();

The thinking being the name of the variable is the most important part and this may make the code more readable. For me I am not completely sold on this change. I think in some circumstances it may make the code more readable, but in other cases it will be worse, so I am taking a wait and see approach with using this style.

The other small developer feature that looks good to me, are APIs to create unmodifiable collections. I could see myself using that a lot, and it will be nice to no longer need Guava for some of these things. Instead of thehorrible old:

List<String> list = new ArrayList<>();
list.add("String 1");
list.add("String 2");

return Collections.unmodifiableList(list);

And making sure that you aren’t leaking the original reference you can just do:

var list = List.of("String1", "String2");

or if you have the list shown in the first example and you want to lock it down you can use:

return List.copyOf(list);

which I think reads better than:

Collections.unmodifiableList(list);

and it is obvious that it is making a copy so you don’t have to worry about leaking the original reference.

Other than that there is better support for the VM to realize it is running in a docker container and only assume the resources assigned to the container instead of reading the OS values. Otherwise there isn’t a lot there. That being said if you have managed to get on Java 9 already in production you need to upgrade right away as 9 is no longer supported, and you need 10 to make sure that you have all the latest security fixes.

Finally I will leave you with this:

Java version text

The times they are a changing…

Java 9 Upgrade

After upgrading my test app to Spring Boot 2.0 yesterday I decided to see how difficult the Java 9 upgrade was from there. I am happy to report that it was fairly trivial. I upgraded my maven pom to set the Java version to 9 and did a mvn clean install.

Immediately I see some no class def exceptions around javax.transaction.Transaction. I did some quick google searching and discovered the problem seems to be in the Maven Surefire plugin. I found a work around that said to set the version to 2.20.1 and added a command line flag of –add-modules javax.transaction. After doing that I was seeing errors around java.xml.bind. Doing some more searching I then added a second –add-modules java.xml.bind. This fixed the issue. In the course of doing so I found a link to the issue on apache’s website. Reading through the comments I ended up with a final configuration of 2.21.0 with the following options:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.21.0</version>
            <configuration>
                <argLine>--add-modules java.xml.bind</argLine>
            </configuration>
        </plugin>
    </plugins>
</build>
Once I dropped that configuration into my pom everything built and ran correctly. So once you get your app to Spring Boot 2.0 the jump to Java 9 is pretty seamless. My follow up change now will be to switch to the new factory methods on List and Set in the app to take full advantage of the features. Once Java 10 drops in a couple of weeks, I will take the App to 10 and see how that goes.

Upgrading to Java 9

Upgrading to Java 9

Ever since Java 9 was released last fall, I have been wanting to upgrade our software at work to the new platform. I am not interested in the new module stuff, mostly I just want the convenience methods like List.of(), and the platform improvements. I think G1 by default looks good, the new representation for strings to save memory looks like a huge win, and all the performance numbers that I have seen show it to be a big win. Unfortunately this is not as straight forward as one should hope.

Step 1 – Spring Support

Even though Spring 5.0 was released back in December I think which fully supports Java 9, Spring Boot 2.0 is not yet released. I believe it is in RC2 now and about to be released in the next week or so, but at this point we are less than a month away from Java 10, before we will have proper Spring Boot support in Java 9. All of our microservices are currently running on Spring Boot 1.5.10 except for one. It is still running on the 1.3.x version of Spring boot, which brings us to our second Spring issue to resolve. Some contractors that originally started that service did a hack to lazy load @Formula s in hibernate. While this worked in Hibernate 4.x in Hibernate 5 the hack no longer worked so we can’t even update this service until we refactor those entities and move that data into views. That is still a work in progress. The other microservices could be moved to 2.0 when it comes out, but I think their is a consensus that we don’t want to move to 2.0 until we have all our services to a place where we could do that.

Step 2 – Gradle

We are currently running gradle 3.5.1. Going to Java 9 is going to require Gradle 4.2 (which is also a requirement for the Spring Boot 2.0 Gradle plugin). Normally this is no big deal upgrade the gradle.build file edit the wrapper portion to the new version run ./gradlew wrapper and check in the new gradle wrapper. But in this case we still have a developer running on IntelliJ 2016.1 and another on 2016.2. They would have to upgrade to at least 2017.2 in order for the new gradle to work with their IDE. So we will need to convince the whole team to update their IDE if they haven’t already ideally at that point to 2018.1.

Step 3 – FlywayDB

We are currently using Flyway DB 4.2.0. This didn’t work with Java 9 when I was testing it, so we need to go to 5.0.x. Additionally Spring Boot 2.0 requires Flyway 5.0.x. Ideally we want to upgrade this ahead of Spring to minimize risk. Bring the new flyway into production and then once we are satisfied that it doesn’t break anything upgrade Spring Boot.

Step 4 – Docker Containers

Once we have all that software in place we then will have to update our docker containers to pull in the new JVM. It sounds like in Java 9 Linux, OpenJDK ships with an empty certificate store. So that means finding a Oracle or Azul docker container as our base. We then have to verify that New Relic works with Java 9 so we have our container monitoring. After doing all that we can update our base VM to be Java 9.

Step 5 – Update Jenkins

We will need to add a new VM to Jenkins so that as different builds switch to the new Java 9 container we also switch to compiling them with the Java 9 VM (though with the Java 8 flags still at this point).

Will the pain never end…

Finally after doing everything listed above we could change our compiler flags to 9 and start using the features. It is still a painful road to walk to get us there. At this point it feels like by the time we finish the work that needs to be done (as obviously we need to be shipping features and bug fixes, while we lay the foundation for this on the side) Java 11 will be out and we will be moving to that.

Even though Java 9 support is so close to being out in Spring Boot I still feel like I am at least 6 months away from getting to use any of it. This feels much more painful than when I moved an App from Java 7 -> 8. At that point I think it was just a matter of coordinating a JBoss container upgrade from 6.0.1 to 6.4. After we got that into production we updated the VM to Java 8 (still with everything compiling on 7). Then we upgraded our Jenkins machine to have Java 8 for the compiler, and finally we updated our maven pom to use source and target of 8. I wonder if anyone Spring shops will even make it to 9 or if everyone is holding out for 11 at this point (also to get the LTS release). While I really like the sound of the 6 month release cadence actually getting the dependencies in place and lined up to do an upgrade will probably mean most enterprises just end up going from LTS release to LTS release and I would guess that Java 9 and 10 see very little use running production code and mostly will just be things for developers to play with on their machines.