JVM restarts/availability JSRs
I made a comment in my JVM restart post about some JSRs that address server restarts. Here are the JSRs and how I see them solving some of the problems.
121: Application Isolation API
This JSR addresses the need to have mini-JVMs inside a single JVM that are completely isolated from each other. They can be stopped, started, restarted, etc without impacting anything else running inside the overall JVM. This reduces the ramp up time considerably and is similar to how some VMs manage processes rather than managing entire VMs. This one actually completed last year. I’m very interested to see if it gets rolled into things because it could be extremely powerful.
277 and 294: Java Module APIs
This is similar to OSGi support that was approved in JSR 291, however it makes modifications to the JVM, which aren’t really addressed in 291 (from what I know, which is minimal). This JSR allows more freedom to control class-loading and management of classes within boxed contexts. It probably does not address threading issues related to mis-behaving classes inside a context, but together with JSR 121, this would be a excellent solution. Let’s hope Sun has the vision to see this as well.
284: Management APIs
This one comes from the folks at Google and addresses utilization and management of processing within a JVM. It specifically addresses the need to terminate mis-behaving processes within the JVM.
291: OSGi
This one seemed like it was marshaled through the JCP just to battle 277 and 294. I think OSGi is great, but it doesn’t address many of the JVM level problems in very large, high availability applications. It really only addresses services and how they are separate but accessible. I’d much rather see 277 and 294 fully realize what the JVM should have in terms of modularization and separation of executing. If we could see truly separate execution spaces within a JVM that strongly define their public and private interfaces, we could gain a lot of stability without requiring what I believe to be dangerous restarts.
About Brian Pontarelli
Brian Pontarelli is the founder and president of Inversoft, a Colorado based software company. In addition to Inversoft, Brian works on many open source projects including Struts, Savant and Java.net commons. In the past, he was the president of the Chicago Java User Group and an enterprise architect for Orbitz.
Brian has been programming for many years and works primarily with Java and Ruby. He has published various articles in both print and online magazines about Java, J2EE security, Java Server Faces and NIO.
More About Brian »Why Attend the NFJS Tour?
- » Cutting-Edge Technologies
- » Agile Practices
- » Peer Exchange
Current Topics:
- Languages on the JVM: Scala, Groovy, Clojure
- Enterprise Java
- Core Java, Java 7
- Agility
- Testing: Geb, Spock, Easyb
- REST
- NoSQL: MongoDB, Cassandra
- Hadoop
- Spring 3
- Automation Tools: Git, Hudson, Sonar
- HTML5, Ajax, jQuery, Usability
- Mobile Applications - iPhone and Android
- More...
NFJS, the Magazine
May Issue Now AvailableClient-Side MVC with Spine.js, Part 1
by Craig WallsOn Prototypal Inheritance, Part 2
by Raju GandhiMaking use of Scala Lazy Collections
by Venkat SubramaniamIntegration Testing Web Applications Using Gradle
by Kenneth Kousen


