JVM restarts/availability JSRs

Posted by: Brian Pontarelli on 08/13/2007

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

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...
Learn More »

NFJS, the Magazine

May Issue Now Available
  • Client-Side MVC with Spine.js, Part 1

    by Craig Walls
  • On Prototypal Inheritance, Part 2

    by Raju Gandhi
  • Making use of Scala Lazy Collections

    by Venkat Subramaniam
  • Integration Testing Web Applications Using Gradle

    by Kenneth Kousen
Learn More »