What the JVM needs | Hacker News Reader

What the JVM needs

wiki.jvmlangsummit.com

21 pointsfogus14 comments

I tried at the conference to get people to agree that hotswap (i.e. reloading classes in a running system) was something that the JVM needed to add, so that the 99.9% of JVM users programming in Java can have a more dynamic programming experience. It really matters when it's there (especially for people that develop server software, which is a large part of the Java community), and there's a real, ingenious solution already implemented as part of the MLVM project that works well enough for me to use in development all-day every day.

When I brought it up during this discussion, I got nowhere, and people basically looked at me like I was an idiot. It was pretty disappointing to see that a room full of language guys just didn't care about anything that would improve Java itself; the discussion pretty much entirely focused around small-scale stuff that would make it easier to efficiently implement dynamic languages on the JVM.

Dynamically reloading classes is a nightmare in production systems. I'm not a .NET guy by any means, but one thing that it has that others could use it code signing. This is precisely the opposite of dynamic reloading and it's much more valuable.

The win-win is leveraging the power of a dynamic language at development time and the power of something like the JVM at production time.

Yeah, I agree that it's a nightmare in production, but it's absolutely indispensable in development situations where you can tolerate the occasional weirdness or failure. If you're developing a server app (or a thick-client app), avoiding a sever restart every time you change anything is a huge, huge win. And again, it's not like it's not implementable: there's already an implementation, for the JVM, that works.

That's true. It would be helpful to have dynamic reloading as an option with the JVM.

Full hotswap capability (which is available as a patch, today, due to the work of a true genius Thomas Würthinger and his team) should be the first entry, the second entry, every entry all the way down to the end. All the rest should be footnote nice-to-haves.

The JVM Language conference once again demonstrated how out of touch with day-to-day JVM development it is. The focus was nearly entirely on how to make dynamic languages fast (method handles, apparently) and how to deal with concurrency (functional programming, of course.) The first problem affects _maybe_ 1% of the JVM's users. The second problem isn't nearly the crisis it is made out to be (server side software keeps the CPUs full and, when it doesn't, there are plenty of fork-join-like libraries out there.)

Meanwhile, poor assholes doing java web app development are breaking concentration to bounce their server every time they change a method signature.

Unbelievable.

Cheers, Carson

... a custodian who actually cares to improve it, along with the insight and ability to say "no" to enough features that it has sharp unified direction and doesn't become a typical example of open source feature creep.

Unfortunately, I have a hard time seeing any reason to believe that this resembles Oracle, and any such beliefs seem to be indistinguishable from wishful thinking.

a custodian who actually cares to improve it, along with the insight and ability to say "no" to enough features that it has sharp unified direction and doesn't become a typical example of open source feature creep.

Sun, in its ownership of Java, has always had the second part down pat - they've flat out rejected many of these features in the past, as well as many other popular requests for improvements both in the VM and in Java the language.

It's the first part, the "cares to improve it" bit, where they really fell down. Honestly, I think we could do with a little bit of "open source feature creep" to make up for the stagnation over the past several years...

I've also gotten the sense that most of the "no"s were borne of lack of resources to devote to these things rather than a desire to avoid feature creep, though, and I don't know if Oracle is in any better position to devote developers to any of this stuff...

I program in Java every day and I see nothing in that list that I really cannot do without.

Structs / value types? Nice to have but you can make do with java.nio.ByteBuffer.

Concurrent PermGen sweeping? I work on a big enterprise project like the article mentions but this has never been an issue in production, only development and then only when reloading lots and lots of classes.

Unsigned equality checks would be nice but you can work around that, too.

These features would be most necessary for JVM languages other than Java: Scala, Clojure, etc.

Since you're not a language implementer what you can do without is irrelevant here.

Okay, then let me tell you what I /can't/ do without. To name a few:

  hot-swappable classes
  design by contract
  re-ified  generics
  closures

These are all things that have been on developer wishlists for years. Design by contract is the #1 upvoted RFE in SUN's issue tracker, the others are all in the top 20.

But what happens? The guys that can make a difference come together and wank about performance hacks for dynamic languages. The 2% of the user base that actually uses Scala and Clojure will thank you for it, but the other 98% is left out in the cold.

Closures and TCO, please.

I assume that you mean for the Java language, not the JVM? There are already languages that run on the JVM that have closures.

Both closures and TCO are things that you can implement in compiler, but would greatly benefit from direct support in VM.

Reply on news.ycombinator.com