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?