Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Oracle

Java 7: What's In It For Developers 338

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."
This discussion has been archived. No new comments can be posted.

Java 7: What's In It For Developers

Comments Filter:
  • Along with promoting an easier multithread API the artical also contain the paragraph:

    Project Coin's diamond syntax for constructor calls lets the compiler infer type arguments, and the try-with-resources statement helps the compiler make reliable code by automatically closing files, sockets, and database connections when developers forget to do this, Ratcliff says: "That's something that's been tripping up developers -- especially young developers -- for years. That'll be a good productivity improvement and will reduce bugs."

    This is almost like programming language lock in, once you have programed in Java for a few months you are incapable of writing functional C++ code and if you lean to program in java you have no idea why your non java programs fail.

    • by ApplicativeJones ( 1579281 ) on Wednesday August 24, 2011 @10:40PM (#37201188)

      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.

      • by nzac ( 1822298 )

        Are these really meaningful advances? (If they are then yes i would agree with you)

        Though i have no idea what they added to thread module if it was an advancement i would think you could sell it a bit better than it makes things easier. 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.

        Sure its fine if you don't need it to be faster than python (or pypy) but changes like these (yes yo

        • Are these really meaningful advances?

          Making it easier for people to close files? I'd say that was an advance.

          At least somebody is finally admitting that garbage collection causes as many problems as it solves.

        • by ispeters ( 621097 ) <ispeters@alumni. ... oo.ca minus poet> on Thursday August 25, 2011 @02:02AM (#37202272)

          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 [slashdot.org]: you have no idea what you're talking about.

          Ian

          • by nzac ( 1822298 )

            Sorry was not clear i meant to imply they were applying the concept of GC to resources other then memory. Java decided you no longer need the resource and frees it. This is simplified situation say you make an object that opens a file (or other resource) but then still need the object without the file then the VM would recognise this and close the file. Its more complex than just SS.

            And you raised the issue of what happens if you cant close/save the file, it would be come more complex to handle the only way

        • Performance hits for closing files is extremely minimal. By far the slowest part of writing a file is the time it takes to transfer it to disks. It is in fact often on the order of a million times slower than any other part. Worrying about the performance hit of a few extra instructions to close a file is silly in that context. There is a law related to this point, but I can't find it right now. It is described under The General Task of Code Optimization [azillionmonkeys.com].
        • There has got to be a performance hit for "extending" garbage collection to files, sockets, and databases.

          No, there does not. All that is happening is the compiler is writing correct code for you that is commonly used, so that you don't have to try and get it right.

        • by dkf ( 304284 )

          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.

          Garbage collection can take some time to realize that a resource is no longer needed and release it. For memory, it's mostly not a huge problem (and you can tune how often the garbage collector runs) but many other resources come from really rather small pools so releasing them earlier is really important. This is especially so for anything connected to a file descriptor and/or process, such as all those that you list.

          Releasing a resource early means doing some kind of close operation on it, and requires th

    • by slack_justyb ( 862874 ) on Wednesday August 24, 2011 @11:09PM (#37201356)

      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.

      • by nzac ( 1822298 )

        I did not say its currently the case, looking at the article I suggested/said it could be going there. (I do think that some of Javas features unnecessary make it easy for people to write programs that could easily preform better.)

        Do you believe, not having to close unlock things makes you a better programmer? or that developer of Java will magically make it so there are no issues like (unnoticeable but cumulative) effects on performance, keeping the file open longer than it needs to be or having to reopen

        • I don't know about you, but when I walk into a convenience store, I pull the door open and walk in. From there, I don't turn around and pull the door closed behind me because it does that by itself. I don't think that makes me a better or worse shopper, but I think it's one less thing for me to worry about. There are no points awarded in life for having a bigger pile of stuff to worry about.
          • by nzac ( 1822298 )

            I don't like your metaphor, you have simplified the issue too far and it hides the numbers needed to compare things to see if the tradeoff is worth it and I never said there is a problem with the part you described.

            But to carry it on what happens when you go to another store and the door does not close and something goes wrong (say something gets blown over and you have to pay for it) or when to cover the cost of putting the door they markup your prices. (I assume the door is hypothetical as here the door w

            • The example was intentionally simple because I'm only pointing out that there's nothing inherently wrong with, as a programmer, letting technology make life a little easier. Certainly we can take the door example or even the real world example of people not closing files/sockets properly in all sorts of directions, but in general, it's OK if things are made easier. Generally, it doesn't turn programmers into simpletons because for every new little nice short cut and helpful feature, there is more and more r
              • by nzac ( 1822298 )

                Thus we have scripting languages (for performance CPython or pypy) which is this taken to the extreme.

                I said that due to the tone of the article and the quote (i don't know who he is) that making the language easier (rather than simpliler) would make it make it harder to move to another language (others have said this is nothing new) and that it could be intentional.I think i left it up to the reader to decide the extended consequences of this.

        • Do you believe, not having to close unlock things makes you a better programmer?

          No and that's not the point of these features. A car can have a manual or automatic transmission. Either one won't prevent the driver from being an ass to me on the road or make them a safer driver overall. Likewise, the features aren't there to make one a better programmer or a programmer who is bad at resource handling suddenly better. The features are there to handle certain cases automatically, cases where we've already had a solution (using finally) but would have preferred it to be less verbose.

          Li

          • by nzac ( 1822298 )

            I think the design focus should be simpler rather than easy (using the word easy over simple just screams bad deign to me, maybe the article writer just chose the other work). I tried to make it obvious that my one line was based of the paragraph from the articular. I don't think anyone who has much influence has ever wanted GC directly built into C++. It just does not fit to have automatically included in Native Code.

            I never said this would make you a bad programmer just that it would be frustrating/diffic

        • by bonch ( 38532 ) *

          Do you believe, not having to close unlock things makes you a better programmer? or that developer of Java will magically make it so there are no issues like (unnoticeable but cumulative) effects on performance, keeping the file open longer than it needs to be or having to reopen it?

          I believe not having bugs makes you a better programmer, and if the language helps enforce that by design, even better. If you're trying to prove yourself by doing things manually that computers are capable of handling for you,

      • Java you don't have to worry about cleaning the mess up and in C++ you clean it up in the destructor

        If you're doing it right C++ needs very few destructors and memory leaks only happen once every blue moon.

        • If you're doing it right C++ needs very few destructors and memory leaks only happen once every blue moon.

          Exactly. Usually deep in the code internals you'll see a couple of d-tors that do all the delete's. Everything else just seems to auto-magically happen and delete itself, sorta like Java.

    • by sjames ( 1099 )

      Can you believe these so-called programmers? Always going on about their infernal structured whatsises with their new-fangled compilers and crap! Real men program directly in binary and enter the code with toggle switches. How will the program layout ever be right if you let some so-called "linker" do it? IOf that wasn't bad enough, now they want to ling AT RUN TIME fercristsake!

      Now GET OFF MY LAWN!

    • by tsotha ( 720379 )
      After using java for a decade or so I can't go back to C++. It would be hard to program anything after gouging my eyes out.
    • by SJS ( 1851 )

      The problem you describe isn't one of developers being lazy... it's a problem of developers being *stupid*, and failing to learn anything from the languages they've previously programmed in. Every language you use in anger should inform you about viewpoints and techniques for every subsequent language, even if they don't directly apply.

      This is why all programmers should start with a language like Pascal, so they learn the basics of structured programming, lexical scoping, and what the hell the difference

    • by bonch ( 38532 ) *

      Just look at those silly C++ programmers letting the compiler manage the stack for them. Once they've programmed in C++ for a few months, they'll never be able to manually set up call stacks in assembly across multiple operating systems and instruction sets.

  • ...please don't let all these fancy tech buzzwords stop Minecraft from working.

  • "...Paul Krill surveys the new capabilities that matter most for Java developers..."

    Do these developers include Android developers? Well, that's the question. After all, Java code will run on Android's Dalvik VM without modification, right?

  • As a developer I could care less about Java itself. It's the new Cobol.

    It's in an awkward spot. For anything high level I'd rather just use Python. And for the few cases where Python's not fast enough, it's easiest to jump down to C++ and write a module I can call from Python.

    The best thing about this new release are JVM improvements for dynamic languages, which should help out projects like Jython, JRuby and Scala.

  • http://www.java.com/en/download/faq/java7.xml [java.com] -- "Why is Java SE 7 not yet available on java.com?

    Java SE 7 is the latest release for Java that contains many new features, enhancements and bug fixes to improve efficiency to develop and run Java programs.

    Why is Java SE 7 not yet available on java.com?

    The new release of Java is first made available to the developers to ensure no major problems are found before we make it available on the java.com website for end users to download the latest version. If you are

  • by Samantha Wright ( 1324923 ) on Wednesday August 24, 2011 @11:38PM (#37201504) Homepage Journal

    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?

    • by Animats ( 122034 ) on Thursday August 25, 2011 @12:24AM (#37201776) Homepage

      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.

  • No Thanks! (Score:2, Funny)

    by Greyfox ( 87712 )
    I've been playing with C++ again recently and had forgotten how much I really liked the language. I have real destructors again! That, along with oracle's recent abusive behavior toward Android leads me to dance the "Oracle can Blow Me" dance! Here I go! Oracle can blow me! Oracle can blow me! Yeah! Shake it!

    Google just needs to re-implement all their shit in C++ and we can get an "Oracle can Blow Me" congo line going. Having a native mode executable build down to 20 *kilobytes* and actually run in 20 kil

    • 20 kB. You clearly are not building applications that are hundreds of thousands of lines with dozens on people working on it. If you were you would be looking at things a little differently (and yes, sure you can do stuff in C++, as I did for a decade, but you are not nearly as productive as you are in Java).

The clash of ideas is the sound of freedom.

Working...