
What the JVM needs - fogus
http://wiki.jvmlangsummit.com/What_the_JVM_needs
======
akeefer
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.

~~~
delano
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.

~~~
akeefer
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.

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

------
carsongross
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

------
WilliamLP
... 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.

~~~
ewjordan
_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...

------
bnoordhuis
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.

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

~~~
bnoordhuis
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.

------
devin
Closures and TCO, please.

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

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

