This is really bad idea. Java and the JVM can still be greatly improved. Closures, fixing generics, tail call optimization, module system, faster startup, etc.
JavaFX will be a nice improvement once it's integrated with Java.
JavaFX will be a nice improvement once it's integrated with Java.
Tail-call optimization is just that, an optimization. A 1.6 compliant, open-source JVM could provide that. Same with the faster startup time.
As I don't generally use closures, and would replicate their abilities through interfaces and anonymous classes, I don't have a comment on them; and you'd need to expound upon "module system" for me to say anything.
I'm going to be slightly handwavy, so forgive me: Generics are implemented by doing type erasure[1] rather than as 'real generics' through some other method. This causes issues with runtime reflection.
> would replicate their abilities through interfaces and anonymous classes,
This embodies exactly what I hate about Java: In other languages, where I simply 'do/end' or ' \ ->', I have to create a whole giant pile of boilerplate bullshit to pull off something that's supposed to be easy.
1: http://en.wikipedia.org/wiki/Generics_in_Java#Type_erasure
On Java-bloat: to be fair, it's really not that much, especially if it's already a known interface: new TreeSet<Foo>(new Comparator<Foo>() { public void compare(Foo a, Foo b) { mycode(); } });
However, your point stands. I've just come to accept that as being a part of Java, myself.
Tail call optimization is not a mere optimization. A jvm cannot provide it and still provide conforming exception stack traces, for example.
As far as closures: you're missing out :)
It just won't run (for very long). :)
int A() { return 1 + B(); }
int B() { return 1 + A(); }
(with necessary ending conditions)
Note that your example was not of tail calls, however. (Tail call would be: return A(...); that is, a tail call is one whose result is immediately returned.)
And, woops...
If you find yourself wanting to pass in Collection<Firetruck> to a method that only accepts Collection<IVehicle>, this usually means that the method isn't correctly typed. The rule of thumb for using 'super' and 'extends' is "Producer extends, Consumer super" or PECS. By applying this, the typing problem should go away, as your method is now accepting Collection<T extends IVehicle> and possibly returning Collection<? super T>, so you can both pass in your Collection<Firetruck> and reassign to a different variable of type Collection<Firetruck>. :)
(I think Josh Bloch wrote up a decent blog post about the PECS principle a couple of years ago. It might be worth reading for more information.)