Geertjan is a DZone Zone Leader and has posted 457 posts at DZone. You can read more from them at their website. View Full User Profile

Farewell to the 'J' in 'JVM'?

03.05.2008
| 20751 views |
  • submit to reddit
Duke

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:

AlexAlex 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 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 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 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 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 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?

Published at DZone with permission of its author, Geertjan Wielenga.

Comments

Joseph Ottinger replied on Wed, 2008/03/05 - 11:30am

I think it's great to see people admitting the obvious. De-emphasizing "J" in JVM is more a recognition that Java is a brand and not just a simple technology any more.

Lots of handwringing, IMO.  The JVM has been ascending for a few years now, and that's ONLY good for Java - as a brand and as a language.

Mark Haniford replied on Wed, 2008/03/05 - 12:36pm

How times have changed.

 Two, three years ago it was almost sacrilege on Javalobby to advocate the de-emphasis of the Java language, and the emphasis of Java the platform.

 It's really nice to see .NET/CLR driving development in the Java community and vice-versa.

Meera Subbarao replied on Wed, 2008/03/05 - 3:55pm

"Write once, run anywhere" (WORA), was a slogan created by Sun Microsystems right? Now they would have to create a new one which says "Write anything, run on one VM".

John Denver replied on Wed, 2008/03/05 - 7:51pm

This is not for repleace Java with language X. Scripting languages are glue languages so the idea to run scripting languages on top of the JVM is to combine Java with scripting language X to develop parts of a system or program that it makes sense to use scripting languages, for the other things or performance Java is and will be the way to go.

 It's like the 90's all history repeat again, C/C++ was the low level language, Visual Basic the scripting language. In this times Java is the C/C++ and scripting languages are the Visual Basic. 

Ashley Aitken replied on Wed, 2008/03/05 - 8:36pm

It's unfortunate that the Java Platform shares the same name with the Java Programming Language.  Apart from the confusion it causes for new comers, it makes branding difficult.

Is Sun going to remove the JAVA from their stock market ticker?  How can you remove the Java from the VM without some folks thinking that is deprecating (at least in some way) Java.

Microsoft have things a lot clearer with the .Net platform and various languages (as you all know).

Finally, to really be a clean multi-language VM does Java (the platform) need a common type system (which I hear is one of the big strengths of the .NET CLR), or does it already have one?

Cheers,

Ashley.

  

Mark Haniford replied on Thu, 2008/03/06 - 12:58am in response to: John Denver

This is not for repleace Java with language X. Scripting languages are glue languages so the idea to run scripting languages on top of the JVM is to combine Java with scripting language X to develop parts of a system or program that it makes sense to use scripting languages, for the other things or performance Java is and will be the way to go.

If you're making the comparison of Groovy or JRuby to what Perl/Bash has been used for in many situations then I'm not buying it.

It's like the 90's all history repeat again, C/C++ was the low level language, Visual Basic the scripting language. In this times Java is the C/C++ and scripting languages are the Visual Basic.

Fine, but there's no reason we can't have a another statically-typed (type inferenced at least), "low-level" language that isn't Java. I think Scala's syntax will always be a bit too weird for too many programmers.

I've said it once, and I'll say it again. The JVM needs something like Boo on the JVM.

Jeroen Wenting replied on Thu, 2008/03/06 - 1:37am

Sseing as to how Sun is ever more jumping onto the "Java is dead" bandwagon these days it's hardly surprising that they want to deemphasise the name in the marketing of the JVM.

I think quite a few people at Sun are kicking each other by now over last year's decision to change their stock ticker from SUNW to JAVA, it no longer fits the marketing plan.

Geertjan Wielenga replied on Thu, 2008/03/06 - 2:26am

Jeroen, you'll not find anyone saying Java is dead, certainly not Sun. :-) And have a look at all the comments above from the various DZone leaders. Is there one there saying anything similar to 'Java is dead'? That's the whole point of this article -- it shows that Java is very much alive, but that all the traffic on the VM is causing a logical rethink about what the VM is all about.

Thomas Mäder replied on Thu, 2008/03/06 - 4:47am

Are they going to call it the KVM now (for kitchensink)? No, but seriously, the JVM is very much geared toward languages like Java and I doubt that this is going to change, considering Suns position on backwards compatibility

Jeroen Wenting replied on Thu, 2008/03/06 - 7:53am

