[mey]

As a web application developer, on Java, I think there is a lot to look forward too.

Mostly in JSR 292.

I see a point where I'm running the best of ruby/python/groovy as core parts of a Java deployment environment.

Edit: Not that you can't now, but now this will bring very good reasons to run a hybrid environment combining the best of both systems.

[bad_user]

Unfortunately JSR 292 will not deliver as you'd thing.

Some people don't have such a good impression of it, e.g. Rich Hickey (Clojure): http://clojure-log.n01se.net/date/2010-06-01.html

     method handles are just going to be an entirely new thing hotspot et al 
     are going to have to be taught to optimize. They are already awesome at 
     optimizing ordinary class method dispatch
     bobo_: invokedynamic is not needed for removing reflection
     ....
     it is just a different way of doing call site caches, which you can already 
     do today with classes and methods

What JSR 292 does is to simplify the work a compiler architect needs to do, since implementing call-site caches is hard work, not to mention memory management since interpreters like JRuby are generating lots of classes that are entering PermGen ... so stuff like java.dyn.AnonymousClassLoader may provide some relief.

But on the other hand, compilers will still need to support Java pre-7, since adoption in the enterprise is really slow (many companies are still on version 1.4)

There is a backport for invokedynamic though, but it remains to be seen if it's any good: http://code.google.com/p/jvm-language-runtime/

Notably missing features with a lot more bang than InvokeDynamic:

      tail-call optimization
      fixnums
      coroutines

All in all, Java 7 is a monumental failure and Oracle is waisting resources on merging JRockit with Sun's JVM, instead of saving it.

Say what you want about .NET, but their releases have been coherent with each one adding value. If only Microsoft's management would see this as an opportunity and open up .NET a bit, probably not.

[mey]

Everyone could implement their own solution to call-site caching (and they do), but to push it down into the JVM for a single clear defined way of doing it, grants much more to optimization efforts. What benefits one system, should benefit them all.

There will be a schism between libraries that move to Java 7 only, and support their own call-cache mechanism, but I doubt any of the established projects would ditch their existing solutions, it would most likely only effect new libraries.

If an enterprise is busy being tied up in Java 1.4, and missing out on the drastic speed and memory improvements in hotspot 1.6 line, then I doubt that adding dynamic languages is a priority. JRuby for example requires 1.6 (from the literature I've seen and personal experience, but they don't explicitly say so on their site)

I also disagree generally about how Oracle is dealing with Java 7, but I am willing to see what the end result is.

Microsoft has been heavily involved in the IronPython/IronRuby and Mono efforts. They do see the power in .Net cross system.

[bad_user]

> Microsoft has been heavily involved in the IronPython/IronRuby and Mono efforts. They do see the power in .Net cross system.

Mono is kind of behind ... I have high hopes for version 2.8/3.0 with the new garbage-collector, but the prelease crashed with a segfault which kind of turned me off for now, I'll retry it when the final version is released.

What bothers me about it is that currently memory-management sucks, some bugs remain unfixed (tail calls don't work properly, hence F# is unusable, and AFAIK fixing that bug requires some major changes), and there are not many Linux-specific APIs for server-side stuff ... like the async I/O apis are there only for compatibility, but don't work properly.

I also kind of expected Mono to be more than a .NET clone, and yet there is no alternative to the ASP.NET, which is heavy and is made with .NET's constraints in mind. On Mono it leaks memory for instance.

They could do more for Mono than they already did ... like have 1 or 2 experienced engineers help them with the garbage-collector / or grant them the IP to learn from / use the garbage collector from .NET.

Also, the C# ECMA standard is 2 versions behind, what's up with that?

[viraptor]

> If only Microsoft's management would see this as an opportunity and open up .NET a bit, probably not.

What exactly would you like to open up?