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?
