Is there a clear list and description of new Java 7 features?

[Pat Farrell]

The usual linked articles quickly get deep into JSR politics that put me to sleep. And those linked by the top postings in the forum only mention the names of the proposed changes (Coin) and don't explain what it is, or what it isn't (in the case of Coin, it seems that half of it is in Java 7 and some other portion is postponed until Java 8.

Java 5 had generics and an for-loop, and some other stuff.

What is Java 7 about?

[Ulf Dittmer]

This is a good jumping-off point: http://download.java.net/jdk7/docs/. This goes into much more detail: http://openjdk.java.net/projects/jdk7/features/

[Stephan van Hulst]

Oracle's Java tutorials front page also lists a few new features in Java 7, with links to the updated trails.

[Pat Farrell]

Both of these links are fine for some folks, but not at all what I'm looking for.

Why do I care about Java 7? What is the equivalent to generics or better for-loops that make me care?

When I last looked at Coin, it had cool stuff, but from my readings, 7 has only parts of Coin, and I can't tell which, or whether those the are actually in it are interesting.

From the Google Collections folks (now Guava) they said that they tried to get the collections framework into 7, but it got pushed back to "at least 8". This doesn't really change anything for me, I've been using Google Collections for years, and it they came as part of the JDK, all it would do is change a library or two in the Ant script.

I see references to "new" XML handling. The old Java XML processing was too restricted to be useful, so I used other libraries and some that I wrote myself. Should I care about the new XML stuff?

[Rob Spoor]

The ones I'll be looking forward to:
Strings in switch Statements - just because it's handy.
The try-with-resources Statement - copied from C# ("using"), it makes it easier to make sure the resources are closed.
Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking - especially the catching of multiple exception types can save some code; either the need to duplicate catch blocks disappears, or the need for instanceof checking disappears.

NIO2, with the java.nio.file package, seems promising, providing an abstraction layer over the old java.io file handling in a possiblly similar way to Apache Commons VFS. I'd have to work with this to find out if it can fulfill that promise. And if it doesn't, there's still the WatchService to look forward to.

[Pat Farrell]

Rob Spoor wrote:The ones I'll be looking forward to:

Strings in switch Statements- just because it's handy.

The try-with-resources Statement - copied from C# ("using"), it makes it easier to make sure the resources are closed.

Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking - especially the catching of multiple exception types can save some code; either the need to duplicate catch blocks disappears, or the need for instanceof checking disappears.

Thanks for the concise list

I am looking forward to an improved switch syntax, but I think it doesn't go far enough. I don't understand why switch can't work on anything that can be evaluated to a "equals" comparison.

I'm not sure that the try-with-resources will actually be a net win. Time will tell.

Improving catch will be good.

I'm willing to bet that NIO.2 won't be useful to me. I spent many months on NIO (1) and it was simply too buggy and did not deliver significant performance improvements over boring Java IO. The new one won't be one of the first things I try.

I don't see any attraction in all the new socket and networking libraries, perhaps they are cool in the embedded space (cell phones?) and for games. Most of my code doesn't get any fancier than talking to a servlet on one side and a DBMS on the other.

[Mike Simmons]

Pat Farrell wrote:I'm willing to bet that NIO.2 won't be useful to me. I spent many months on NIO (1) and it was simply too buggy and did not deliver significant performance improvements over boring Java IO. The new one won't be one of the first things I try.

Skepticism is understandable at this point, given Java's long history of sucky IO (especially from an ease-of-use perspective). And it's unfortunate that they're calling this NIO.2, since it brings to mind the original NIO, which had a few nifty features but was painful to use. However NIO.2 looks much, much better, with simple method calls to do things like copy or move files, read and set permissions, read all lines from a file into a List, register a watcher for changes in a file, and more. All stuff Java should have had years ago. I agree with Rob that we'll need to actually work with it to see if it fulfills its promise, but from why I see so far it's a vast improvement over most previous Java IO.

Pat Farrell wrote:I'm not sure that the try-with-resources will actually be a net win. Time will tell.

This one looks like a clear win to me (modulo the fact I haven't actually used it yet) - what's your concern?

[Paul Clapham]

All I see for XML is this:

Upgrade the components of the XML stack to the most recent stable versions: JAXP 1.4, JAXB 2.2a, and JAX-WS 2.2

Hardly earth-shaking stuff, although getting rid of the bugs would be nice.

Unless I'm missing something; but I don't think I am, since I haven't heard XML mentioned at all in all of the pre-release chatter.

[Stephan van Hulst]

Pat Farrell wrote:I am looking forward to an improved switch syntax, but I think it doesn't go far enough. I don't understand why switch can't work on anything that can be evaluated to a "equals" comparison.

Probably because the cases need to be compile time constants. The compiler needs to be able to figure out you're not using duplicate cases.

I'm not sure that the try-with-resources will actually be a net win. Time will tell.

This is the feature I'm most excited about. No more tries within tries within tries.

[Mike Simmons]

Stephan van Hulst wrote:

Pat Farrell wrote:I am looking forward to an improved switch syntax, but I think it doesn't go far enough. I don't understand why switch can't work on anything that can be evaluated to a "equals" comparison.

Probably because the cases need to be compile time constants. The compiler needs to be able to figure out you're not using duplicate cases.

Well, I'm not sure they need to do it that way, but they choose to. I think it would be entirely possible to allow arbitrary objects and just convert the whole thing into a series of

if (X.equals(foo)) {
  ...
}
else if (Y.equals(foo)) {
  ...
}

They'd have to explicitly state new rules for what happens if more than one object is "equal". But that's not a big deal. Then again, using switch in this case isn't that much of a win over just writing out all the if/else-if yourself. There are other ways it could be implemented, like converting to a get() on a HashMap<Foo, Integer>, followed by a conventional switch on the integer retrieved.

I suspect that the key issue here was that Project Coin was all about small, simple changes to the languages that would make things nicer for programmers. And the guys who wrote the proposal probably tried to keep it as simple as possible, to enhance the chances of it getting accepted and implemented in Java 7. Nothing prevents them from expanding more on this later on - but Strings are all they are adding now.

[Pat Farrell]

Mike Simmons wrote:Well, I'm not sure they need to do it that way, but they choose to. I think it would be entirely possible to allow arbitrary objects and just convert the whole thing into a series of ...

Its clearly a design/engineering decision. There is no need except that they chose to do it that way. Given that all this runs with the JVM with tones of JIT work, the whole compile-time and execution-time distinction is silly.

Back in ancient times languages would have two switch-type constructs, one that used Mike's if/elseif/elseif constuct, and the other that was only suitable for a "switch" on small integer ranges. The second allows the compiler to build a dispatch table, and just jump indirectly into the table. But, this is moving quickly OT, and into the politics of the JSR stuff that I was complaining about up thread.

[Jeanne Boyarsky]

I like this link. It provides examples of the features one is most likely to use in everyday coding.

Like Pat, I had to do some extra work to find good info via search. In particular, I had to limit results to the past month and add some extra keywords. There's too much info out there from when Oracle was promoting Java 7 a year ago on the Java road trip. I'm glad I named mine what may or may not be in Java 7 because I wrote about closures and they didn't make it in.

[Stan Sokolov]

I deeply disappointed. No closures/lambda expressions no Method references. C# seems has all of those.

Read how cool it can be

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-2.html

[Pat Farrell]

Stas Sokolov wrote:I deeply disappointed. No closures/lambda expressions no Method references. C# seems has all of those.

I don't see this as a problem for Java 7. Doing it cleanly, avoiding the crock stuff they did with generics is a good thing.

But, I'm not sure you can really do it well and still call it Java. I'd love to see a Java-like language that actually does generics and closures properly, which will most surely break backwards compatibility. Keeping backwards computability makes it impossible for a language to improve. Replace one of the A's with a B, like JavB

[Stan Sokolov]

Pat Farrell wrote:

Stas Sokolov wrote:I deeply disappointed. No closures/lambda expressions no Method references. C# seems has all of those.

I don't see this as a problem for Java 7. Doing it cleanly, avoiding the crock stuff they did with generics is a good thing.

But, I'm not sure you can really do it well and still call it Java. I'd love to see a Java-like language that actually does generics and closures properly, which will most surely break backwards compatibility. Keeping backwards computability makes it impossible for a language to improve. Replace one of the A's with a B, like JavB

I did not find generics particularly useful but method references seems to be a feature that can save a lot of development time. Closures by itself is probably a candy for script developers but method references can save a lot of mundane work

Example from the link I provided. ... consider a Person class that can be sorted by name or by age:

class Person { 
    private final String name;
    private final int age;

    public static int compareByAge(Person a, Person b) { ... }

    public static int compareByName(Person a, Person b) { ... }
}

Person[] people = ...
Arrays.sort(people, #Person.compareByAge);

Arrays.sort(people, #Person.compareByAge(Person, Person));
Arrays.sort(people, #comparatorHolder.comparePersonByAge);

[Rob Spoor]

Bad example. By instantiating just one class that implements java.util.Comparable you can do the same thing. You can even make the two Comparable's static final fields:

class Person {    
    private final String name;   
    private final int age;   
   
    public static final Comparator<Person> COMPARE_BY_AGE = new Comparator<Person>() {
        public int compareByAge(Person a, Person b) { ... }   
    };
   
    public static final Comparator<Person> COMPARE_BY_NAME = new Comparator<Person>() {
        public int compareByName(Person a, Person b) { ... }   
    };
}   

Person[] people = ...   
Arrays.sort(people, Person.COMPARE_BY_AGE); 
Arrays.sort(people, Person.COMPARE_BY_NAME);

[Stan Sokolov]

Rob Spoor wrote:Bad example. By instantiating just one class that implements java.util.Comparable you can do the same thing. You can even make the two Comparable's static final fields:

class Person {    
    private final String name;   
    private final int age;   
   
    public static final Comparator<Person> COMPARE_BY_AGE = new Comparator<Person>() {
        public int compareByAge(Person a, Person b) { ... }   
    };
   
    public static final Comparator<Person> COMPARE_BY_NAME = new Comparator<Person>() {
        public int compareByName(Person a, Person b) { ... }   
    };
}   

Person[] people = ...   
Arrays.sort(people, Person.COMPARE_BY_AGE); 
Arrays.sort(people, Person.COMPARE_BY_NAME);

I know that it is all the same but just a way less of low level, interface specific coding.

[Pat Farrell]

Stas Sokolov wrote:I know that it is all the same but just a way less of low level, interface specific coding.

When its "all the same" then all you are talking about is syntactic sugar. Its the curse of adding features this late in a language's life that syntactic sugar that begets bizarre syntax is not a win.

[Stan Sokolov]

Pat Farrell wrote:

Stas Sokolov wrote:I know that it is all the same but just a way less of low level, interface specific coding.

When its "all the same" then all you are talking about is syntactic sugar. Its the curse of adding features this late in a language's life that syntactic sugar that begets bizarre syntax is not a win.

It seems that C# somehow is evolving in this direction and quite aggressively but Java stuck. It is really a shame to have a new release just to introduce String variable in switch statement. Who the hack use the switch statement anyway ?
http://msdn.microsoft.com/en-us/library/bb397687.aspx#Y114

[Paul Clapham]

Stas Sokolov wrote:Who the hack use the switch statement anyway ?

I gotta agree with this. Every time I feel that I have to use a switch statement I have to go and look up the correct syntax for it -- that shows you how much I need it. And switch statements which use Strings as the case identifiers? Using string constants to choose behaviour just smells wrong to me.

[Ulf Dittmer]

Paul Clapham wrote:Every time I feel that I have to use a switch statement I have to go and look up the correct syntax for it -- that shows you how much I need it.

I think it's become much more useful when Enums came along - although more purist OO folks will point out that each time a switch statement is used, that's an opportunity to subclass.

And switch statements which use Strings as the case identifiers? Using string constants to choose behaviour just smells wrong to me.

+1

[Jesper de Jong]

You have to understand something about the history of the development of Java to understand why we now have Java 7 with relatively few new features.

It has been a long time since there has been a new Java version. Java 6 was from December 2006. In the time after Java 6 was released, lots of new ideas have come up for the next version of Java, such as closures, a module system and lots of other things. There was a lot of discussion about how to add closures to Java, there were different proposals, and Sun couldn't decide on which one to go with.

Then business didn't go so well for Sun, so they didn't dare to invest a lot into a new Java version, and eventually Sun got sold to Oracle. Now Oracle has taken the lead to bring Java a step further.

About a year ago, Mark Reinhold, the chief architect of Java SE, proposed two plans: Plan A and Plan B. Plan A meant: continue with developing the new Java version with all the new features that had been proposed in the past years. It would mean that Java 7 would have been ready in the summer of 2012. Plan B was to have Java 7 a lot quicker but with less new features, and then work on the bigger new features for Java 8.

They chose to go with Plan B.

So, there is no need to be disappointed with Java 7. Yes, it doesn't have lambda expressions and a module system, but we knew this in advance, and those big new features are still planned for Java 8, for late 2012.