Open-source Java Virtual Interface API makes Java apps Cloud-friendly
Open-source Java Virtual Interface API makes Java apps Cloud-friendly
Join the DZone community and get the full member experience.Join For Free
The CMS developers love. Open Source, API-first and Enterprise-grade. Try BloomReach CMS for free.
The JVI API allows developers to bring multitenancy to existing Java applications and frameworks, making Java applications friendlier to Cloud platforms. It will be released through the end of the month as an open source API.
Following is a transcript of our interview, with interesting bits in bold.
DZ: Tell me a little bit about the Waratek Java Virtualization Interface.
|John Matthew Holt|
So a simple example is: When you talk to Java developers and Java administrators who are consolidating a lot of Java applications, they have a recurring feature request between the two. They say, “Wouldn’t it be great if we could change the way the Java applications interact with the FileSystem?” One very pragmatic and simple example of that is a complaint that I have heard too often from large organizations, large IT users, where they have found that their developers have developed a Java application many years ago and they originally developed that application on Windows desktops or on Windows servers, and so unbeknownst to the people at the time, they took shortcuts where they hardcoded C:\ in the FileSystem path of the file access operations for that Java application. It’s paradoxical because Java is meant to be a platform and a language for running applications on a range of operating systems, but the moment that you get a developer who does something silly like that—hardcodes C:\ or hardcodes / if he’s on a Linux environment, then he’s constraining the kind of operating system infrastructures that he can host the application on. And there’s really no convenient or quick way to solve that problem of trying to relocate that application without going back into the code of the application or without making changes to the application. But the JVI, the Java Virtualization Interface, allows you to tell the hypervisor and the JIT in the JVM, “Hey, listen, we want you to change the way this application is functioning but we want to do it without any code change to the application or the Java platform.” And so in the case of virtualizing the Java platform, changing the accesses of this hypothetical Windows-locked application, using JVI it’s as simple as writing one, pure Java class and you make it implement an interface called FileSystemEnvironment which defines a number of functions, and that’s the entire virtualized interface for a FileSystem of a JVC. By writing this one Java class they can implement FileSystemEnvironment and you can then provide in like 300 lines of code a little translation logic where you can translate C:\ to a Linux / and vice versa, and you can do this deep down in the bowels of the JVM in pure Java code without any code change to the application. Then when you fire up that application and you run it inside the JVC, you just tell the JVM to load your file FileSystemEnvironment rather than the default FileSystemEnvironment and voila! Suddenly you have virtualized FileAccess for that Java application and you’re abstracting that FileSystem.
DZ: Could you give a specific example of a way that an individual developer could use the JVI to tailor the JVM to their needs?
JMH: Recently we hosted a customer at our Dublin Offices to start to use the JVI as part of our Early Access Program. Our customer has a long established software platform that is difficult to maintain when it comes to bespoke client requirements and features. In particular they are crafting a cloud based service offering for their platform, which poses a real challenge because their customers need to write plugins in order to use their platform. This plugin tailors the environment of this big application server environment. (It’s like writing a WebApp.) So you write this plugin for this company’s application server environment and you can tailor the way their engine works. When they looked to host that in a cloud environment, though, that becomes really inefficient and not economical for a very simple reason: because Java isn’t multitenant, they can’t safely collocate class files from different customers in one JVM. Because, as we all know, if you collocate class files from different developers in one JVM, there’s nothing to stop one of those class files from chewing up all the memory. There’s no such thing in TomCat, for instance, where “Servlet #7 is only allowed to use 38 MB of memory but Servlet #8 can use 100 MB of memory.” There’s no such control. So as a result of not having multi-tenancy in standard Java, for them to host a cloud offering they have no choice but to give each customer their own JVM and their own unique instance of this particular engine. Which means that they start looking at a memory-footprint-per-user of a gigabyte or more by the time they allocate the JVM, set up the memory for the full app server stack, the app server stack takes forever to load, then they load in what might actually be a very small portion of the user’s code—it might only be 10-30 class files for the user but there are 10’s of thousands of class files for the app’s server engine that wraps around it.
What they got very excited by was that JVI for the very first time allowed them to do was, by using the JVI API in the Waratek JVM, and without any code change to the application server platform, in three days they were able to turn around and write a small driver using the JVI API, tell the JVM hypervisor how to virtualize these little foreign third-party plugins that this platform loads so that every time their platform goes to load one of these customer application plugins, without the platform itself knowing—without their application server engine knowing, and without the customer or their application plugin knowing—the Waratek JVM runs all of those in separate JVCs. It does this completely transparently. So then without any code change what they achieve is that they can say, “I can now boot up a single instance of our application server engine, I can load 100 different users’ plugins onto that engine, but each user’s plugin will run in its own JVC. And then I can manage, control, meter, and provision each user completely independently even though they’re actually sharing one host service underneath." For this particular customer use case, why it’s so exciting is that the amount of memory taken for each customer’s application that they load onto this application server engine is very small. It’s on average 1-5 MB. Every customers gets 10-15 MB of memory so suddenly in one or two GB they find that they can run 100 customers where before in the same one to two GB they could only run one.
DZ: I understand this is Waratek’s first open-source project. Can you tell me why you chose open source and how you hope to engage your community?
"Here we are now in 2013. We’re not in 1993 when Microsoft ruled the world and the world was closed-source. The world is open source."
But as we look further on the horizon we see that the Java community is much more than just the systems administrators trying to run Java apps on a daily basis, it really is defined by the developer community. They really lead the way in showing what Java or what any application platform and programming language is capable of. So, by opening up the virtualization system and the JVM and making it accessible to developers, we bring this power to them and to their software and applications.
Here we are now in 2013. We’re not in 1993 when Microsoft ruled the world and the world was closed-source. The world is open source. Today we think of all the common application platforms: Apache TomCat, Red Hat JBoss, Linux itself—all these fundamental technologies are open source. And so to aide the adoption of JVI, and to provide a reference of implementation and an exciting new product in its own right, we have gone ahead and developed a virtualization driver for Apache TomCat and packaged that up as a new build of TomCat. We call that ElastiCat. So there’s ElastiCat and the virtualization driver that virtualizes TomCat we developed using the JVI API. Anyone could have written the same thing, and we are releasing that as open source—both the virtualization driver and the API and it will be for the open source community to use that API to build their own tailored and customized virtualization extensions and enhancements.
DZ: When and where will ElastiCat be available?
DZ: How can developers get their hands on the API?
Opinions expressed by DZone contributors are their own.