Java 9

[Wouter Oet]

Java 8 is more then a year away however some plans have been released for Java 9. For instance: a self-tuning JVM, improved OS/native integration, big-data support, reification, adding tail calls and continuations, a new meta-object protocol to improve cross language support, multi-tenancy, resource management for cloud applications, and the building of heterogeneous compute models (according to this article). What do you guys think about these plans? What should be added?

[Stephan van Hulst]

Tail calls will be great. They will greatly increase the usefulness of recursion. At this time I avoid recursion in Java like the plague.

I would also enjoy it if a lot more Swing classes were generified, such as TableModel columns and TreeNode.

[Rob Spoor]

TableModel and JTable will never be generic. The number of generic types for them would be theoretically unlimited, because you would need a generic type per column. Also, JTable allows its columns to be reordered, meaning that the generic types for its setValue and getValue methods would need to shift around.

I agree with TreeNode, or at least with DefaultMutableTreeNode (in fact, I make my TreeNode implementations generic already). JSpinner is another GUI component that could have generics added, although SpinnerNumberModel may be tricky to adapt.

[Jesper de Jong]

It's good to hear that there are lots of ideas to move Java forward - it has been quiet for a long time between the release of Java 6 in December 2006 and Java 7 in July 2011.

I really hope that we'll get reified generics - type erasure has many nasty side effects. I wonder though how they're going to do that while maintaining backwards compatibility. It's a complicated subject.

You also mentioned big-data support, multi-tenancy and resource management for cloud applications: those are subjects for Java EE 7, which will probably be release around the time that Java SE 8 will be released.

[Rob Spoor]

Jesper de Jong wrote:I really hope that we'll get reified generics - type erasure has many nasty side effects. I wonder though how they're going to do that while maintaining backwards compatibility. It's a complicated subject.

One way would be to add a special marker inside the byte code after the non-generic type. If that marker exists, the following part is the generic type(s). If it's absent (which will be the case for byte code generated by an older compiler) there is no generic type. It's still not trivial after that though - how do you handle these cases during runtime? You can't throw a ClassCastException if you try to cast a List with unknown type to a List<Integer> because the List may well have been a List<Integer> before being compiled.

[Jesper de Jong]

Jesper de Jong wrote:I wonder though how they're going to do that while maintaining backwards compatibility.

I asked this question to Mark Reinhold at the Devoxx conference this week. He said that they might break backward compatibility to make reification possible in Java 9 (but nothing is decided yet).

[Hussein Baghdadi]

Self tuning JVM, tail calls and continuations are great. I don't know why Swing isn't getting more attention.
I'm studying Cocoa and Cocoa Touch frameworks and I'm really amazed by elegance of these two frameworks. There is a lot to bring to Swing, somethings like Core Data and Core Animation frameworks.

No news about Java Micro Edition? really a sad thing.

[Jesper de Jong]

John Todd wrote:I don't know why Swing isn't getting more attention.

Because JavaFX is going to be the new API for desktop (and mobile) user interfaces.

John Todd wrote:No news about Java Micro Edition? really a sad thing.

Oracle is working on a new version of Java ME. I don't know much about it.

[Paul Clapham]

Stephan van Hulst wrote:I would also enjoy it if a lot more Swing classes were generified, such as TableModel columns and TreeNode.

Interestingly, the fact that they made JList a generic class caused some code I wrote to not compile in Java 7, although it did compile in Java 6.

[Jesper de Jong]

Paul Clapham wrote:Interestingly, the fact that they made JList a generic class caused some code I wrote to not compile in Java 7, although it did compile in Java 6.

Normally Oracle is extremely careful to not break backward compatibility. I'm curious why your code doesn't compile on Java 7 while it does on Java 6. Can you share your code here?

[Pat Farrell]

I really hope they break backwards compatibility for Java 9. Type erasure for generics is a good example of a crock that was put in just to ensure backwards compatibility.

But perhaps that would be better called something besides Java. Design decisions that made sense for set-top boxes in 1995 are not optimal for how we will be using Java-like languages in 2015 and beyond.

[Paul Clapham]

Jesper de Jong wrote:

Paul Clapham wrote:Interestingly, the fact that they made JList a generic class caused some code I wrote to not compile in Java 7, although it did compile in Java 6.

