Month: March 2018

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…

Let’s Encrypt Wildcard Certs

Recently Let’s Encrypt announced that they would be supporting wildcard certs. I was pretty excited to hear about this as many times I would like to get certs for machines that might not be accessible on the internet. Currently I didn’t see an easy way to do this. With the new certs you could get a cert on your web server for your domain and use that cert on all the other machines in your domain that need TLS as well.

I decided to try it out and see how easy it was to do. I updated my certbot client to version 0.22 and did some google around and found out that you have to specify the new acme version 2 servers on the client command line in order to generate the wildcard cert. So I found the command and fired it up:

./certbot-auto --server https://acme-v02.api.letsencrypt.org/directory -d *.haskovec.com --manual --preferred-challenges dns-01 certonly

The command runs and asks you a few questions and then presents a DNS challenge. They give you a TXT record that you need to update in your DNS server to prove that you control the domain. I added the record and waited a couple of minutes and next thing you know it generated my new cert.

I updated my NGINX config to point to the new cert restarted the server and hit my site. Next thing I see is an SSL error. It turns out if you only have *.haskovec.com in the cert that isn’t a valid server for the base domain of haskovec.com. So I reran the command again and specified the following:

 ./certbot-auto --server https://acme-v02.api.letsencrypt.org/directory -d haskovec.com -d *.haskovec.com --manual --preferred-challenges dns-01 certonly

This time it asked me if I want to expand my cert to include the new domain name. I said yes. Next it had 2 challenges that I needed to insert into my DNS TXT record. I added them both and finished generating the new cert. When I restarted NGINX my site was back. I ran the https://www.ssllabs.com/ security test on my site and I am still at an A+.

All in all a very easy process and I recommend people give it a try.

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.

Spring Boot 2.0

Spring Boot 2.0 has finally arrived. Unfortunately we aren’t yet in a position at the office to be able to begin the upgrade so I decided to start playing around with it on one of my projects at home as I didn’t want to wait until we were ready to update our app.

The first thing I noticed about it they removed findOne() from CrudRepository. This to me is a bad change for all the users of the framework. It is one of the most commonly used methods in Spring Data, and not people either have to refactor their code to use findById() which returns an Optional<> of the type and deal with the optional instead of a null or you have to add a findOne with an @Query to all of your repositories. I have worked on projects in the past that have hundreds of tables and Repositories. This change is forcing them to update hundreds of classes just to upgrade to Spring Boot 2.0. It seems to me a better choice would have been to @Deprecated on findOne and encourage people to upgrade to the new findById method.

The next breaking change I found was also in Spring Data. They removed the delete() method from CrudRepository that takes an ID as the type. It has been replaced by a deleteById() call. There is no good reason for this change. In Java we have method overloading so the language can determine whether to invoke delete() with the Entity or delete() with an ID. It seems like they were trying to be consistent with findById() but they just end up breaking a bunch of code in the process. The only benefit that I can see with this change is groovy will get happier as it seems to be very poor at understand overloaded methods.

The next change I noticed was when calling new PageRequest(page, size) it was telling me that constructor was deprecated. To me this is the right way to handle the situation. I clicked into the method and it suggested to use PageRequest.of() instead. That was an easy fix that I made and seems more consistent with Effective Java about using static factory methods instead of constructors.

Finally I got all my unit tests updated to replace the findOne calls with the findById changes I had made and I went to launch the application and Hibernate fell over. It looks like the new version of Hibernate requires me to specify a GenerationType of Identity with MySQL where before it didn’t force me to specify it.

All in all it wasn’t too bad to upgrade my toy application. I am really looking forward to using Spring Boot 2.0 going forward, but a little disappointed by some of the Spring Data breaking changes. I feel like this could have been transitioned in to make it easier to upgrade existing Spring Boot 1.5.x applications. It is interesting that 2.0 is the first release to support running under Java 9, and it is finally released a month before Java 9 goes away and Java 10 is released. Up next for my test application will be switching it to Java 9 to see if I see any issues with that.