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?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
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.
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.
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 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).
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.
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?
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 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:
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 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.
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.
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.
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).
0
