[harlanji]

> I think this change is unnecessary.

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.

[needusername]

> 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.