JVM developer her (Java and more recently Kotlin). In an era where microservices are becoming increasingly popular I think this change is unnecessary. This was needed back when Java 6/7 was king and people were still investing heavily in monolithic architectures.
I am really not convinced this does anything besides make Java development more painful for those of us who are building small self-contained services with limited scope and library dependencies.
On the positive side this looks like a road forward for minimizing the size of a JRE in a world with AOT compilation. It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable. I've only been loosely following but it looks like the jlink and jaotc tools shipping with JDK9 may make that possible.
Just the opposite, faster startup time and lower memory footprint for the JVM via modules would be great. Both via process start, storage read, container image transfer. It'd also be a boon to JVM based dynamic languages by extension.
Albeit if you're layering images the cost could balance out over time in deployment. The runtime density would be increased overall with modules though.
> It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable.
This is where go wins over JVM hosted languages, it'd be nice to bring JVM into new domains.
> Just the opposite, faster startup time and lower memory footprint for the JVM via modules would be great.
Why would modules lead to faster startup time and lower memory footprint? Java class loading has always been lazy, if you do not need a class it will not be loaded. If anything modules should increase startup time because additional runtime checks needs to be performed and increase memory footprint since additional metadata needs to be referenced. Modules do not affect memory layout of Java objects.
With AOT compilation, you are not minimizing the size of the JRE. The Java bytecode is more compact than any assembly code because it is more high level.
So with jlink, you are reducing the size of the JDK by creating your own JDK and with jaotc, you are augmenting the size of the JDK but have a faster startup (not sure) or at least less jitter (no JIT) (sorry for the pun).
I think you're in agreement with meddlepal. The idea is that if you want to do AOT, it would be nice to be able to minimize how much of the JRE you need to link in (via help from the module system).
It's been a while, so I'm not up on the latest Jigsaw details. A while back I was working on building traditional Java (Spring MVC/Spring/Hibernate) web applications using OSGi. At the time, I hit some non-trivial challenges with any library that used a class discovery mechanisms that assumed a flat classpath. Jigsaw is purported to be simpler, so hopefully it's not a big issue, but when our team starts using Java 9, that'll be one of the big risks I'll be looking for.
At the same time, I am excited that many issues with transitive dependency resolution will be easier, and it will be easier to enforce code architecture principles (i.e., not just calling whatever code from whatever place just because it's on the classpath already).
Java dev here. Modules are great, they provide encapsulation on a higher level: can encapsulate classes, interfaces, etc. behind a well defined module interface. They help reducing object-oriented spaghetti code.
I am really not convinced this does anything besides make Java development more painful for those of us who are building small self-contained services with limited scope and library dependencies.
On the positive side this looks like a road forward for minimizing the size of a JRE in a world with AOT compilation. It would be really nice to be able to ship self-contained, executable binaries for native targets with the entire runtime embedded in the executable. I've only been loosely following but it looks like the jlink and jaotc tools shipping with JDK9 may make that possible.