Posted by John R. Rymer on June 21, 2010
Java's future is on my mind lately. Oracle's new ownership of Java prompts a series of "what will Larry do" questions. But more to the point, the research Mike Gualtieri and I have been doing on massively scaled systems makes me worry that Java technology has fallen behind the times.
This is not a "Java is dead" commentary but rather a discussion of issues as I see them. Java technology is alive and vitally important; we all must be concerned if its future direction isn't clear.
For me, Java's 2-gigabyte-per-JVM memory limitation symbolizes this gap. Volumes of application data are rising, but standard Java platforms still have a practical limitation of 2 GB of memory. I spoke with one customer that incorporates a search process into its app that alone requires 20 GB of memory. This customer employs servers with 6 GB of memory each but can only use this memory in 2 GB chunks, each chunk managed by a JVM in a scale-out architecture.
We've done pretty well with 2 GB JVMs until now. But as data volumes grow, this company (and others) are no longer well served by scale-out JVM architectures. Java technology should give shops the choice of scaling up the memory within an individual JVM as well. Why?
- Scale-out approaches require changes to code to incorporate either elastic caching platforms or not-only SQL (NoSQL) databases.
- Scale-out approaches impose a certain amount of configuration complexity and management overhead.
The company with the 2o GB search process would love to have the option of large memory pools within a single JVM, primarily to get scale without code changes. Gap: There is no memory scale-up option in standard Java today. I'm not sure how many shops would select a scale-up approach over a scale-out approach (would love to know what you think). But I've seen enough requirements to be persuaded that having the additional choice is important.
This is the problem: The Java community should have an answer for this requirement, but it does not. The recently announced Managed Runtime Initiative, backed by Azul Systems, seeks to drive a scale-up JVM solution (based on a new JVM combining OpenJDK and Azul's software) at a future date. None of the Java leadership has yet signed on to that initiative. We can only hope that: a) MRI comes up with a standards-aligned scale-up JDK and/or b) MRI inspires the Java community leadership to solve this problem.
Here is what worries me about Java's future:
- Requirements for a scale-up JVM exist now.
- Creating a scale-up JVM will take tons of work. The solution must address not only the structure of JVMs but also their interactions with operating systems.
- Neither Oracle nor IBM -- the leaders of the Java community -- have strong incentives to solve this issue. A massive engineering investment to remake the JVM only to give it away in specs and a reference implementation? I don't think this will happen.
- It isn't clear who's got the job of solving issues like the 2 GB JVM, aside from the amorphous Java Community Process. Oracle generally embraces strong, direct initiatives but hasn't yet done so with Java's technical direction.
And so the status quo in JVM memory persists, and developers work around that limitation. Makes me worry about the future of Java technology. You? I've added a discussion thread in our Application Development & Delivery Community Site (http://community.forrester.com/thread/2918) for your thoughts.
- Anjali Yakkundi (27)
- Art Schoeller (1)
- Boris Evelson (144)
- Claire Schooley (2)
- Clay Richardson (1)
- Diego Lo Giudice (17)
- Gene Cao (1)
- George Lawrie (17)
- Holger Kisker (38)
- Ian Jacobs (4)
- Jeffrey Hammond (27)
- John R. Rymer (45)
- Jost Hoppermann (33)
- Kate Leggett (125)
- Kurt Bittner (4)
- Kyle McNabb (12)
- Margo Visitacion (9)
- Mark Grannan (9)
- Martha Bennett (13)
- Michael Barnes (21)
- Michael Facemire (14)
- Mike Gualtieri (115)
- Noel Yuhanna (10)
- Paul Hamerman (2)
- Phil Murphy (24)
- Philipp Karcher (1)
- Randy Heffner (15)
- Rowan Curran (1)
- Stephen Powers (23)
- Ted Schadler (6)