Java Advanced Tools - Errata for Thread Safety

In Chapter 20 of the Java Advanced Topics course (the video on Synchronization and Thread Safety), at about 20 mins 15 seconds, I explain that you tend to use the synchronized keyword with the smallest possible code block. I demonstrate this with the following code:

Unfortunately, for the example we have been looking at, this wouldn’t be thread safe! It would be possible, if a thread was interrupted after the synchronized block, but before the return statement, for 2 threads to be given the same number.

Thank you to one of our customers who pointed this out today – the synchronized keyword needs to be around the minimum part of the code that should not be interrupted. In this example it would need to be the entire method. 

Java 9 – custom Runtimes… would you actually use them?

Last month I posted about the issues affecting the Jigsaw (modular Java) features within Java 9. As we approach the release of Java 9 (which we currently expect to be at the end of July, but who knows if it will be delayed again?), this time I thought I should talk about one of the other features of Java 9, creating your own custom Java Runtime Environments.

The idea is that the Java Runtime Environment (JRE) has been split into a number of modules in Java 9 (see the last blog post for details about what we mean by modules). So when you build your own applications, the users who will run them don’t necessarily need the entire JRE, but could use a cut-down version.  I’ll talk in a paragraph or so about why you might want to do this.

The process to create a cut down version, containing only the parts of the JRE that are needed for your application looks quite straightforward (I saw a demo of this at the recent London Java User Group hackday) but two points did stick …

1.      The process to create a cut-down version of the JRE uses the JRE installed on the computer being used to create the new version. So for example if you’re using a Mac, then you can create a cut-down JRE for the Mac, but if you’re application is going to potentially be run on a Windows or Linux machine, that’s not going to work. You’ll need to use a Windows or Linux machine to create compatible cut-down runtimes for those environments too.

2.      Once you have created the new runtime, there’s no easy way to distribute it – what you are effectively creating is a folder with lots of sub-folders and files in… but you’ll need to provide all of these to your users with some instructions on what to do with them (such as creating the environment variables). The system (at least for now) doesn’t create a nice user-friendly installer for your cut-down JRE.

In practice this almost certainly means that you won’t be creating cut-down JREs for applications which you plan to sell to the general public… you’re more likely to do it only where you are deploying to hardware that you have control of. 

That probably makes sense, as for most users there is no obvious need for a cut-down JRE – the main benefits of a reduced JRE would be lower storage requirements (where disk space is limited) and possibly reduced memory requirements (e.g. in an embedded device where RAM is limited). If you’re creating an application to run on an embedded device, and so you know the specific hardware, and operating system that needs to be targeted, and that this won’t be generally accessible by the public, then this could be something you will benefit from.

Given the ever lowering cost of storage and RAM, you might wonder if this is really going to be a sizeable need, although even in server environments there could be a genuine use case. If you’re creating microservices, that are going to run in a cloud platform such as Amazon’s AWS, making them as “lightweight” as possible, so that you can get reasonable performance from the cheaper, lower spec EC2 instances, might deliver some considerable cost savings.

Another issue which may crop up from this is what happens when the Java runtime needs updating with security patches etc. Will the developer need to continually create new versions of their runtime for distribution? If so then systems with a reliance on developers to provide a patch for a security issue in a JRE sounds like a real potential for disaster!

Initially my reaction to all this was that this will be another feature of Java which very few people will want or use, but I’m now wondering if this actually presents an opportunity for a service to come along and make this useful….

I suspect in due course we’ll see a “centralized custom JRE service”. Developers can register their applications and tell the centralized service which modules within the JRE their application needs. The centralized service can then create custom installers of the cut-down JRE for various platforms, and the developer can tell their customers to click on a personal link to download and install that JRE.

Then when security patches are released, whereas Oracle’s standard Java calls home to Oracle to find out about updates, the custom JREs could call home to the centralized service and get their updates from there.

I’m sure I’m not the first person to think of this, so I won’t claim copyright (or royalties if you have a go at implementing the idea) but it does feel like something like this would make the idea of custom JREs actually useable… maybe something for an enterprising startup to consider in due course?

The latest on Java 9... will it be delayed, features removed, or released with problems?

In case you’ve not been following the progress of the next release of Java SE,  Java 9, we thought we should let you know what the current status is (or at least our current understanding of it!).

As you might expect, the next version of Java will have some changes in it from the earlier versions. By far the biggest, is the introduction of Jigsaw, an API for building modular applications. Some have described this as a bigger change for Java than when generics were introduced back in Java 5.

If you’re not familiar with modular applications, then in simple terms the idea is that you can split larger applications into smaller parts (modules). Each module can depend on / use other modules, but they’re built as separate projects, and compiled into separate Jar files. There are quite a few potential benefits to this approach, but perhaps the most useful is that if you need to change a single module, you can do that without needing to amend or recompile any of the other modules. There's more to it than this, but that's a very simple high level overview.

If this sounds familiar (you may be thinking about microservices) well it’s another way of solving the same problem that microservices solves, at least in terms of building smaller, more manageable applications rather than monoliths.

