Glyn Normington: It’s interesting to speculate what would have happened if a static module system had been put into Java much earlier. My guess is that it wouldn’t have bothered to address versioning or dynamicity requirements which only become crucial in the context of relatively large systems with continuous operation.
Indeed it is interesting to speculate. Mono and .net are both implementations of the Common Language Infrastructure. They have had a static module system from the beginning and they power many applications from best in show MP3 players to relatively large systems with continuous operations such as myspace and shortly second life.
CLI implementations and JVM implementations couldn’t be more different. While at first glance they appear very similar, they both have an intermediate language and they both use a JIT, the similarities seem to end there.
CLI implementations have been designed to apply classic compiler optimizations using code analysis techniques just like those found in a typical C++ compiler. For example their approach for method inlining is very simple. They also JIT all code once on first use. They can do this as most of the CLI languages have been designed for compilation using classic analysis techniques.
JVMs, on the other hand, use runtime knowledge to decide what to optimize. Rather than using the classic techniques they guess a lot (e.g. on whether a method can be inlined) and they have to keep these guesses around in case they load a class that invalidates them. They also have different levels of optimizations that they perform, saving the most aggressive for code that is getting used the most (i.e. the hotspots). They use these approaches as the class loading rules in java make the application of code analysis techniques virtually impossible.
So which is better, I think the jury is still out, and they both have strong supporters. However, CLI implementations have one big advantage over JVMs. As they rely on classic static analysis CLI modules can be ahead of time compiled to native binaries. This brings many advantages such as improved startup and better memory sharing between processes, the latter being a key requirement if multiple applications are being run on a single workstation.
As such, the forthcoming language level changes for Java modularity along with the corresponding changes to the runtime provide a unique opportunity. They could be designed as a static module system like the one in the CLI. To do this they would need to change the classloading rules for classes in modules, but this would allow JVM implementations to ahead of time compile java modules to native code bringing all the advantages I mentioned above.
I really hope the expert groups design with this flexibility in mind and I see that I am not the only one that has seen the potential.
Update: I posted a follow up pointing out how subtle language differences have lead to the two different approaches to the runtime.