Slashdot Mirror


Java 7: What's In It For Developers

GMGruman writes "After five years of a torturous political process and now under the new ownership of Oracle, Java SE 7 is finally out (and its initial bugs patched in the Update 1 release). So what does it actually offer? Paul Krill surveys the new capabilities that matter most for Java developers, from dynamic language support to an improved file system."

12 of 338 comments (clear)

  1. Re:A language with a file system? by iggymanz · · Score: 5, Informative

    It's just improvements to the I/O API. Java has the New IO API for doing I/O. java 7 has extended it, hence NIO2. http://www.ibm.com/developerworks/java/library/j-nio2-1/?ca=drs-

  2. Re:Kill it Oracle by Anonymous Coward · · Score: 4, Insightful

    Ah yes. The old "blame the language for the lack of a developer's skills" ploy. It's a sad carpenter who blames his tools for his incompetence. It's a sadder carpenter who blames a tool for other carpenters' incompetence.

    Just curious: what do you think all those "Java weenies who couldn't code themselves out of a paper sack" would do if Java died. Would they magically become skilled code gurus because Java doesn't exist? Or would they be incompetent coders in a different language?

    As Dilbert so succinctly put it: you're solving the wrong problem!

  3. Re:One day we will be done with java... by Anonymous Coward · · Score: 5, Insightful

    While you are busy being a jackass and letting us all know you have never made a single mistake EVER with resource allocation, some of us have work to do and enjoy the fact that we will never have to type try{openFile}catch(DamnException){}finally{try{closeFile}catch(AotherDamnException){}} ever again.

  4. Re:Devs can now be more lazy by ApplicativeJones · · Score: 5, Insightful

    Yes. Let's shun all advances in programming language design, because they make it too hard to use languages without them.

    Man, imagine what'd happen if you ever ran into a programming language with a good design. There are some out there that are actually pretty good. Of course, no language is perfect - or even close. But people who resist making things better just because it makes defects in existing languages more obvious is doing themselves, and the entire field of software engineering, a disservice.

  5. Re:Kill it Oracle by Rik+Rohl · · Score: 3, Funny
  6. Re:Improvements by slack_justyb · · Score: 4, Interesting

    Arguments for slow Java are so 1990's. Every Java application, desktop or otherwise, I have written has been very snappy, very responsive. Swing has always had places where you can get caught making your own application slow to load or slow to respond. I believe that the community and Sun have really ushered in conventions to mitigate that. SwingWorker (part of core Java Swing), Timing Framework [java.net], JPA (especially our friends at Eclipse), and other community frameworks have really changed the way coders write Java desktop applications in ways that avoid a lot of the pitfalls that came with the 1.1, 1.2 and so on versions of Java.

    I think this is the reason why Oracle really needs to embrace the community. It has been because of them that Java has gotten better and faster with each release. People who still talk about how slow Java is and how crappy Swing is, are still living in the past. Is it the perfect platform? No, but it has gotten multiple times better than where it was.

  7. Re:Devs can now be more lazy by slack_justyb · · Score: 3, Interesting

    once you have programed in Java for a few months you are incapable of writing functional C++ code

    Having been a Java developer for eleven years now, I still write C++ with few memory leaks and a couple of passes through a debugger usually fixes that. I am not sure why people believe Java makes you a bad programmer. Java, C#, and C++ all follow the same design patterns, they just use different methods on getting there. It is really not that hard to remember, hey in this language the object is GC and in this one it isn't. A singleton design pattern in C++ and Java look exactly alike and function exactly the same. Java you don't have to worry about cleaning the mess up and in C++ you clean it up in the destructor, c'mon some people make it out to be the difference between gutting a fish and brain surgery. It's all syntax sugar, a lot of people need a new argument.

  8. Riddled with errors by Samantha+Wright · · Score: 3, Insightful

    Among the delayed capabilities are adding Lambda expressions, or "closures," to Java for multicore programming, ...

    Lambda expressions are not closures, and neither enable parallelization. Yes, the Wikipedia articles for both are dense swamps, but couldn't you have at least tried to ask someone? Please?

    --
    Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
    1. Re:Riddled with errors by Animats · · Score: 3, Insightful

      Lambda expressions are not closures, and neither enable parallelization.

      I noticed that too. Somehow, in the Java community, closures somehow became connected to lambda expressions. Whether you have a syntax for anonymous functions is completely separate from whether you have closures.

      In a reasonably static language like Java, adding closures makes the concept of the "stack" a lot more complex. A closure can contain a binding to a local variable outside the closure. That binding can outlive the scope of that local variable. So local variables now have to be handled in a more general (and slower) way. The semantics of local variables gets a lot more complicated, too.

      Perl, Python, and Javascript have closures, although most programmers who use those languages don't know it. In those languages, any nested function can potentially be a closure. (Well, in Perl, there's a warning if you do that.) The Java people don't seem to have taken that route, possibly because they don't want to incur the overhead of a closure unless the programmer really wants one.

  9. Re:Improvements by Lisandro · · Score: 3, Informative

    To be fair here compared to other interpreted languages Java is still the king of the hill. By far.

    Disclaimer: Yes, interpreted. Bytecode is interpreted, even with stuff like JIT.

  10. Re:Devs can now be more lazy by ispeters · · Score: 3, Informative

    Are you trolling? You said:

    There has got to be a performance hit for "extending" garbage collection to files, sockets, and databases. How hard is it to realise you no longer need a resource and free it.

    They haven't "extended garbage collection", they've introduced syntactic sugar. Instead of this (with real indenting in real life because you're not limited by Slashdot's lame commenting system):

    File file = null;

    try {
    file = openAFile();

    // operate on file, possibly causing an exception
    }
    catch (IOException e) {
    // do whatever you like with e, possibly rethrowing
    }
    finally {
    if (file != null) {
    try {
    file.close();
    }
    catch (IOException e) {
    // what the hell do you do here?
    }
    }
    }

    You can have something like this:

    try (File file = openAFile()) {
    // operate on file, possibly causing an exception
    }
    catch (IOException e) {
    // do whatever you like with e, possibly rethrowing
    }

    // file is closed here because the compiler has inserted
    // the right epilogue for you, saving you boilerplate, preventing
    // you from inserting the wrong boilerplate, and not impacting
    // the GC in the slightest

    So either you're trolling or "The Dawn Of Time" is right: you have no idea what you're talking about.

    Ian

  11. Re:One day we will be done with java... by BotnetZombie · · Score: 3, Interesting

    "Write once, run anywhere" was like communism -- an idea that sounds nice in theory in some ways but utterly fails to work in reality.

    True, if you hardcode C:\something or /somethingelse in your app. I've never had cross-platform problems, either on big server side applications or trivial desktop ones. So I guess 'utterly failes to work in reality' is somewhat dependent on the developer.