Geertjan, read the mood in the blogs by Sun people at java.net, which I have to assume reflect the attitude of Sun itself (or they'd put a stop to it).
Combine that with the way the JCP is handled, the effective dumping of the language stewardship onto the OSS community, and other things going on over the last year or so and I can only conclude that Sun themselves are loosing interest in the language and are working to let it die out.

Geertjan Wielenga replied on Thu, 2008/03/06 - 7:58am

Jeroen, read the pattern in which the leaves fall from the trees, the shape of the clouds at midday, and the dewdrops in the morning, which I have to assume are there for a reason, and I can only conclude that etc. etc. etc.

You are drawing so many baseless conclusions, that I don't know where to begin to help you. :-)

PS: The fact that you think Sun would actually put a stop to a blog, any blog, shows how far off base you are. 

Osvaldo Doederlein replied on Thu, 2008/03/06 - 8:55am

@Meera: Actually, the WORA standard is now being extended to other languages. Even though most "alternative" languages like Python, Ruby, PHP and others are multiplatform, they're often deficient in important aspects of multiplatformness... like having a decent cross-platform GUI toolkit (Tcl doesn't count), or high-quality Windows ports (many alternative languages are quite Linux/Unix-centric, e.g. PHP apparently sucks on Windows so there's a market for products like Zend's). Not to mention having a very rich set of libraries and frameworks that don't rely on native code and as a rule, behaves the same (bugs and all) on all platforms. Of course, in order to fully benefit from the Java platform, other languages must either adopt Java's libraries (which sucks - except for languages specifically designed for the JVM, like Groovy and Scala), or have their own standard libs reimplemented in the Java platform. That is, either in the Java language or self-hosted, e.g. Ruby libs implemented in Ruby and so on. Because most languages discussed here (remarkably the dynamically typed) are dog slow, there's some considerable effort in rewriting lots of libs currently implemented in C. But this rewrite is usually necessary for other reasons, anyway... Java's JNI is heavier than the native interfaces of other VM langs, so a straight port of languages with gobs of native libs will probably perform poorly, and that native code may also be broken for the JVM in many areas, e.g. handling of multithreading.

 @Jeroen: I don't think the JAVA ticker is a problem... marketing-wise, it raltes to the Java runtime that millions of users see every day when they start Java-platform apps in their browsers or cellphones. The ticker stuff was certainly not a move to attrach the much smaller number of software developers who know and worry about languages.

@Ashley: Microsoft certainly had this idea of language-neutral VM before. Personally, I've always been critic of their implementation, not their idea. The CLR is not as open as they want you to believe; the first batch of CLR languaes were all C#-like like VB.NET, or significantly contaminated/compromised like early Eiffel and Smalltalk for .NET. Fact is, the CLR is as bad as the JVM in that it's highly optimized for statically-typed languages with vtable-based dispatch, single implementation inheritance, non-unified typesystem (primitives vs. reference types- you can't implement tricks like Smalltalk's 'tagged memory'), stack-based activation (no fancy stuff like continuations), a specific memory model and GC, a specific JIT model, etc. etc. Now they have the DLR, but at the same time we discover that a big part of the DLR is just giving to the CLR the dynamic optimization capability that HotSpot's had for ages, allowing self-updating dynamic call sites. We're also finding that the JVM can become much more language-friendly with a few relatively simple tweaks, no need of a big plan like .NET's CLI... it's perhaps a lesson on the old debate of extensive up-front design versus evolutive designs driven by real-world experience. The .NET platform had all that common language stuff baked since v1.0, yet it also needed massive updates (DLR) when the first really non-C#-clone languages emerged to the mainstream.

@Mark: Yes, Scala is more difficult than Java. It's a richer, bigger language - even though IMHO the feature/size ratio is much better than Java. But C++ was also much more complex than C - even when C++ appeared and was not yet a Titanic of programing languages - and yet, it took over C for application development. So, don't count Scala out just because of its learning curve. Of course, complex languages tend to separate programmers between "framework writers" and "application writers"; 90% of C++ programmers couldn't write the STL or the MFC classes if their lives depended on that, and I don't think most Scala programmers will be good enough to create advanced libs like Actors of Lift. But this may be a Good Thing. The Java ecosystem is too much polluted by redundant frameworks for everything, each one giving a tiny contribution compared to the others, and often with a less than brilliant implementation. When I pick some infrastructure that my apps will depend on heavily, like an ORM tool or some middleware, I really hope that it was implemented by top-1% elite developers, not by run-of-the-mill hackers that just had some nice idea and motivation to work hard.

Matt Raible replied on Thu, 2008/03/06 - 10:19am

I believe the biggest obstacle for developers today is increasing our productivity. While the best way to do this is to convince us to stop reading e-mail and reading blogs, it's unlikely we're going to do this. The 2nd best alternative is to give us "zero-turnaround" when developing applications - particularly web applications. Developers typically have short attention spans because we're sitting at a terminal, with access to the world's information at our fingertips. If you make us wait for longer than 15 seconds (e.g. to run "ant deploy"), the chances of us watching the terminal run to completion are somewhere between slim and none.

By allowing dynamic languages on the VM, and web frameworks that have zero turnaround, it's highly likely that you'll see more productive (and happier) developers in the future. This isn't a bad thing for Java Developers. If you know your way around Java Web Applications, you probably already know a lot about tuning your JAVA_OPTS and configuring your server for optimal production performance. This knowledge doesn't go away. Neither does your knowledge of the Java programming language. Now you'll just have more choices in languages to develop with, and you won't to worry about the "production deployment" so much.

