aspose file tools*
The moose likes Features new in Java 7 and the fly likes Is there a clear list and description of new Java 7 features? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Features new in Java 7
Bookmark "Is there a clear list and description of new Java 7 features?" Watch "Is there a clear list and description of new Java 7 features?" New topic
Author

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

Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4658
    
    5

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
Marshal

Joined: Mar 22, 2005
Posts: 41873
    
  63
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/


Ping & DNS - my free Android networking tools app
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3647
    
  16

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

Joined: Aug 11, 2007
Posts: 4658
    
    5

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
Sheriff

Joined: Oct 27, 2005
Posts: 19696
    
  20

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.


SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6
How To Ask Questions How To Answer Questions
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4658
    
    5

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
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3014
        
      10
    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
    Bartender

    Joined: Oct 14, 2005
    Posts: 18570
        
        8

    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
    Bartender

    Joined: Sep 20, 2010
    Posts: 3647
        
      16

    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
    Ranch Hand

    Joined: Mar 05, 2008
    Posts: 3014
        
      10
    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

    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
    Rancher

    Joined: Aug 11, 2007
    Posts: 4658
        
        5

    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
    internet detective
    Marshal

    Joined: May 26, 2003
    Posts: 30537
        
    150

    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.


    [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
    Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
    Stas Sokolov
    Ranch Hand

    Joined: Apr 13, 2004
    Posts: 117

    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


    Good luck for yourself.
    Pat Farrell
    Rancher

    Joined: Aug 11, 2007
    Posts: 4658
        
        5

    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
    Stas Sokolov
    Ranch Hand

    Joined: Apr 13, 2004
    Posts: 117

    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:
    Rob Spoor
    Sheriff

    Joined: Oct 27, 2005
    Posts: 19696
        
      20

    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:
    Stas Sokolov
    Ranch Hand

    Joined: Apr 13, 2004
    Posts: 117

    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:


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

    Joined: Aug 11, 2007
    Posts: 4658
        
        5

    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.
    Stas Sokolov
    Ranch Hand

    Joined: Apr 13, 2004
    Posts: 117

    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
    Bartender

    Joined: Oct 14, 2005
    Posts: 18570
        
        8

    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
    Marshal

    Joined: Mar 22, 2005
    Posts: 41873
        
      63
    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
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14153
        
      18

    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.


    Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
    Scala Notes - My blog about Scala
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Is there a clear list and description of new Java 7 features?