Actually if you have a need for modular Java right now, then you don’t need to wait for Jigsaw – the OSGi framework (https://www.osgi.org/) provides this today, and although I've never used it personally, everyone I have met who has say it works well. Unfortunately Jigsaw isn’t compatible with OSGi… I guess there are some politics involved as to why they didn’t adopt OSGi as the standard!

So that’s the background… what’s the current status?

Well Jigsaw is having some problems. I have tried using it myself, with the current beta release of the Java 9 JDK. I thought it might be an interesting and useful exercise to take an internal Spring Boot based application that we use at Virtual Pair Programmers, and upgrade it to make it modular.

Unfortunately I ran into some problems doing this, including:

• Maven doesn’t work with Jigsaw right now. So if you want to build a set of modular Spring Boot applications, for example, well it’s possible in theory but highly frustrating in practice…. it involves writing a number of shell scripts and delving into the file system to work out where all the maven dependency jars have been put, so that you can reference them in your compilation scripts.
• Eclipse doesn’t really cope well with Modular projects right now. It can be used to edit them (although you’ll do some frustrating manual moving around of the file structure to get it to work) but you can’t currently create a modular Jar / War file from Eclipse. Again you'll end up writing shell scripts to do these. We understand that other IDEs have similar issues.

This means that today, Jigsaw is really not ready for use.  We recently attended the London Java User Group’s hackday to get an introduction to Java 9, and certainly left there with a feeling that the modular approach is going to take some getting used to… and without full integration with familiar build tools and IDEs, it won’t get widely adopted. 

It seems that more widely within the Java community our view that Jigsaw isn’t ready is shared… and not just for the reasons we have come across. Currently 13 of the 23 organisations that have a vote on the Java Committee have voted no to Jigsaw being ready to release (https://jcp.org/en/jsr/results?id=5959).

Currently Java 9 is scheduled for release on July 27 2017. Whether it gets delayed, it gets released without Jigsaw, or the Jigsaw issues get sufficiently fixed in time, we’ll have to wait to see!

Installing Groovy - which version to go for?

Since we released the Groovy course, there have been some changes to the hosting of the Groovy distribution files. The newer versions of Groovy are completely compatible with the course, so you're fine to use any, but you'll need to download them from:

http://groovy-lang.org/download.html

Please note that for Windows users, the latest version may not have a windows installer available. To get started quickly you may wish to check a prior version with a Windows installer. At the time of creating this blog post, 2.4.11 is the latest stable version of Groovy, but if you want the Windows installer you'll need to get 2.4.10.

We also mention in this course that at the time of recording we were planning a course on Grails. We held off for the release of Grails 3, we knew that each version of Grails tends to break something in earlier versions / is not always backwards compatible. Unfortunately the Grails project has lost popularity in recent years (mainly due to political reasons I believe) and so a course on Grails has not been a viable option.

However for fans of the Groovy language, it's perfectly possible to create Spring Boot applications in Groovy - and indeed this is effectively where Grails was heading anyway. So Combining Groovy and our Spring MVC / Spring Boot courses will allow you to build production quality web applications in Groovy... and that's our recommended way forward!

Errata for Hadoop course - Installing Java with Ubuntu

In chapter 4 of the Hadoop course we set up a new Virtual Machine, running Linux. This step is not needed if you're already using Linux or a Mac to run the course, but is needed for Windows users.

In the course we install the Java JDK version 7. However this is no longer available from the repositories, and you'll now need to use Java version 8. We've tested the course with this version of Java and are not aware of any issues.

To install Java version 8 issue the following command:

sudo apt-get install openjdk-8-jre-headless

instead of

sudo apt-get install openjdk-7-jre

Errata - Java EE Module 1, Chapter 6

We've recently been made aware of a small issue which affects chapter 6 (the CDI chapter) of Java EE with Wildfly, Module 1. You might experience this issue if you're using some versions of Java 8 to create your project - we're aware it is a problem in Java 8.60 and above.

In the video we talk about the different ways to tell JavaEE which implementation of a particular interface should be injected at runtime, when multiple implementations exist in your project. We first demonstrate the @Default and @Alternative annotations, then we look at specifying the required implementation in beans.xml, and finally we discuss qualifiers, which allow us to specify a different implementation in one specific area of our code.

In the video, we end up with all 3 methods in our project in use at the same time, and this worked fine at the time of recording. However we have found that when you then add in your own custom annotations (such as @ProductionDao - the example we use in the video) the deployment might fail. It appears that there is a bug in Java 8 which means that you can't use custom annotations together with beans.xml.

So you are fine to use @Default and custom annotations together, but not beans.xml and custom annotations. As most users will agree that using @Default and @Alternative are much easier than editing the xml file, this probably won't cause much difficulty in practice, but if you are getting a message that the build has failed, this will be why. If you're following along with the chapter, simply remove beans.xml from your project, and you will be able to continue with no further issues.

Why I have never attempted to teach JavaScript...

It must be time for the "which is the best programming language" debate again... Here's an interesting article that claims "Jobs-wise, you’d be hard-pressed to find a better language than Java as your primary programming language" - that does seem to reflect the reality we see... actually the comments are even more fascinating than the article! 

http://www.theregister.co.uk/…/03/03/pizza_roaches_and_java/