views:

2476

answers:

7

Possible Duplicate:
What new features in java 7 do you find most useful?

What are some features that you like in the next version of Java?

+8  A: 

I'm looking forward to a decent date and time API being in the core libraries, so there's no excuse to use Date and Calendar any more (other than backward compatibility). Admittedly that's a library feature rather than language.

If the resource disposal feature gets in there - the equivalent of C#'s using statement - that will be really handy. Admittedly I'd really like closures in there as well, but introducing closures into Java is complicated by checked exceptions :(

Jon Skeet
I agree, the Date implementation in Java's library is atrocious... especially if you are used to using .Net
jle
The .NET APIs are nothing to crow about though - particularly before .NET 3.5, when we *finally* got non-local, non-UTC time zone support. It still doesn't really support the different ideas of an instant, local date, local time, duration etc. Joda Time is complicated, but only because the subject matter is inherently complicated.
Jon Skeet
Looks likes the JSR spec lead is too busy to complete it before Java SE 7 deadline. I <3 JCP.
Tom Hawtin - tackline
I will continue using joda-time :)
Macarse
Joda Time FTW, so don't bother!
alamar
If I have to fiddle with conversions between java.util.Date and java.sql.Date one more time, my head may or may not explode. It's pretty unclear at this time.
MattC
Joda-Time is great, but as the joda lead is the JSR lead I'd seriously consider switching over when it is done.
GaryF
+2  A: 

Collection literals.

To solve this kind of problem.

Macarse
It's not hugely great. In that example ArrayList<String> places = new ArrayList<String>(Arrays.asList("Buenos Aires", "Córdoba", "La Plata")); becomes ArrayList<String> places = new ArrayList<String>(["Buenos Aires", "Córdoba", "La Plata"]);
Tom Hawtin - tackline
+11  A: 

Since closures will -- as far as I know -- not be in Java 7, I'm not particularly interested in Java 7, anymore. I will probably use more alternative languages on the JVM like Scala or JRuby.

However, some Project Coin enhancements are nice (see also), e.g.

  • multi-catching of exceptions
  • Indexing syntax for lists and maps
  • Collection literals
  • Large arrays: When lsts of server have 16 GB+ memory and int slowly gets to small.
  • "invokedynamic": New operation to better support dynamic languages on the JVM

Edit: It should be noted that some kind of closures will be in Java 7 (should it ever be released)

dmeister
Totally agree. Without closures, Java 7 is completely irrelevant.
Apocalisp
Large arrays and multi-catch are out, apparently: http://blogs.sun.com/darcy/entry/project_coin_final_five
Stu Thompson
Anyone know what the collection literal syntax would be? Same as array literal?
TM
What does this mean then? http://tech.puredanger.com/java7/#closuresIt says "YES" next to it? Too bad. I was looking forward to closures.
Vivin Paliath
+6  A: 

I do lots of IO work, so NIO2 is something I am looking forward too. From the JSR:

  • A new filesystem interface that supports bulk access to file attributes, change notification, escape to filesystem-specific APIs, and a service-provider interface for pluggable filesystem implementations;
  • An API for asynchronous (as opposed to polled, non-blocking) I/O operations on both sockets and files; and
  • The completion of the socket-channel functionality defined in JSR-51, including the addition of support for binding, option configuration, and multicast datagrams.

Secondly, there are two things to reduce Java's verbosity that I'm looking forward to, albeit the later is almost trivial. Regardless, both will help make Java slightly more terse.

Simplified Generics are high on my happy list. Throw in modifiers and larger class names and these lines of code can get borderline unreadable.

Map<String, List<BigDecimal>> numberMap = new TreeMap<String, List<BigDecimal>>();

...becomes...

Map<String, List<BigDecimal>> numberMap = new TreeMap<>();
Stu Thompson
Would've been nice, but alas.
Eelco
Ah...I see the improved catch block is out. Sniff, sniff. http://blogs.sun.com/darcy/entry/project_coin_final_five
Stu Thompson
This is a shortcut syntax for eliminating duplication when instanciating ojects of generic classes, but that's not type inference, at least not beyond that particular case.
Rafa Castaneda
@Rafa Castaneda: Oops, you are correct. The two had merged in my mind.
Stu Thompson
A: 

API support for interfacing with USB peripherals.

snake
+5  A: 

No one's mentioned fork-join yet? See this for details..

Tim
yes of course how can we forget light weight and heavy weight components ;)
Aizaz
Care to elaborate your comment?
Tim
A: 

java.util.programmer :) more productivity for programmer, modularity and independent.

Aizaz
Java non blocking calls. I just love that. currently using Apache MINA that is excellent built over Java NIO
Aizaz
EqualsDeep() a fault proof equals method.
Aizaz