To highlight, here are the bullet points from Neil Bartlett's excellent post on that thread on how a modular JVM could help Java on the server:
- Could remove the concept and implementation of the classpath
- Results in modules that are swappable and able to be updated at runtime
- Provides modularity for security updates - for instance, there would be no need to pull down an update for the latest Swing fixes if your app does nothing but typical website delivery.
- Allows modules to advance at their own pace - thus decoupling the modules from the platform itself.
More important to me, however, are items #2 and #4. Seeing as how I work mostly with server side technologies (read: EE containers and service buses for SOA that are expected to have virtually %100 uptime), being able to, hypothetically speaking, allow my developers to use some updated package in what might be the latest and greatest Java (say JSR 310's new Date/Time API), for one portion of their app while sandboxing the rest of the app or other apps on the container so that they still use a preexisting package *and* without the cost of upgrading to the next major Java version along with potentially no need to restart the container, would be absolutely brilliant.
Of course, this is slightly pie in the sky thinking and I have not really considered the negatives... but one man can dream, can he not?
3 comments:
This certainly is interesting. I also wonder how this plays with things like OSGI (which is something I'm personally very interested in) and JSR-291 and friends. While things like OSGI don't go as far as eliminating classloaders, et al, it could be seen as a more tenable goal if parts of the standard libraries are bundled this way and offer many of the same benefits in HA scenarios.
Hi Jason, thanks for the link.
I have to point out that these are all potential benefits that I see from modularising the JVM. Depending on the implementation, we may not get some or all of those benefits.
You may have noticed from my post that I am a strong supporter of OSGi. My opinion is that Sun should leverage OSGi as much as possible in their effort to modularise the JVM, and doing so would result in the benefits you highlighted. However, previous module systems they have proposed (e.g. JSR 277) have been non-dynamic and also had poor support for properly decoupling modules, so if they go down that route again then you're likely to be disappointed by the result.
Incidentally, Apache Harmony successfully used OSGi to modularise its implementation of the core JRE libs, so we know it can be done and there is no real need to invent a new module system.
You can use OSGi today to modularise the rest of your server applications, i.e. everything above the level of the JRE. Many server application vendors are already doing this, including pretty much all of the Java EE servers you've ever heard of (WebSphere, WebLogic, JBoss and GlassFish are all using OSGi). Also many ESB/SOA servers (e.g. Mule, ServiceMix, WS02, Project Fuji) are doing this.
So, I don't think this is pie-in-the-sky at all. It's starting to happen already.
The sort of things you are talking about imply that the operation would, in effect, be that of a collection of separate libraries. I believe that would be a good idea, but problems could come out of it. Some form of versioning for each library would be necessary to prevent chaos.
Post a Comment