I'm certain that Operations Departments at many companies will be pleased with Sun's direction for the JVM. A lot of times, Ops is happy if you give them a WAR. They aren't happy if you tell them they need to install a new runtime. Of course, the hard part now is deciding between Django, Rails, Grails and GWT for your web framework. Then again, that's like having to choose between a Ferrari, Porsche, Lamborghini and a Maserati. No matter which one you choose, it's unlikely you'll be disappointed.

Harimohan Bawa replied on Thu, 2008/03/06 - 12:01pm

 

Theory ... Well we build a compiler to compile C# to Java Byte Code and we get the C# compatibility with existing JVM. Now how do we handle microsoft's platform specific support? Is this do-able? This way CLR will not be needed. I believe C# is the most popular language in .NET collection today. Question is .... Can we make this happen?  Can we do this for C++? There is a big pool of developers out there with knowledge of Java and C++.

We have Ruby, Jython and many more languages. How many languages a developer need to learn? How can we confirm the production level usability of these languages? What are the pros and cons compared to existing popular languages? There are tons of questions.

We are  coming up with tons of languages. The key question is, can we enhance the existing popular ones? What would it take?

This question is for language Pros. 

Cheers :-) I am still very happy with Java. (COBOL->C->C++->Java->????)

Hari 

 

Osvaldo Doederlein replied on Thu, 2008/03/06 - 12:57pm

@Harimonah: Support for unmanaged languages like C/C++ is not viable. One think I can state for sure about the future of the JVM is that it won't ever allow unsafe operations (raw memory access, pointer arithmetics) from bytecode. Even C# allows this in its unsafe blocks, so at least this aspect of C# cannot be ported to Java. Twelve years later, I still believe that this is a good tradeoff. The Java platform owes much of its success to its no-compromise approach to security and safety.

On the "production level usability", look for support of large vendors. Sun is now 'supporting' Ruby and Python, as they hired the main developers of the JRuby and Jython projects. Sun's Glassfish project is also supporting JRuby (with Rails) out of the box. NetBeans 6.1 will have support for PHP, so that's potentially a third alternative. IBM seems to back Groovy with their Project Zero, although this one is still early stuff (I'll believe it when I see this integrated to Websphere Application Server). Microsoft has IronPython, F# and others, although I don't track these very closely.

Artur Biesiadowski replied on Thu, 2008/03/06 - 5:21pm in response to: Osvaldo Doederlein

[quote=opinali]

Support for unmanaged languages like C/C++ is not viable. One think I can state for sure about the future of the JVM is that it won't ever allow unsafe operations (raw memory access, pointer arithmetics) from bytecode. Even C# allows this in its unsafe blocks, so at least this aspect of C# cannot be ported to Java.

[/quote]

I think you can get pretty close with sun.misc.Unsafe class. It is well understood by hotspot, so most calls to Unsafe are actually converted into single target cpu opcodes and fast as hell. Interpreter speed can be less stellar, but there could be as well an option of forcing compilation of every method marked as 'unsafe'.

So, support is very well inside jvm platform now (Sun jvm, that is).

I find it funny when some people write alarmist blog entries about 'unsafety' of reflections with setAccessible(true) (omg, you can change value of final !), at the same time forgetting about sun.misc.Unsafe allowing them unbound memory access (modify class of the object on the fly anyone?).

James Imber replied on Fri, 2008/03/07 - 5:43am

I'm a Java developer and I don't plan to use another language anytime soon. That said, I think it is great that other people will be able to use the (J)VM to run the apps written in other languages. That many more people use the (J)VM is a guarantee for a bright future for the decades to come. Let's see if we can get there.

Osvaldo Doederlein replied on Fri, 2008/03/07 - 7:21am

@Artur: What you say about Unsafe is true, but untrusted classes can't reach it. It may be possible to use Unsafe to convert C# programs, which unsafe code is well encapsulated and small. But for languages C/C++, code is all unsafe and not encapsulated - the program may create a pointer to some heap object now, and two hours later attempt to deref this pointer so the object must be kept in the same virtual address... so in addition to using Unsafe, you can't let GC move objects, ever - no gen-GC, no compaction or semispaces, only simple mark&sweep with free lists. There may be other restrictions to support of unmanaged languages, I don't think Unsafe is powerful enough to solve all issues. And let's not forget that Unsafe is also an Unstable and Unstandard API, new versions of the JDK can have incompatible changes, JDKs from different versions may not have the Unsafe class at all (although in practice they usually do)... that would spoil even further any attempt of supporting unmanaged languages.

Gabriel Mazetto replied on Mon, 2008/03/17 - 1:38pm

Why Not changing J from JVM to another one like UVM (Universal Virtual Machine) or something like...

it makes a lot more sense then just removing it.

 

PJ Murray replied on Tue, 2008/04/08 - 9:46am

This would have been huge 5 years ago - just like Sun open sourcing its IP would have been huge 5 years ago.

 But now?  It looks like Sun is copying Microsoft's CLR.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.