Normally Oracle is extremely careful to not break backward compatibility. I'm curious why your code doesn't compile on Java 7 while it does on Java 6. Can you share your code here?

Sure, here it is:

public abstract class BNBList<T> extends JList {

...

  @Override
  public void setListData(Vector<?> list) {
    ...
  }

}

The error message is "The method setListData(Vector<?>) of type BNBList<T> must override or implement a supertype method". The class compiles fine in Java 6, where JList was not generic, but in Java 7 it doesn't. I was a bit startled by that when I installed the new version of Eclipse and recompiled my project in Java 7. The fix isn't difficult, but not completely obvious.

[Pat Farrell]

Paul Clapham wrote:The fix isn't difficult, but not completely obvious.

Can you share the fix? I often beat my head against the wall trying to fix generic argument problems.

[Rob Spoor]

Probably switch to

public abstract class BNBList<T> extends JList<Object>

, or change that entire code to

public abstract class BNBList<T> extends JList<T> {   
   
...   
   
  @Override   
  public void setListData(Vector<? extends T> list) {   
    ...   
  }   
   
}  

[Paul Clapham]

Yes, the latter would have been (and will be) how I fix it.

[Luc Lieber]

How about a 100% pauseless garbage collector that doesn't fall back on "Stop The World" and break application responsiveness.

[Pat Farrell]

Luc Lieber wrote:How about a 100% pauseless garbage collector that doesn't fall back on "Stop The World" and break application responsiveness.

That is actually very, very hard to do. If you let the application run, how can the GC know that the snapshot of memory it has is still valid?

I believe Azul Systems sells one. I seriously doubt that Oracle would put that kind of engineering effort into Java.

[Luc Lieber]

Pat Farrell wrote:That is actually very, very hard to do. If you let the application run, how can the GC know that the snapshot of memory it has is still valid?

I believe Azul Systems sells one. I seriously doubt that Oracle would put that kind of engineering effort into Java.

I'm aware of their Zing JVM, but I'm afraid to think of what they charge for it.

As Java stands now, it won't be able to break its current memory constraints. In my humble opinion, if Oracle wants Java to survive in the future years, they should make some effort to raise the heap size that can be effectively used. Azul has a neat video out on the net explaining the huge brick wall that Java has finally reached regarding the current garbage collector (and vaguely how they solved it.)

I come from a C++ background...and I still haven't figured out why Java hasn't implemented a transparent reference counting system. It seems to me that a reference counting system would be more predictable than a GC that seems to do what it wants, when it wants without any much developer control.

[Pat Farrell]

Luc Lieber wrote:I come from a C++ background...and I still haven't figured out why Java hasn't implemented a transparent reference counting system. It seems to me that a reference counting system would be more predictable than a GC that seems to do what it wants, when it wants without any much developer control.

There are problems that Java simply is not the right tool. C++ programmers write leaks. They always do. Better programmers write fewer leaks.

Java avoids that problem, and has others.

There is no perfect language.

For most of what I would pick C++ for in the past, I'd probably pick Google's GO today.

[Luc Lieber]

Pat Farrell wrote:C++ programmers write leaks. They always do.

Years ago, I would have agreed, but not anymore. C++ has evolved. Smart pointers in the C++11 standard (and boost libraries) have made it much harder to write leaks. Granted, there are still those that cling to using 'C with classes' that write leaks, and shouldn't be called C++ programmers imo.

Pat Farrell wrote:There is no perfect language.

Agreed, 100%.

[Luc Lieber]

Back on track, I'd also like to see variadic generics in a future version of Java (after the type-erasure hack job is fixed).

[Nick Wiggill]

Reified generics -- no doubt about it. That's the single most important thing.

Import aliases would come in handy, too (as C#).

[Claude Moore]

What do you mean with "big data" support ?

[Steve Fahlbusch]

Java 9 is now to the place where python had to go from 2.x to 3.x.

The object model in python 3.x has totally changed. We now have a noes language. But they were so nice as to provide a tool to tell us our code (2.x) would not continue to work (3.x).

So let us break and embrace the new java.

[Pat Farrell]

Steve Fahlbusch wrote:So let us break and embrace the new java.

I am all for a new Java that is NOT backward compatible.
The mess that is generic support that started in Java 5 is, IMHO, a really bad idea.