Farewell to the 'J' in 'JVM'?
Farewell to the 'J' in 'JVM'?
Join the DZone community and get the full member experience.Join For Free
FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.
CMS Watch discusses Sun Microsystems CEO Jonathan Schwartz, speaking at the SugarCRM Customer and Developer Conference earlier this month, stating: "I think what you'll see from Sun," Schwartz remarked, "is that we're just going to take the 'J' off the 'JVM' and just make it a 'VM'." What does that mean? Here several of the DZone leaders share their views, from their various backgrounds, which range across a variety of programming interests and specializations.
A public statement of this development certainly seems like a landmark moment. Let's not let it go by unanalyzed, though. Does a deemphasizing of Java indicate that less resources will be spent there or simply that more will be spent in other places? Weiqo Gao's blog posits mixed emotions, which many are likely to feel: "I'm not sure how to react to this quote as a Java developer." He turns the discussion on its head by not simply seeing many different uses of the Java platform, but many different uses of Java itself, such as Android: "I think as main stream scripting languages crowd into the JVM, Java the language needs to do the opposite—spreading out to other runtimes."
DZone leaders were asked for their thoughts, and here are some of them, indicating a pretty enthusiastic response to the general direction:
Alex Miller. I'm primarily a Java guy, but I'd love to see an explosion of well-supported, high-performance language implementations on the JVM. Some of the most interesting work I've seen for Java 7 (closures aside) is coming from John Rose in the context of JSR 292. This JSR was originally intended to explore a new JVM instruction "invokedynamic" that would allow the invocation of a method without knowing the type of the receiver. However, as JRuby and other languages have pushed the envelope, JSR 292 has also started to look at tail recursion optimization, tuple support, anonymous methods, and all sorts of interesting enhancements to the JVM. I find these developments exciting for two reasons: 1) I'd love to have my pick of awesome languages on the JVM and be able to have them work together and 2) JVM enhancements open the door to Java features and performance improvements down the line.
Dan Wilson. As a ColdFusion programmer, I'm no stranger to this idea. ColdFusion is a dynamic, loosely typed language and a Rapid Development Framework for constructing Web Applications that has been running on top of the JVM for 6 years. . With this rich Java heritage, we gain a variety of functionality such as Apache Axis, Web Charts 3D, EAR and WAR deployment of ColdFusion applications and JDBC. If ColdFusion were not written on top of Java, ColdFusion product engineers would have to redirect effort toward infrastructure, taking away from building relevant functionality.
Rick Ross. It isn't so much a "farewell to the J" as an expansion of the platform opportunities Java provides. Sun's investment to power ongoing development of JRuby and Jython broadens the range and reach of Java, as a whole. Community support for emerging languages like Groovy and Scala goes further, still - driving the very evolution of programming languages on a Java foundation. These efforts demonstrate the adaptive versatility of the underlying JVM more clearly than ever. Best of all, this expansion creates new opportunities for Java developers to get more mileage out of their Java platform experience. Rather than fading into obscurity, Java now appears likely to become the very DNA of next generation computing, and the time developers have invested in mastering the Java platform will continue to yield new and unexpected dividends.
Graeme Rocher. The disappearance of Java is much hyped and makes for catchy headlines, but is greatly exaggerated. Java is and continues to be hugely popular. What is happening however, is the emergence of languages like Groovy which are better suited for tasks which are often cumbersome in Java. Of course, programming in multiple languages has its cost, the more languages you need to know, the harder it becomes as you have to deal with dramatic context switching between language implementations. Not all developers are rock stars and, in my view, if we are going to transition to an era of polyglot programming, where on a day to day basis you use multiple languages to achieve different tasks, those languages must interoperate seamlessly at every level from the syntax to the APIs. This is why I got involved with Groovy and believe that it provides an evolutionary (as oppose to revolutionary) step on the dynamic language ladder.
Tim Yates. As primarily a Java developer, I'm really excited by these times of expansion, Java is truly becoming the platform rather than the language. To coin a phrase, it is less like we are losing a son, but are gaining a daughter (or daughters). The power of being able to pick the tool that is truly best for the job, and yet be able to seamlessly incorporate it into our existing applications to me, ensures the future of Java as the platform of choice. And having the multitude of existing Java frameworks and libraries available to these other languages is surely a win-win situation for all.
James Sugrue. In the last year or so, Java has become a lot more sophisticated - the virtual machine is starting to live up to its promises and provide us with a platform to add the type of languages that we've wanted. This can't be a bad thing and diversity will continue as others build their own platforms on top of the VM, Eclipse being an example of this.
Jim Bethancourt. I am curious how the Java User Groups (JUGs) will take shape with the changes in the Java landscape in the coming years. It is good to see Groovy User Groups starting up, though it would be very helpful to see suggestions on the best ways JUGs can serve the Java community and incorporate more material about other VM languages. It would be great to see Sun step forward and publish a CIO / CTO level press release document describing the new languages that are starting to take shape on the Java platform. This could pave the way for the quicker adoption of different JVM languages and let CIOs / CTOs know that their previous investments in the Java platform will not be threatened, but made more valuable, and that developers will be more productive as a result as well. It will also be interesting to see the continued growth of the forms of the JVM and the places where we find it running: The JVM is now being made available in massive compute capacities, via Azul Compute Appliances (which have multiple 48-core Java instruction processors), and continues its growth as a regular (non-J2ME) VM on small devices, such as Google's Android VM. We are also starting to see the growth of pure Java compute environments, such as BEA's Liquid VM, and even pure, viable Java OSes such as JNode and the JX Operating System (though I can't speak to how usable or performant they are). On top of that, Sun, BEA, and others continue to work on real-time Java, and pure Java device drivers can even be implemented with Sun's RT JVM implementation.
Boyan Kostadinov. From a .NET perspective, removing the Java restrictions from the JVM, and therefore making a generic VM, makes a lot of sense. Microsoft has already done so with .NET by allowing any language to run on the platform by simply providing methods to use and compile other languages on top of the CLR. What .NET lacks in terms of a general VM is a standard VM that works on all platforms. I realize that there is Mono but that is not as widespread or supported as the .NET framework under Windows. Back to the Java discussion, limiting the VM to just Java or any other language is much like shooting yourself in the foot. Maybe not right away but eventually. Computer languages appear and evolve all the time and it is silly to think that one will always persist. Providing a way to host other languages inside a generic VM is the way of the future. As a plus, you can forget the "my language is better than yours" argument and let each individual decide what to use.
Now over to you... what's your take? The VM without Java... an inevitable development with the rise of scripting languages? A logical next step in the crumbling of Java's special place as a language? Are you cheering or do you have reservations?
Opinions expressed by DZone contributors are their own.