Slashdot Mirror

← Back to Stories (view on slashdot.org)

Java 7: What's In It For Developers

Posted by samzenpus on from the take-a-look-under-the-hood dept.

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."

258 of 338 comments (clear)

  1. Re:Kill it Oracle by LordLimecat · · Score: 1

    You can usually spot "likely to be baseless" criticisms on slashdot, even if youre not up to date on the particular topic. Usually they are made by ACs.

  2. Re:A language with a file system? by pauljlucas · · Score: 2, Informative

    I assume the author meant, "... to improved file system access." See here.

    --
    If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
  3. 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-

  4. 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!

  5. Re:A language with a file system? by Anonymous Coward · · Score: 1

    I don't know what you were voted up for, but it is kind of obvious that it means "an improved file system API".

  6. Devs can now be more lazy by nzac · · Score: 1

    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.

    1. 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.

    2. 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.

    3. Re:Devs can now be more lazy by nzac · · Score: 1

      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 it?

    4. Re:Devs can now be more lazy by dummondwhu · · Score: 1

      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.

    5. Re:Devs can now be more lazy by nzac · · Score: 1

      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 you could pretended they don't exist and then it may not matter) were to accumulate it could hurt the language rather than make it better. Assuming that Java programs do run (insignificantly) slower, it makes C++ and its dev's all that more important.

    6. Re:Devs can now be more lazy by sjames · · Score: 1

      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!

    7. Re:Devs can now be more lazy by The+Dawn+Of+Time · · Score: 1

      In your first sentence you explain you have no idea what you're talking about, then you proceed to spout off in the remainder of your post anyway. You're pretty clearly the voice of inexperience. You should learn to lurk more and talk less.

    8. Re:Devs can now be more lazy by slack_justyb · · Score: 2

      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.

      Likewise, GC has been a favorite subject of C++. Should we have GC in the core of C++ or not? There is always a third party library that can add GC to your C++ project. Does using that library make you a bad coder?

      Making your job easier is not equal to making you a bad coder. A bad coder *is* no matter the language, platform, or libraries used. When I develop applications that need to talk to a DB, I have to think about when I need to let that connection go, it doesn't matter if I am using Java or C++ or Python, when to let go of a connection is part of the design, not the language. The language part only dictates how many lines of code it will take to let the connection go, not when. If you are not thinking about how you handle resources it is not a problem of the platform so much as it is the design phase. Even in GC environments you have to keep track of what is happening to your resources, you just keep track of them in a different manner.

      As a rough example: I open a file in Java or C++, I still have to think about how that file will be used and when I need to close it (no other option in C++) or just let it close by itself (an option in Java but not usually the best one.) If we are talking about a text file that only the current running application is going to use then yeah let it close by itself in Java and close the file in the destructor of the main delegate (or whatever you may have used to open the file) in C++. Both of those options function the exact same way, the file doesn't close until the application does. It's just syntax sugar that separates them, either way I've got to remember that I have a file open.

      I did not say its currently the case, looking at the article I suggested/said it could be going there.

      That's been an argument for decades for everything. Again, making something easy does not make a bad programmer. Bad programmers tend to not think things out fully and giving them a manual or automatic isn't going to change that.

    9. Re:Devs can now be more lazy by Joce640k · · Score: 1

      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.

      --
      No sig today...
    10. Re:Devs can now be more lazy by nzac · · Score: 1

      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 would both open and close for me.)

    11. Re:Devs can now be more lazy by Joce640k · · Score: 1

      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.

      --
      No sig today...
    12. Re:Devs can now be more lazy by dummondwhu · · Score: 1

      Certainly, but in this case, I am a user. The architects at Oracle (hopefully) made sure that the doors close correctly. I don't know that to be a certainty, as I haven't tried Java 7 yet, but you get my point. It doesn't mean that I've devolved into an end-user. It's just that my job was made easier.

      At some point, farmers mostly stopped planting fields with the help of a hoe and they hooked up plows to oxen or some other beasts. Then, the tractor was invented, making life even easier. Advance after advance after advance, and no one would think to say a farmer today is less capable. Sure, he could do his job with hand tools. But how many people would he be able to feed that way?

    13. Re:Devs can now be more lazy by tsotha · · Score: 1

      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.

    14. Re:Devs can now be more lazy by dummondwhu · · Score: 1

      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 room to do bigger and better things without being encumbered by so much of the small stuff (especially forgetting the small stuff here and there and spending an inordinate amount of time trying to figure out what went wrong).

    15. Re:Devs can now be more lazy by ApplicativeJones · · Score: 1

      Let me just make one suggestion: Learn another programming language. Learn something fundamentally different. Learn it thoroughly. Then decide if there have been advances made in the design of programming languages since C++.

      I'd recommend Haskell, myself. It's the furthest you'll get from the mainstream, while still having incredible support for writing real software. But if you learn it, make sure to learn it thoroughly.

      Understand what the IO type really is. Not how it's implemented, that's boring. Not what type classes it implements, that's still relatively boring. Understand the consequences of it being a higher-kinded type that describes IO operations as a first-class type. Understand what a type like "IO (IO (), IO ())" means, and why IO is far more interesting than just a tag on impure functions. Understand what a type like "FilePath -> IOMode -> (Handle -> IO r) -> IO r" means, and how it's related to the original point here.

      And that's just scratching the surface. Is Haskell perfect? Far from it. Very far from it, in fact. But there are a lot of things it does better than any other language you can build real software with. It's worth learning what those things are. Once you see that there are fundamentally better ways, you might begin to welcome advances to mainstream languages.

    16. Re:Devs can now be more lazy by nzac · · Score: 1

      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.

    17. Re:Devs can now be more lazy by nzac · · Score: 1

      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/difficult to move to an alternative language.

      That's been an argument for decades for everything...

      Fair call but then i would have just be modded off topic.

    18. Re:Devs can now be more lazy by slack_justyb · · Score: 1

      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.

    19. 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

    20. Re:Devs can now be more lazy by SJS · · Score: 1

      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 is between pass-by-reference and pass-by-value. It would be best if at least one other language were to be learned before the programmer attemps to learn Java.

      I would never recommend that any programmer learn C++, except as an example of what NOT to do when designing a language. Learning C is a good idea, so the programmer can learn what a high-level assembler looks like.

      A language like Smalltalk or Self should be thrown into the mix somewhere, just for contrast.

      Some sort of prolog should prove useful as well. (Although, if you seriously think that adopting the prolog viewpoint for general computing, you need to be shot in the face.)

      And if trying all these languages doesn't improve your code... you're in the wrong job.

      (As for laziness... that's a virtue, according to Larry Wall, and he's likely right.)

      Personally, I found that once Generics and Annotations were imposed on Java, the language became a lot harder to read and maintain. They might as well just gone ahead and mandated the abomination that is hungarian notation and made the language completely stupid.

      But then, Java was something like language #11 that I learned. So my viewpoint is biased.

      Support for other languages in the JVM might be nice, but I really don't see the point.

      --
      Pick One: http://www-rohan.sdsu.edu/~stremler/sigs/sigs.html (Note - disable Javascript first!)
    21. Re:Devs can now be more lazy by bonch · · Score: 2

      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, you're programming for the wrong reasons. Users don't give a shit how you made the product; just that it doesn't crash or leak.

    22. Re:Devs can now be more lazy by bonch · · Score: 1

      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.

    23. Re:Devs can now be more lazy by phantomfive · · Score: 1

      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.

      --
      "First they came for the slanderers and i said nothing."
    24. Re:Devs can now be more lazy by dkf · · Score: 1

      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 the programmer to do something (GC is the fully automated approach, and that releases late). In Java up to 6, that operation was typically an explicit close() method call, and while the language did provide a try/finally construct to help with it (itself a big advance over older languages like C) it was still rather verbose. The technique of binding lifetime to a syntactic scope came later (well, it was earlier in Lisp but too many people forget to raid that treasure trove of techniques) and has now been adopted in Java 7. It was around earlier in C#, but in many ways Java is a very conservative language — it simply does not change quickly (and that's mostly a good thing; a platform that is changing rapidly is not a great thing to build production code on). In many ways it's just syntactic sugar as it does not add any fundamental capability to the language, but it makes it enormously easier to write correct and efficient code. (The new-style for loops in Java 5 were another example of this tendency.)

      Improving the ability of programmers to write correct and efficient code is indeed an advance.

      --
      "Little does he know, but there is no 'I' in 'Idiot'!"
    25. Re:Devs can now be more lazy by nzac · · Score: 1

      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 this is easier is if you happy for java chose what to do in this case.

      Dawn of time is right i don’t know shit about java but still missed my point (yes everything past the first sentence is shit invented on this spot when i look back on it, i could justify some of it but not the important parts). Is intrenching GC concepts in modern programming a clear advancement that most future languages will use? I thought it was clear my comments came from the language used in the article.

    26. Re:Devs can now be more lazy by silentcoder · · Score: 1

      > You should learn to lurk more and talk less.

      Dude, this is /. not 4chan...

      --
      Unicode killed the ASCII-art *
    27. Re:Devs can now be more lazy by silentcoder · · Score: 1

      >Generally, it doesn't turn programmers into simpletons

      Nope COBOL took care of that decades ago...

      --
      Unicode killed the ASCII-art *
    28. Re:Devs can now be more lazy by silentcoder · · Score: 1

      I must commend you good sir, for the most convoluted and twisted slashdot car analogy I have ever read. That is one hell of a high bar.

      --
      Unicode killed the ASCII-art *
    29. Re:Devs can now be more lazy by silentcoder · · Score: 1

      According to XKCD real men hold their hard drives in the air and wait for cosmic raise to randomly magnetize the right bits for the program they wanted to write (which chaos theory says must happen if you hold it long enough).

      Also - there's an emacs command for that...

      --
      Unicode killed the ASCII-art *
    30. Re:Devs can now be more lazy by ggeens · · Score: 1

      So exact what problem do GC solve?

      Manual memory management is tedious and error-prone. You need to add your destructor calls in all the right places, taking into account all possible program flows. Any mistake results in a memory leak or a crash.

      It is not hard to deallocate what you have allocated.

      Not if you have shared objects.

      And yes, I am a Java developer since 10 years.

      And you still don't understand the environment you're working on? That's sad.

      --
      WWTTD?
    31. Re:Devs can now be more lazy by maxume · · Score: 1

      ecode gives you arbitrary indentation:

      blah
          blah
              blah

      code also falls through the filters:

      blah
          blah
              blah

      (this is with the tags dropped into "Plain Old Text", not sure what the other formatting options would do)

      --
      Nerd rage is the funniest rage.
    32. Re:Devs can now be more lazy by tigersha · · Score: 1

      cat > a.out

      --
      The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
    33. Re:Devs can now be more lazy by EdgeCreeper · · Score: 1

      HTML Formatted with ecode does not give you indentation, and elements will not help either. Plain old text mode with ecode does give indentation. This has saved some time. Thank you.

    34. Re:Devs can now be more lazy by Bill_the_Engineer · · Score: 1

      Sure its fine if you don't need it to be faster than python (or pypy) but changes like these (yes you could pretended they don't exist and then it may not matter) were to accumulate it could hurt the language rather than make it better.

      Java 7 is significantly faster than Python 3, so I don't know where you are getting your information.

      Assuming that Java programs do run (insignificantly) slower, it makes C++ and its dev's all that more important.

      If speed is really an issue then I would write those portions in C. Anyway I have many lines of C++ code floating around in a lot of embedded systems, and I haven't been harmed while programming in Java (or any other language).

      If portability was important and I could take a slight hit in speed, then I would choose Java.

      If speed was important and resources are low then I would choose C.

      If speed was important and there's a need for OO to manage the complexity then I would chose C++.

      If "glue" code needed to be created and speed was not being considered then I would pick Perl, Python, or Ruby (Perl is the language most used for this).

      If I needed to make a dynamic website and I wanted to use a web framework to keep my workload manageable I would pick Python or Ruby.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    35. Re:Devs can now be more lazy by Bill_the_Engineer · · Score: 1

      Real men program directly in binary and enter the code with toggle switches.

      I know what you mean. I fell for the columnated paper to write out the fortran 77 code years ago, and after being stuck with all those pads I decided to wait and see how long the text editor fad lasts. ;)

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    36. Re:Devs can now be more lazy by cowdung · · Score: 1

      So exact what problem do GC solve?

      It makes mem management less error prone. Also in some cases it can reduce the memory management overhead and make your app have a higher throughput rate!

      It is not hard to deallocate what you have allocated.

      It is not hard to write a program in Assembly either. However high level languages give you convienences to help reduce your bug rate.

      That is what the destructor method on objects normally are used for.

      Destructors are like finalizers (except deterministic). The big problem with destructors is that they make object deallocation SLOWER so you can't get the higher throughput I mentioned above because you have to process all your garbage. A copy collector doesn't have to deal with your garbage it simply ceases to exist.

      Now, Java removed the destructor method. Why? What this good language design? And yes, I am a Java developer since 10 years.

      I had that question 13 years ago. I have since discovered the answer to it. I don't believe you're a real Java developer if you don't understand this.
      I liked destructors, but finally + efficient memory deallocation is something worth losing destructors for.

    37. Re:Devs can now be more lazy by Unequivocal · · Score: 1

      You've just effectively summed up and answered about a decade (or more?!) of slashdot comment-chatter. Not that I expect this to change anything, but +1 from me. :)

    38. Re:Devs can now be more lazy by Bucky24 · · Score: 1

      You need to add your destructor calls in all the right places, taking into account all possible program flows. Any mistake results in a memory leak or a crash.

      Personally I think this causes people to write better code, forces programmers to think ahead when they are developing, to avoid those problems, and in general improves the skill of the programmer.

      Is that a bad thing?

      --
      All the world's a CPU, and all the men and women merely AI agents
    39. Re:Devs can now be more lazy by Bucky24 · · Score: 1

      You're using the java api, certainly, but that makes you a developer, not a user. Just like the architect is using the laws of physics to design a door, but that doesn't make them an end-user. It makes them an architect. (yes it's a weak analogy I know but it's the best I could come up with)

      --
      All the world's a CPU, and all the men and women merely AI agents
    40. Re:Devs can now be more lazy by sjames · · Score: 1

      There is only one true text editor!

    41. Re:Devs can now be more lazy by NoOneInParticular · · Score: 1

      Ah well, after using java for a decade or so, I still go back to C++ now and then to feel a breadth of fresh air. Code where you actually don't pay for what you don't use; no per object overhead when you don't need it; no garbage collector that needs to be tuned independently from the program; no runtime environment + jit that optimizes away the errors of newbies, not the needs of the proficient. No magic, just a program that you can understand.

    42. Re:Devs can now be more lazy by jgrahn · · Score: 1

      Likewise, GC has been a favorite subject of C++. Should we have GC in the core of C++ or not? There is always a third party library that can add GC to your C++ project. Does using that library make you a bad coder?

      Yes, if you use it for things where C++ has better mechanisms, i.e. most of the cases.

      ... As a rough example: I open a file in Java or C++, I still have to think about how that file will be used and when I need to close it (no other option in C++) or just let it close by itself (an option in Java but not usually the best one.)

      Have you ever done any C++ programming? Does RAII ring a bell? A file gets closed when its object goes out of scope. (Of course no matter what the language, if you've written to the file it's usually prudent to check it for I/O errors at closing time.)

    43. Re:Devs can now be more lazy by tsotha · · Score: 1

      I still go back to C++ now and then to feel a breadth of fresh air.

      Well, okay, I suppose, as long as you don't have to maintain other peoples' code. I spent years chasing intermittent memory bugs in C++, and I'll be forever grateful to the java designers for freeing me from that task. About six months ago in a C++ project at my company someone found, by accident, one such bug. They'd been looking for it for more than a decade, finally giving up and writing a bunch of code to detect when it occurred and clean up the mess. I've never seen that in a java project, even one with junior and/or incompetent programmers.

    44. Re:Devs can now be more lazy by NoOneInParticular · · Score: 1

      Ah okay. Yes ... maintaining other people's C++ code. Especially that of someone who just figured out how static variables could work together with operator overloading and templates. Shudder. You're right, Java is a godsend for that. I've seen some pretty brutal Java code too, but if you can't toss it, you can usually wrap it and hope it would not make too much of a mess later on. Uncontrolled C++ is a whole different beast. Don't let amateurs code, but.... no choice.

    45. Re:Devs can now be more lazy by slack_justyb · · Score: 1

      Have you ever done any C++ programming? Does RAII ring a bell?

      That's almost offensive. You use close in the destructor you idiot. Yes I know what RAII is since I made an example of its usage in the part of my comment that you did not quote, ye of limited sight and even shorter span of memory.

      Yes, if you use it for things where C++ has better mechanisms, i.e. most of the cases.

      Obviously that is that limited sight thing. Yes standard is good, but I would dare say not *most* of the cases. Boost comes to mind. However I doubt that to actually sink into your head based off of what you have thus far said. No matter if I wasted another five to six hundred words making my case. If you want to be arrogant that is fine. However, I have programmed sixteen years in C++, so please do me a favor and if you don't know me, don't try to comment on me or at least expect the same poor assumptions to be tossed in your direction, as I have done so in this reply.

      Finally do your self a favor and get out whatever pent up aggression you may have here on this thread, since I have little time to reply back to an absolute single minded bigot such as yourself. I would hate for your vile language to be wasted on a thread that someone may actually reply back to.

  7. I think I speak for many when I say... by mattcsn · · Score: 1

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

    1. Re:I think I speak for many when I say... by DeeEff · · Score: 1

      Why'd you post as an AC? I think "looking beneath the surface" is what programming is all about, and what they're doing here with Java 7 is just silly.

      Geez, catering to "young programmers" seems silly. If they don't learn it properly while they're young, it'll only get harder to learn once you get older.

  8. 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.

  9. Re:Kill it Oracle by Afforess · · Score: 2, Insightful

    Let me get this straight - you think that a harder programming language increases programmer competence. While I'm not defending Java, this logic is deeply flawed.

    If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

    --
    If our elected representatives no longer represent us, do we still live in a Democracy?
  10. Re:all i do by iggymanz · · Score: 2

    Well since JDK downloaded, ant XML in my head,

    jars, wars, and .class files all night with laptop by my bed,

    well java you look so fine (look so fine)

    for C++ errors took all my time,

    for you to help me java

    get Stroustrup outta my heart.

    help me java, help help me java

    help me java, help help me java
    .........

    help me java, yeah, get him outta my heart.

    Bjarne was gonna be my god,

    and we gonna be his bitches,

    preprocessor bloat came between us,

    patterns ruined by the glitches

  11. Compatible with Andriod SDK by Billly+Gates · · Score: 1

    How compatible is Java 7 with Java 6? Can I run the Andriod emulators? Is it more secure than java 6? I would like to use Chrome but it always runs Java by default and I got owned a month ago from this exploit. I hate using IE as it is the only browser I can disable Java from

    --
    http://saveie6.com/
    1. Re:Compatible with Andriod SDK by vawwyakr · · Score: 1

      You can install the notscripts add-on in chrome and then you can selectively enable JS based on the source.

    2. Re:Compatible with Andriod SDK by Bucky24 · · Score: 1

      Java != JS

      --
      All the world's a CPU, and all the men and women merely AI agents
  12. Re:Kill it Oracle by Rik+Rohl · · Score: 3, Funny

    Obligatory xkcd

  13. Re:Kill it Oracle by AliasMarlowe · · Score: 2

    If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

    Correct: the best programmers can use machine code if needed. But the best programmers also don't abuse the apostrophe as much as you did...

    --
    Those who can make you believe absurdities can make you commit atrocities. - Voltaire
  14. What's in It for Developers? by microphage · · Score: 1

    Well going by previous statements by Larry Ellison and Oracles actions in regards to Red Hat Linux. They'll wait until your stuff is popular and then just take it and start charging support fees for your stuff.

    "If an open source product gets good enough, we'll simply take it" link

    1. Re:What's in It for Developers? by Lennie · · Score: 1

      That was one of the questions I wanted to ask. So how open (source) is it now ?

      I just know OpenJDK exists, I even know where to download it:
      http://download.java.net/openjdk/jdk7/

      --
      New things are always on the horizon
  15. 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.

  16. Do these developers include Android developers? by bogaboga · · Score: 1

    "...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?

    1. Re:Do these developers include Android developers? by renrutal · · Score: 1

      Since current Java SE code isn't expected to run and have the very same behavior in Android without modification in previous versions, I don't think it the current version would be any different. BTW, are Android developers considered to be Java developers by Oracle?

    2. Re:Do these developers include Android developers? by angel'o'sphere · · Score: 1

      After all, Java code will run on Android's Dalvik VM without modification, right?

      What do you mean with Code in this case? Sourcecode? Or bytecode? The JVM bytecode won't run on a Dalvik VM. As the compilation way for Android is to create ordinary bytecode classfiles and cross tranlate those bytecode files then into Dalvik VM bytecode files, I assume you can use any "language" and only the libraries are an issue.

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  17. Re:One day we will be done with java... by Anonymous Coward · · Score: 1

    Ruby showed the value of this technique as well. The Java haters live in ignorance. Java is frequently used to solve difficult integration problems that require the use of diverse resources; database sessions, networks connections, file system resources, etc. Simplifying the code necessary to do this while reducing the chances for leaks is a genuine improvement.

  18. Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 by Kensai7 · · Score: 1

    It won't be jilted in Windows 8. Why you people keep perpetuating this myth? Just because C++ is making a comeback (it was about time) and JavaScript/HTML5 is finding a new home, doesn't mean that we throw away .NET Framework 4.5.

    --
    "Sum Ergo Cogito"
  19. Meh. by jlarocco · · Score: 1

    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.

    --
    Maybe not
    1. Re:Meh. by RightSaidFred99 · · Score: 1

      Python is still a scripting language and has all the baggage that comes along with such for larger programs. Let me guess - you come from a system admin background?

    2. Re:Meh. by mario_grgic · · Score: 1

      Python is a nice language, but I'm not sure how it scales to tens of millions of lines of code? Java with its mature tools scales really well. It's not hard to maintain and add new features.

      So, yes, if your project is small and runtime speed is not an issue develop in Python/Ruby or what ever. But if you hit critical code base size, scaling further might not be as easy. Also, tool support for dynamic languages can never be as good as for statically typed ones with reflection like Java or C#.

      --
      As the island of our knowledge grows, so does the shore of our ignorance.
    3. Re:Meh. by slim · · Score: 1

      Python is a nice language, but I'm not sure how it scales to tens of millions of lines of code? Java with its mature tools scales really well. It's not hard to maintain and add new features.

      This would make more sense if you could mention some features of Java, pertaining to large codebases, that Python doesn't have.

      It seems to me that whether you're using Java or Python, or anything else with a module mechanism, you write modules of a manageable size, and have them import one another.

    4. Re:Meh. by jgrahn · · Score: 1

      Python is a nice language, but I'm not sure how it scales to tens of millions of lines of code? Java with its mature tools scales really well. It's not hard to maintain and add new features.

      This would make more sense if you could mention some features of Java, pertaining to large codebases, that Python doesn't have.

      He did, in the part you didn't quote: static typing. I really like the way Python handles this for small programs, but for anything a bit larger I really want a compiler, not myself, to do the static checking.

    5. Re:Meh. by slim · · Score: 1

      I really don't believe that static typing is something that helps you with large programs.

      I certainly see the value of strong static typing for certain jobs, but plumbing modules together into a large system isn't it.

      Indeed, I like static typing for little fiddly components, and something more dynamic for the broad brush strokes.

      For example, I recently put wrote an application in Groovy. I believe Groovy saved me days of work, and oodles of bugs, compared to writing it in Java. But, one core part required some encryption and some bit twiddling. Having the compiler help me with those fiddly bits was useful.

  20. Re:Kill it Oracle by Afforess · · Score: 2

    If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

    Correct: the best programmers can use machine code if needed. But the best programmers also don't abuse the apostrophe as much as you did...

    If I found out someone was manipulating code at the machine level - I'd definitely have issues with that. You lose portability and expose yourself to a nearly infinite amount of issues - there really aren't many cases left where this would even be remotely advisable.

    PS. Nitpicking grammar - that's nearly as bad as using machine code directly. :p

    --
    If our elected representatives no longer represent us, do we still live in a Democracy?
  21. Here's a reason why it is not on http://java.com. by antdude · · Score: 1

    http://www.java.com/en/download/faq/java7.xml -- "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 interested in trying Java SE 7 it can be downloaded from Oracle.com..."

    It sounds like even Oracle, itself, doesn't think Java 7 is ready for the public!

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  22. Re:Kill it Oracle by Lord+Kano · · Score: 1

    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.

    I can't speak for other workplaces, but there are certain languages that people at my company develop in and you can get a pretty good idea of a programmer's skill level by what language he develops in. Anyone who develops in only one language is very good at that language. S/He can solve any problem you throw at him/her in that one language. There's nothing wrong with that per se, but demand is not constant. Sometimes, they need more people in a different department. If you are a one language programmer, you have very good odds of being let go when that happens. If you are competent in many, you can go far.

    The hands down best programmer I ever worked with could code in anything from FORTRAN 77 through .NET and his code was always amazing. But, that's one out of hundreds.

    LK

    --
    "Hi. This is my friend, Jack Shit, and you don't know him." - Lord Kano
  23. 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 MischaNix · · Score: 1

      I know better than to dare read the actual articles nowadays. It's never anything but disappointment.

    2. 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.

    3. Re:Riddled with errors by moonbender · · Score: 1

      That only works for finals.

      JLS 8.1.3: "Any local variable, formal method parameter or exception handler parameter used but not declared in an inner class must be declared final. Any local variable, used but not declared in an inner class must be definitely assigned before the body of the inner class."
        (source w/ discussion)

      --
      Switch back to Slashdot's D1 system.
    4. Re:Riddled with errors by kervin · · Score: 1

      Somehow, in the Java community, closures somehow became connected to lambda expressions.

      Because Java's lambda expression feature is a closure....?

      It didn't have to be implemented that way, but it is. So using Lambdas and closures as the same thing in conversation makes sense for Java ( and C# ).

    5. Re:Riddled with errors by sproketboy · · Score: 1

      So?

    6. Re:Riddled with errors by benjymouse · · Score: 1

      So using Lambdas and closures as the same thing in conversation makes sense for Java ( and C# ).

      Speaking of C#, no, lambdas and closures are definitively *not* the same thing. A C# lambda may be a closure (if it captures any variables from the lexical scope), it may be just a function (if it doesn't close over any variables), or it may be an expression tree which is totally not a closure at all.

      Likewise, a closure need not be created through a lambda expression, an anonymous method may also be a closure.

      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    7. Re:Riddled with errors by Just+Some+Guy · · Score: 1

      Is Python common enough for you? It supports named functions as closures, not just lambda expressions.

      --
      Dewey, what part of this looks like authorities should be involved?
    8. Re:Riddled with errors by shutdown+-p+now · · Score: 1

      A closure is supposed to close over local variable bindings, not values of said bindings. This distinction is irrelevant in a language like Haskell where bindings bind directly to values, but it makes all the difference in e.g. Scheme or Java, where bindings bind to mutable locations.

    9. Re:Riddled with errors by shutdown+-p+now · · Score: 1

      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.

      The reason for the mix-up is because lambdas are most useful when they can also be closures; and, conversely, closures are most useful when they can be defined inline. It just works better with most common patterns where they are used (e.g. task continuations).

      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.

      It's not as bad as it sounds. You don't need to make all locals more expensive, but only those which are closed over (and even then only if you can't statically prove that local is not mutated after the closure is created) - which, in a language with lexical scoping, is trivially determined in advance. So you wouldn't incur any overhead for a variable unless that overhead is made necessary by the fact that it's closed over.

  24. Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 by Anonymous Coward · · Score: 1

    You need serious attention of a psychotherapist. Hurry!

  25. Re:"Java 7: What's In It For Developers" by mrmeval · · Score: 1

    Can we get it reviewed by someone who isn't a fanboi and butt licker?

    --
    I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
  26. Re:Here's a reason why it is not on http://java.co by MischaNix · · Score: 1

    I believe this is actually because the JVM for 7 hasn't made it to the Mac yet.

  27. Re:Kill it Oracle by AliasMarlowe · · Score: 1

    If you follow it to it's logical conclusion, the best programmer's flip the machine bits by hand...

    Correct: the best programmers can use machine code if needed. But the best programmers also don't abuse the apostrophe as much as you did...

    If I found out someone was manipulating code at the machine level - I'd definitely have issues with that. You lose portability and expose yourself to a nearly infinite amount of issues - there really aren't many cases left where this would even be remotely advisable.

    Well, that's why I emphasized the "if needed" bit. I suspect that cases where a real need for machine code might arise are probably limited to embedded systems and other single-architecture real-time applications, where a complete re-write (from specs) would be needed for a change in architecture.

    PS. Nitpicking grammar - that's nearly as bad as using machine code directly. :p

    Hmm... now was I picking at a grammar nit or a spelling nit? Or were you suggesting that grammar related to a disgusting activity is nearly equivalent to direct use of machine laguage?

    --
    Those who can make you believe absurdities can make you commit atrocities. - Voltaire
  28. Re:What Java really needs by Homburg · · Score: 1

    1. C#'s 'using' block so I don't have to use try/finally everywhere.

    That's in Java 7, in the form of the try-with-resources statement.

  29. Re:A language with a file system? by Joce640k · · Score: 1

    Why are you both confused/assuming? Too busy to read the article?

    --
    No sig today...
  30. Re:Kill it Oracle by mywhitewolf · · Score: 1

    there is a difference between understanding how the computer does what it does (and a logical extension of that is knowing how to change it should that be required), and actually attempting to do something via machine code. but you're right, modern day programming is a different beast than old school logic gate manipulation.

  31. Re:Improvements by Joce640k · · Score: 1

    Arguments for slow Java are so 1990's.

    Nope, still as relevant as ever. Java simply doesn't scale. Try running your microbenchmarks with a million objects in memory...

    --
    No sig today...
  32. Re:A language with a file system? by mywhitewolf · · Score: 1

    It's really not that obvious in the summary.

  33. 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.

  34. Re:Poor Ol' .NET Dev--A Pity Party Next To Java 7 by slack_justyb · · Score: 1

    I am not sure why people keep saying this even in the light that Microsoft has said that they are bringing .NET even closer to the core API here.

    HTML 5/JS is just being added onto what is already there. The fact that no one has heard about Silverlight has made everyone worried. Microsoft has talked about Silverlight just not to the degree that everyone had hope for. So since no one likes waiting until September, we'll just spread rumors and make Microsoft pay for suddenly wanting to do things like Apple and keep quiet.

  35. Re:Here's a reason why it is not on http://java.co by Lisandro · · Score: 2

    It sounds like even Oracle, itself, doesn't think Java 7 is ready for the public!

    And they are right indeed...

  36. Re:A language with a file system? by NotBorg · · Score: 2

    Thats why the summary links to an article. You must be new here.... oh wait... You'll fit in great here. Carry on.

    --
    I want this account deleted.
  37. Re:Here's a reason why it is not on http://java.co by antdude · · Score: 1

    If it is that bad, then don't release it!

    Did update #1 even fix it?

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  38. Re:Here's a reason why it is not on http://java.co by Lisandro · · Score: 1

    AFAIK it is planned to be fixed on update 2. Which is kinda retarded - even for Oracle standards.

  39. Re:Java is Great by Anonymous Coward · · Score: 1

    You forgot "once upon a time" and "they all lived happily ever after."

  40. Re:"Java 7: What's In It For Developers" by phantomfive · · Score: 1

    Yeah. Basically it's this:

    There were a number of proposals for how to improve Java. Some of them were controversial. The controversial ones got moved out to Java 8, and the ones that everyone agreed on made it in to Java 7.

    In essence, this is a good, solid, incremental update.

    My idea of a perfect programming language is somewhat different, but I can respect this as a solid improvement.

    --
    "First they came for the slanderers and i said nothing."
  41. Re:One day we will be done with java... by Anonymous Coward · · Score: 1

    So, it's basically like C++'s ancient RAII...

    You know what? Bjarne Stroustrup was right: The more useful Java becomes, the more it approaches what C++ already provides.

  42. Re:Here's a reason why it is not on http://java.co by antdude · · Score: 1

    Wow, that is seriously messed up if it is true. I will stick with the older stable version (v6u27) that just got an update last week. ;)

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  43. Re:Improvements by slack_justyb · · Score: 1

    Java simply doesn't scale. Try running your microbenchmarks with a million objects in memory...

    That sounds like EE development and not SE development. If that is the case:
    That sounds like a problem with the design. Try using more lock free structures, you can use the java.util.concurrent package to find tools that will help you build these easier in Java 5 and better.

    If your are indeed talking SE development, why is your desktop application using millions of objects in memory? I do not think it is wise to juggle that many objects in any desktop platform. Usually, and this is just me, I flush objects out of memory and to disk, network host, database file, or something other than memory once I hit over more than I could keep in my head. Pagination designs help smooth this out for users and using task workers keeps everything moving smoothly. For the curious the pagination design pattern in Java SE looks exactly the same using the QT toolkit (if you use that toolkit.)

    I don't know your situation and I won't pretend that I do, but in most cases I find it is the developer just assumed Java would do this or they are still following an old convention that doesn't work well with today's JVM. Either way, EE or SE, if you are dealing with millions of objects in memory, there are ways of moving that data around to keep space on the stack for responsiveness in your application. Just having a million objects in memory just because is not a good idea.

    Just curious what use case do you have that requires you to have that many objects in system memory at once? Are we talking simple objects or pretty complex ones?

  44. Re:Improvements by slack_justyb · · Score: 1

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

    Um, no, it is not. There really isn't much to debate here. This is like debating if JIT is the same thing as a compiler.

  45. Re:Improvements by Lisandro · · Score: 1

    Bytecode IS interpreted (by the JVM), sorry. Jazelle was the only attempt of a hardware JVM implementation that i know of and even that was short lived.

  46. Re:Kill it Oracle by GigaplexNZ · · Score: 1

    Lolcode sucks, it just sucks in a fun way :/

  47. Re:Improvements by SomeStupidNickName12 · · Score: 1

    Haha, if java doesn't scale why is it the defact standard for any large enterprise?

    Probably not the best language to write a ray tracer or an on the fly 3D engine but the stuff I seen java do is pretty impressive. Go take a look at throughput of something like Websphere MQ.

  48. Re:Improvements by slack_justyb · · Score: 1

    Let's look at the fundamental differences here:

    Interpreted code does the following: Bytecode is loaded by a native program into an Interpreter. The Interpreter reads the code and sends native code to the machine or to another piece of software that can do such.

    JIT code does the following: Bytecode is loaded by a native program into a compiler. The bytecode is compiled into native code. The native code is sent to the machine.

    The difference is the following, the bytecode in JIT eventually becomes the native code. Interpreted bytecode never makes it as native code. Both can be optimized by saving the bits of machine code that get generated, however JIT usually means that the native code follows closely what the original bytecode looked like. Interpreted usually has to make assumptions on how execution should happen and in what order.

  49. Re:A language with a file system? by wvmarle · · Score: 1

    I hope this means they will have basic functions like copy built-in. I was quite surprised when I took up Java on Android that such a function was simply not there. And that I basically had to add it myself (luckily code snippets all over the place, but still). The whole I/O felt very primitive to me - it may have its advantages to do it that way, but me coming from Python is used to being able to address files much easier.

  50. Re:Improvements by bertok · · Score: 1

    The problem with Java is that the startup time is poor, which is often ignored by benchmarks.

    First, for an apples-to-apples comparison, this is the startup of a typical installed .NET app:

    * Operating system loads the cached, fully compiled EXE or DLL.
    * Operating system loads the cached, fully compiled System library DLLs.

    If the app is not cacheable (not signed, not properly installed, or whatever), then the process is almost the same, except that the first step changes to "Operating system loads the bytecode, and compiles it one method at a time on demand and runs it". All of the system libraries are always fully pre-compiled. No code ever runs in an interpreter.

    Compare to Java:

    * Decompress Application JAR files (this is a ZIP file internally) -- this is slow. At best, you get 30MB/sec for typical compression ratios.
    * Decompress Java system JAR files -- this is also slow, and there's a lot of it to load. At this point, anyone without an SSD gets to twiddle their thumbs while the disk makes crunching sounds for a while.
    * Start running application (including the system libraries) using an interpreter -- this is several times slower than compiler code.
    * At some point, some of the code (usually not all of it) is compiled -- now your app is probably fast.

    Even for server apps, this is bad. I've seen a large J2EE app thrash a server (100% CPU!) for tens of minutes before it settled down. Compare that to, say, ASP.NET, which if precompiled can launch in a few hundred milliseconds!

    Sure, in long running benchmarks, Java is faster, but the user experience is less than stellar.

    There's no good reason for this. Oracle could use a container format that's uncompressed by default, pre-compile, cache, etc... but they don't. I know there's third-party JVMs that do that kind of thing, but the majority of users stick to the "official" JVM.

    There's also still this attitude of having "User" vs "Server" JVMs, as if people still had single-core PCs. My laptop has 8 logical 64-bit CPUs!

  51. Re:Improvements by slack_justyb · · Score: 1

    n my experience most of Java's performance improvements have had more to do with advances in hardware.

    I can tell you that all compilers have advanced in step with hardware improvements. Also, I have easily ran Tomcat 6 and Linux on a Dell OptiPlex GX300. Trust me I have tons of 90's hardware that I am required to make work and enjoy hacking on. I still change DIP switches on ISA cards at my work place.

  52. Re:Improvements by Lisandro · · Score: 1

    The difference is in the how. JIT gives huge improvements in stuff like loops and basic constructs because these are easily translated into machine code. But for Java bytecodes dealing with OOP constructs (new, for example) this basically means that the JIT has to embed a lot of machine code as an abstraction layer. The improvements there are minimal because this code is doing pretty much the same the JVM would do processing that bytecode on the fly.

    Making a very loose comparison, i could easily bundle a JVM implementation and Java bytecode into an .EXE and call that "compiling". In fact, there's software that does exactly this. Quick Basic did it too back in the DOS days.

    JIT is great, but it is not a compiling by any stretch. Is a hybrid approach that works pretty well, but every time you fire up your Java code the JVM will process it for you, interpret it and translate it, when possible, to native machine code on the fly. In fact, for big files this process can add a significant start up time penalty.

  53. Re:Improvements by m50d · · Score: 1

    What are the prominent desktop applications written in Java? I'd say Azureus, Eclipse, and OpenOffice (and personally I'm using JDownloader, but that's a bit obscure) - all of which are dog slow (heck, every one needs a splash screen when starting). So you can't really blame people, for whom these applications are their only experience of Java, for perceiving Java as slow.

    --
    I am trolling
  54. Re:Improvements by phantomfive · · Score: 1

    Once Java is launched, you are right. I have a Java program I use on a regular basis, and it is a fine program, which is why I use it, but I hate to launch that thing because it takes forever. Makes me want to rewrite it.

    My biggest problem with Java isn't the language, which I have grown to respect, it's the Java programmers. They think they are using Java so they don't have to worry about memory, that things can't leak. No, you still can stick an object in a queue and forget about it. Or register a Swing listener and need to clean it up. If you aren't thinking about the lifecycle of resources, even in the back of your mind, you're probably leaking them all over the place.

    --
    "First they came for the slanderers and i said nothing."
  55. Re:Improvements by Post-O-Matron · · Score: 1

    Java simply doesn't scale. Try running your microbenchmarks with a million objects in memory...

    Can you give an example of a managed, cross-platform, enterprise language for which the above statement is incorrect?

  56. No Thanks! by Greyfox · · Score: 1, Funny
    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 kilobytes is freaking awesome. Having real system level control over your hardware, awesome. As long as you're not seduced by template fuckery (You know who you are, "lets factor prime numbers at compile time" template people!) or dynamic link libraries, it's a fine language!

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:No Thanks! by Mr+Thinly+Sliced · · Score: 1

      As long as you're not seduced by template fuckery (You know who you are, "lets factor prime numbers at compile time" template people!) or dynamic link libraries, it's a fine language!

      I agreed with you until you discourage dynamic link libraries.

      I'm someone currently making the move back to C++ from Java (reason - predictable scheduling) after 10 years in the J jungle. If you don't have dynamic libraries how would you do plugins? (Never mind that dynamic libraries are necessary for anything larger that a simple standalone application.)

      Admittedly the tooling for building is still messy (autotools work, sure, but are a pain to have to deal with).

      As an aside, the new c++0x features have really changed C++ from the "new" "delete" fiasco I remember from 1995. STL plus boost makes C++ rather natural and use of threads is pleasant after I previously had to jive with pthreads.

    2. Re:No Thanks! by SplashMyBandit · · Score: 1

      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).

    3. Re:No Thanks! by devent · · Score: 1

      Yeah, destructors in which you cannot throw an exception. I'm living in Europe and using OpenJDK, so Oracle can blow me, too. In addition, can you explain why a 20 kbytes executable is "awesome"? I have 4GB of RAM, I really don't care how much an application is using as long as it can do the job.

      Furthermore, you don't want to use templates and dynamic linking? So no STL and boost, and no other libraries at all, because you want your executable be 20 kbytes.

      I think Google already re-implemented all the shit in C++ anyway, how do you think they can write the DalvikVM? Plus, software patents are not tied to a particular implementation or language. So even if Google would implement Android in their Go language, Oracle can still sue them.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    4. Re:No Thanks! by shutdown+-p+now · · Score: 1

      Yeah, destructors in which you cannot throw an exception.

      You can if you want to. You can even catch that.

      It's just that it's almost never a good idea - what, exactly, do you expect the compiler to do when a destructor is automatically executed during stack unwinding because of some existing exception, and throws another one? silently override it, like Java does for return values with return-inside-finally?

    5. Re:No Thanks! by devent · · Score: 1

      I never understood the need for a destructor. For 99% the GC is just fine and for other resources besides memory I have a close method. If you really need a custom memory management, then you can hack the OpenJDK.

      http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9
      "[17.9] How can I handle a destructor that fails?
      Write a message to a log-file. Or call Aunt Tilda. But do not throw an exception! "

      So RAII is completely useless for any kind of resources. That's why I also don't understand the hype about RAII.

      From Wikipedia:

      ~file() {
                      if (std::fclose(file_)) { // failed to flush latest changes. // handle it
                      }
              }

      void example_usage() {
              file logfile("logfile.txt"); // open file (acquire resource)
              logfile.write("hello logfile!"); // continue using logfile ... // throw exceptions or return without // worrying about closing the log; // it is closed automatically when // logfile goes out of scope
      }

      And what if the std::fclose method of the log throws an exception? Where should I log that? In the worst case nothing is flushed to the file and the log is empty. The exception is not logged so you can spend hours to find your bug. That is true for all other kinds of resources, be it sockets, pipes, etc.

      "Using RAII-enabled resources simplifies and reduces overall code size and helps ensure program correctness."

      Except where the methods in the destructor throwing an exception in this case almost all developers just ignore it, how is that to "ensure program correctness".

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    6. Re:No Thanks! by shutdown+-p+now · · Score: 1

      I never understood the need for a destructor. For 99% the GC is just fine and for other resources besides memory I have a close method.

      close() method is not the antithesis of RAII. The point of RAII is that close() method should be called automatically inasmuch as possible, by having well-defined object lifetimes and object ownership relations.

      And what if the std::fclose method of the log throws an exception?

      fclose() cannot throw an exception, because it is a C function. It can fail otherwise, by returning an error code. But, what, exactly, do you propose to be done then? Not being able to clean up the resource is, frankly, a design bug for that resource. Handling an error properly normally requires tearing down resources - if that can also fail, then you're in a situation where you plainly can't proceed, since you can't clean up to move on to other stuff.

      This is by no means unique to RAII, but is a general problem with resource management. In Java 6, suppose you have a try-finally, and you call close() explicitly in finally - And that throws. What do you intend to do in that case, considering that there may still be a pending exception thrown from try? You can either suppress the one from close(), or let it override the one from try. You are arguing that the first is bad because it loses an exception; but so does the second, and it loses a far more important one!

      Java 7 try-with-resource blocks chain exceptions in that case. That's a nifty trick, but isn't 100% foolproof. On the other hand, it does show that RAII itself is fine (since try-with-resource is RAII).

      Where should I log that? In the worst case nothing is flushed to the file and the log is empty. The exception is not logged so you can spend hours to find your bug.

      If things are so bad that you can't even log exceptions, your best bet is to terminate the process immediately and loudly (e.g. by throwing that exception after all). Of course, there are also asserts etc.

      So RAII is completely useless for any kind of resources.

      Really? Do you often have failures while releasing resources? How come that numerous C++ programs (to remind, still the vast majority of desktop apps are that) use the "useless" RAII heavily to manage all resouces?

    7. Re:No Thanks! by devent · · Score: 1

      "This is by no means unique to RAII, but is a general problem with resource management. In Java 6, suppose you have a try-finally, and you call close() explicitly in finally - And that throws. What do you intend to do in that case, considering that there may still be a pending exception thrown from try? You can either suppress the one from close(), or let it override the one from try. You are arguing that the first is bad because it loses an exception; but so does the second, and it loses a far more important one!"

      In Java it's very easy (and in C++ if not using the RAII). You just re-throw the exception to a higher level, maybe up to the View layer and show the exception to the user in a nice error dialog. With RAII that is not possible, because the destructor cannot throw an exception. So either you call a method to the outside in the destructor, or you just ignore the exception.

      try-with-resource is not like RAII, because there the close() method of the AutoClosable/Closeable interface is called, which can throw an exception. The exception can be then retrieved and logged/presented to the user.

      That is the nature of resources, they can fail at any time and with all resources you can recover from it in a graceful way. Except of course for memory resources, that is why RAII is only useful for memory, but in Java I have the GC.

      "Really? Do you often have failures while releasing resources? How come that numerous C++ programs (to remind, still the vast majority of desktop apps are that) use the "useless" RAII heavily to manage all resouces?"

      That is my personal opinion about destructors and RAII in C++. Of course you can use it, like you can use templates to calculate the fibonaci numbers at compiler time. But my personal opinion is that mixing memory management and resources management (what RAII is all about) is just stupid because of the fact that you cannot throw an exception from the destructor.

      --
      http://www.mueller-public.de - My site http://www.anr-institute.com/ - Advanced Natural Research Institute
    8. Re:No Thanks! by shutdown+-p+now · · Score: 1

      In Java it's very easy (and in C++ if not using the RAII). You just re-throw the exception to a higher level, maybe up to the View layer and show the exception to the user in a nice error dialog.

      This does not answer the question. If your close() throws while the stack was unwinding, you have two exceptions - one that caused the stack to unwind and your finally-block to execute, and the other that was thrown by close(). Which one do you choose to report?

      With RAII that is not possible, because the destructor cannot throw an exception. So either you call a method to the outside in the destructor, or you just ignore the exception.

      As noted several times already, this is plainly false, and you can throw exceptions from destructors to your hearts content, catch them, and report them. The reason why it's not recommended to do so is because destructors happen to run when an exception is already pending, and there's no reasonable thing for the compiler to do with that other exception then, other than let the process die. If you always wrap points where destructors run in try/catch, you can throw from them with no problems whatsoever - same as in Java. If you don't wrap them in try/catch, then there's nothing analogous to that in Java (until v7), since it doesn't auto-run close().

      "Destructors shouldn't throw" is not a language rule, it's a proper API design rule. It's very hard to write a library that correctly deals with objects which can throw when they are being released. Hence, the standing advice to the library authors is to not even try to do so, and the standing advice to the users is to not throw when cleaning up, and do "best effort" cleanup. This works wonderfully in practice.

      That is the nature of resources, they can fail at any time and with all resources you can recover from it in a graceful way. Except of course for memory resources, that is why RAII is only useful for memory

      Can you explain the difference between "cannot close a file handle" and "cannot release a block of memory", and why you can recover from one but not the other?

      Also, how, exactly, do you gracefully handle not being able to close a file?

  57. Re:Improvements by slack_justyb · · Score: 1

    The problem with Java is that the startup time is poor, which is often ignored by benchmarks.

    I can understand this poorly written application usually have very long start up times. Usually if you need to yank in a ton of stuff you can do that at runtime in the background. Dynamic loading.

    Compare that to, say, ASP.NET, which if precompiled can launch in a few hundred milliseconds!

    You can precompile EE applications as well and have them start up in milliseconds. I think the PHP guys are the ones who came up with this in the first place but then of course I am sure that at some point Xerox came up with the idea first.

    There's no good reason for this. Oracle could use a container format that's uncompressed by default, pre-compile, cache, etc...

    As far as EE goes you are not required to use WAR or whatever they are called. In SE that is being addressed in Java 8, but you can already do some of it with dynamic loading. .NET is snazzy in the fact that the VM is loaded with the OS so you only incur the cost at startup and shutdown. Maybe that's why it seems to take ten minutes to turn off a Windows machine.

    There's also still this attitude of having "User" vs "Server" JVMs

    So does .NET, except it's not a switch away. Do you think they use the same .NET VM in Windows Server as they do in Windows Home whatever?

  58. Re:Improvements by slack_justyb · · Score: 1

    One could say the exact same thing about VTables in C++, lookup pointers in C or RT-Code in Objective-C. Which bring me back to my point we could debate this at about the same rate we could debate compiler vs JIT. Machines are state based, OOP is artificial no matter the platform, a CPU is not made to natively understand the concept of an object be it C++, C#, VB, or Java.

    At some point a machine will not natively do everything a language requires and thus extra "fluff" will need to be added. That's why Interpreted vs JIT is defined as who sends the executed code to the machine and when, not what is executed or how it goes about it. C++ compilers add machine code abstraction layers for all kinds of stuff like virtual pointers and polymorphism, does this suddenly classify every C++ compiler as JIT?

  59. Re:One day we will be done with java... by bonch · · Score: 1

    In the 50s and 60s, programmers were skeptical of using a high-level programming language in place of assembly, but the productivity and understandability increase was too great to ignore. Today, using assembly is frowned upon expect in very specific situations. In fact, compilers are generally regarded as being capable of doing a better job than a human could.

    The computer exists to do work for you, and that inevitably includes managing its own memory. Automatic memory management in some form is an inevitable future for most application programming.

  60. Re:Improvements by Lisandro · · Score: 1

    No. C++ generates binary machine code. It is not portable. It is loaded directly into memory where it is executed directly by the CPU. There's no "just in time" there, at all.

  61. Re:Improvements by Waccoon · · Score: 1

    Is that why Java installs so many "Quick Starters" as background processes and plug-ins in every nook and cranny it can?

  62. Re:One day we will be done with java... by Jmc23 · · Score: 1

    Wow, so it's almost like lisp?

    --
    Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
  63. Re:Improvements by Jmc23 · · Score: 1

    Maybe king of the popularity hill. A lot of us still think that lisp is the king of elegance, and look, wow, java got some more lisp features.

    --
    Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
  64. Re:Improvements by Lisandro · · Score: 1

    I was referring to speed alone, where Java runs circles around Lisp. But yes, if we're talking elegance Lisp makes Java look like Flavor Flav.

  65. Re:Improvements by sgt101 · · Score: 1

    If I was doing this I would use an in memory database. I would talk to that database using Java.

    I developed in C++ for 5 years, I have thanked Jesus and his angels every day since Java came to save me.

    --
    --------------------------------------------- "In the end, we're all just water and old stars."
  66. No hit by SuperKendall · · Score: 1

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  67. Re:One day we will be done with java... by nstlgc · · Score: 1

    The punchline being that C# has had "using" clauses (try-with-resources) since 1.0 and its compiler type inference (you know, the one it got in 3.0) wipes the floor with that cute diamond syntax thingie. Sorry for the trollish language, but you know I have a point...

    --
    I'm Rocco. I'm the +5 Funny man.
  68. Re:One day we will be done with java... by nstlgc · · Score: 1

    C# had it 10 years ago.

    --
    I'm Rocco. I'm the +5 Funny man.
  69. Re:One day we will be done with java... by prionic6 · · Score: 2

    I totally agree. Also, it's not about the noobs. I suspect most experienced java programmers cant' code the correct try/catch/finally/try/catch for a resource access without looking it up. Check http://stackoverflow.com/questions/4092914/java-try-catch-finally-best-practices-while-acquiring-closing-resources

  70. Re:Improvements by m50d · · Score: 1

    Haha, if java doesn't scale why is it the defact standard for any large enterprise?

    Because 10 years ago it was the best tool for the job.

    --
    I am trolling
  71. Re:A language with a file system? by DrXym · · Score: 2

    Well it is. It has new asynchronous channel functionality and the FS stuff also allows Java to watch directories, walk through them, examine attributes and other stuff. Java is generally a good language but some stuff particularly Date & Time and IO have been pretty mouldy and long over due a revamp.

  72. Re:One day we will be done with java... by DrXym · · Score: 1

    I mean if that doesn't say it all I don't know what does. Hmm Allocate a resource, Free a resource. I think they still teach that in CS-101, then again maybe not. I alloc() therefor I free() ?".

    Maybe they do. Doesn't mean it's not a pain in the arse to get right ESPECIALLY in Java since a close() can throw an IOException and ESPECIALLY if you have more than one resource open, e.g. input & output file and you need to ensure both get closed in all normal and extraordinary circumstances.

  73. Re:Improvements by SomeStupidNickName12 · · Score: 1

    Its still the best tool for the job, I agree that something like C++ has better scalability from a pure language perspective but java far more scalable from an environmental perspective.

    There is no such things as a clustered app server in the C++ world, MQ servers that can push through millions of message a day within the bounds of a full XA transaction.You either build them yourself which would take years or you use Java.

    And part from the 3 possible contenders to the enterprise crown (C++, java, .NET) nothing else even comes close.

  74. Re:Improvements by Rockoon · · Score: 1

    So does .NET, except it's not a switch away. Do you think they use the same .NET VM in Windows Server as they do in Windows Home whatever?

    I dont know what he thinks, but you are quite clear about what you think and its wrong. The CLR is the same between Server and Home versions of windows. There simply is not differing branches of the CLR because that would defeat its purpose.

    --
    "His name was James Damore."
  75. Re:Improvements by DrXym · · Score: 1
    Java's UI is perfectly acceptable for a range of trivial and complex applications. The fact that tools like Netbeans use it should demonstrate that it is no impediment. And if you absolutely need faster performance, or a more native appearance (though Swing is close enough) then SWT could provide that too. Eclipse is built in SWT and is probably the most complex application from a UI standpoint that anyone is ever likely to see.

    A bigger issue for Java is that it uses layout models extensively to ensure GUIs cope with differences in metrics, fonts etc. from one platform to the next. It can be a huge pain in the arse to program layout models. There are GUI editors (e.g. Window Builder, or Netbeans) and relative / group layouts but these editors never work 100% properly. Android inherits this same problem too but at least it's declarative. Java could really do with a standard declarative way to define layouts.

  76. Re:One day we will be done with java... by rpopescu · · Score: 1

    Yeah, and C++ had it since before Gosling decided C++ wasn't good enough for him.
    Ever since its inception, Java has steadily acquired lame, non-generic, basically hacks of implementations for features in C++ which it strived so hard to shun. Mainly due to Gosling being not smart enough to really understand C++ in the first place. Honestly, read some interviews with him, he's just guts and bile about it, no logical arguments whatsoever, typical I-don't-get-it-therefore-it's-wrong, holier than thou attitude.
    The tasteless, confused hamburger that Java is today is the result of its small minded creator and the barriers built in since the beginning. Doug Lea's work turned the crapfest Java was into a workable platform for serious applications, but that's about it.

  77. Re:Improvements by DrXym · · Score: 1

    Even Eclipse is fast unless you weigh it down with plugins. J2SE or J2EE Eclipse with a couple of plugins (e.g. Maven & source control) works perfectly well. IBM's WSAD (Eclipse + a massive amount of crap for websphere / rational / kitchen sink development)... not so much.

  78. Re:Improvements by DrXym · · Score: 1

    Because 10 years ago it was the best tool for the job.

    It's still the best tool for the job. And it scales extremely well assuming you bother to write apps correctly to cope with the dataload.

  79. Re:Improvements by bertok · · Score: 1

    I can understand this poorly written application usually have very long start up times.

    Nothing to do with code quality, unless you consider "using the standard libraries" poor programming practice!

    You can precompile EE applications as well and have them start up in milliseconds.

    Maybe, with some containers. I said that. My point is that 90% of Java environments don't or can't do this. It's certainly not the default.

    In SE that is being addressed in Java 8

    That's my point! Java 7, which is now 16 years old, still doesn't have minor, unimportant features like... fast start time, even though, as you put it, other people have solved the problem decades ago.

    Dot NET is snazzy in the fact that the VM is loaded with the OS so you only incur the cost at startup and shutdown

    Not true! The VM is only loaded if an application needs it. The operating system doesn't -- Windows XP and 2003 certainly don't, and even newer versions usually don't load it. Heck, Server 2008 R2 doesn't even fully install it by default for security.

    It's also another difference between .NET and Java -- automatic sharing of DLLs between running processes. On Citrix or Terminal Servers, this makes a massive difference to resource usage. Java reloads and recompiles everything for every user! On a 100 user server, that's about 50x the overhead of a comparable .NET app.

    Do you think they use the same .NET VM in Windows Server

    It's the same install package and binaries, but there are some small differences, like the default GC mode. You can override it if needed with a configuration entry. Not that I've ever seen anyone having to do this, because the defaults are fine, unlike the Java workstation VM, which is too slow to use for some workstation GUI apps! One of my tricks is to switch to a 64-bit server JVM to run IDEs because the speed boost is quite noticeable.

  80. Re:What Java really needs by master_p · · Score: 1

    This new Java statement, C#'s blocks and C++'s destructors are all hacks that solve a problem that would not exist in the first place if those languages had lazy evaluation: the code that uses those resources could have been passed as a functor to another function that opened the resources, called the functor and then closed the resources.

    It it amazing that in this day and age, language designers ignore language design and compiler basics this much.

  81. Re:A language with a file system? by Exitar · · Score: 1

    Read the article? Do you know where you are?

  82. Re:One day we will be done with java... by serviscope_minor · · Score: 2

    Thanks for the object lesson dick.

    You thank him for the lesson which is strange since you seemed to misunderstand it.

    1. Raii gives you the -ability- to reclaim resources after a fault,

    No, it automatically reclaims them. E.g.:

      osfstream f("tile.txt");
      throw "An error!";

    now f is automatically flushed, closed and reclaimed.

    2. If you mean writing a hell of a lot of useless boiler plate and trouble laden code

    Well no, not really. In this case, the C++ version is shorter and therefore less error prone.

    --
    SJW n. One who posts facts.
  83. Re:Kill it Oracle by neokushan · · Score: 1

    A Language that gives you head? Where do I sign up?!

    --
    +1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
  84. Re:Improvements by Xest · · Score: 1

    Meh, not sure what you're used to but Eclipse is always slow, no matter how few plugins you use.

    I don't disagree with the original comments- that Java being slow is a 90s argument, but Eclipse is a particularly poorly written piece of software that really doesn't demonstrate Java very well.

    The GP pointed out why Eclipse is slow though, and why it's not a Java issue, but a poor design issue.

    Compare Eclipse to other IDEs like NetBeans, JDeveloper, or Visual Studio and you can see how much of a joke it is. It's not even just initial boot up, even intellisense in it is too slow to be of much use a lot of the time really.

  85. Re:Improvements by silentcoder · · Score: 1

    > I still change DIP switches on ISA cards at my work place.

    Sheez, who do you work for ? The museum of retrocomputing ?

    --
    Unicode killed the ASCII-art *
  86. Re:Improvements by silentcoder · · Score: 1

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

    By what measurement ? Both python and ruby can outperform it in at least some situations, both are more advanced and powerful languages with better features and faster development cycles.

    Or do you mean back-office market share ? I'll grant you that one...

    --
    Unicode killed the ASCII-art *
  87. Re:Improvements by MichaelSmith · · Score: 1

    I don't find eclipse to be especially slow but it does everything it can to make software written under eclipse difficult to run outside eclipse. For example eclipse runs class files directly while deployments use jar files. Eclipse has its own classpath file format which is of no use in the outside world.

    --
    http://michaelsmith.id.au
  88. Re:Improvements by m50d · · Score: 1

    I know that. But IIRC it announces in the splash screen that it's using Java, and so it's still one of the things I think of when I'm trying to think of "java desktop app". Seriously, if it's possible to write a snappy, performant desktop app in Java, why can't I think of any?

    --
    I am trolling
  89. Re:Improvements by MichaelSmith · · Score: 1

    assuming you bother to write apps correctly.

    Thats quite some assumption you have there. The problem with java IMHO is that it gives the bright young things a lot of fun toys to play with and opportunities to create write only source code.

    --
    http://michaelsmith.id.au
  90. Re:Improvements by MichaelSmith · · Score: 1

    I still change DIP switches on ISA cards at my work place.

    Hey I had to attack the backplane of a PDP 11/84 to install a SCSI card.

    --
    http://michaelsmith.id.au
  91. Re:Improvements by DrXym · · Score: 1
    I'm quick enough to rant when I hate something. Eclipse has its faults but performance is perfectly tolerable for me. I'm using it on a fairly crappy dual core box right now on a 30,000 file project and it works fine except when I fire up a couple of instances and physical memory has depleted. It's badly behaved plugins which hog memory or hook into much stuff that hurt performance. If you restrict yourself to the version of Eclipse that meets your needs you should be okay.

    I'd add that Eclipse and Netbeans aren't really that different at the low level. Both implement RCPs over modular frameworks. Eclipse uses OSGi, Netbeans has it's own framework with an OSGi bridge.

  92. Re:Improvements by DrXym · · Score: 1

    Thats quite some assumption you have there. The problem with java IMHO is that it gives the bright young things a lot of fun toys to play with and opportunities to create write only source code.

    No, it's not an assumption, it's a requirement. If the requirement says "must scale", then you design and write your app to scale, depending on what that means in the circumstances. In many cases it just means being able to run extra instances of something in a cooperative fashion and externalizing settings for performance tweaking. In others it means using a scaling app server like Gigaspaces. I'm quite sure you can abuse Java in all sorts of perverse ways if you don't know what you're doing, but that isn't the point.

  93. Re:Kill it Oracle by Kjella · · Score: 1

    There are places where it's still very legitimate, like high performance crypto libraries, video processing, graphics engines, that sort of thing. Typically you have a reference implementation in C or some other portable language and the assembler is conditionally compiled in, so it works on other platforms but you only get the extra performance boost on that particular platform. It's a niche but so is kernel and driver development, it still makes sense to have some people specialize and do those specific tasks. I wouldn't go it as a career though, there's way, way too many developers from the "bad old days" who know all about shaving two bits and four instructions off a calculation.

    --
    Live today, because you never know what tomorrow brings
  94. Re:Kill it Oracle by angel'o'sphere · · Score: 1

    I don't really get why people emphasize to be able to program in assembler. Or machine code ...

    Do you really believe a programmer who can program in Java or even Visual Basic is incapable of learning assembler?

    For most programmers there likely never was a need to learn any assembler or more than 2 languages ... nevertheless assembler is easy to learn.

    There is no magic about it.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  95. Re:Improvements by angel'o'sphere · · Score: 1

    What do yu mean with Java does not scale ?

    Do you even knwo what scale in IT means? It certaily has nothing to do with millions of objects in memory ...

    You do know that many larg scale internet companies run their business on JVMs? (Not necessaryly on Java, but Scala or other languages)

    You don't tackle slowness or speed in general by the language or platform but with architecture and design.

    A straight forward written C++ program hardly will outperform a well thought out Java solution. Ephasizies on "straight forward" and "well thought out"!

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  96. Re:One day we will be done with java... by dshk · · Score: 1
    osfstream f("tile.txt");
    throw "An error!";

    That is great (really), but it does not support inheritance. The declared type must be the same as the actual type, which would render a similar construct in Java useless most of the time.

  97. Re:Improvements by angel'o'sphere · · Score: 1

    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.

    Nitpicking: in an interpreted language the language is interpreted. Java is not and never was an interpreted language. Its bytecode is interpreted, so: the bytecode is an interpreted language.
    In a truely interpreted language (today we don't have many anymore as nearly everyone makes a small compile pass and creates some intermediate code) the programm is basically executed/interpreted line by line. That means the interpreter will stop with an error as soon as it finds something it can not interpret. So it is possible that programs only run half:

    10 PRINT "hello World"
    20 GARBAGE
    30 GOTO 10

    In this example line 10 is "interpreted" and that means executed, but line 30 is never reached. Java on the other hand is compiled and an error like line 20 would be discovered during the compile phase.

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  98. Re:What Java really needs by sourcerror · · Score: 1

    JPA has pretty much lazyness.
    Also, you can pass "functors" with anonymous classes.

  99. Re:What Java really needs by master_p · · Score: 1

    But anonymous classes is not a convenient way to do it. They require the definition of a super class or an interface, they require typing the super class or interface they implement, etc.

  100. Re:One day we will be done with java... by LizardKing · · Score: 1

    Cool! Can I use this C# language to create desktop apps that run without modification on Linux, Mac OS X and Windows? Is there a cross platform IDE for this C# language that allows me to develop in the same IDE on Linux as my colleagues do in Windows or OS X?

  101. Re:Improvements by stdarg · · Score: 1

    Shouldn't the implementation be in question, not the language as a whole? Javascript is usually interpreted, but I'm sure someone has written a Javascript compiler that emits executable machine code.

  102. Re:Improvements by Lisandro · · Score: 1

    I was *almost* tempted to ask you to enlighten me there. Nice job! Now doze the fuck off please.

  103. Re:Improvements by Lisandro · · Score: 1

    I don't think there's a single language today out there that isn't compiled to bytecode prior to execution on a VM. Even Perl does it AFAIK. The code is still being interpteted, just not from the text sourcecode directly.

  104. Scala is not dynamic! by EvilRyry · · Score: 1

    FTA:

    A key feature of Java SE 7 is its accommodations for dynamic languages, which are becoming prominent on the JVM lately, thanks to the emergence of languages such as JRuby and Scala.

    Scala is _NOT_ a dynamic language!

  105. Re:Improvements by Mongoose+Disciple · · Score: 1

    Even Eclipse is fast unless you weigh it down with plugins.

    The problem with that statement is: basically everyone who uses Eclipse seriously also uses a lot of plug-ins to provide all the functionality Eclipse doesn't out of the box.

    In my career I've known over a hundred developers who used Eclipse as their major development tool, and not a one of them used less than three or four plug-ins with it.

    Saying Eclipse doesn't run like a dog if you don't add plug-ins is like saying your car gets great gas mileage if you take the seats out and don't weigh it down with passengers or cargo: technically true and yet totally useless from a practical perspective.

  106. Re:One day we will be done with java... by LizardKing · · Score: 1

    The try-with-resources handles all this for you. declare both resources in the try (...). The auto-closing will be applied to all the resources you specify, and in the event of an exception being thrown in your try block, then any exception thrown by the closing of the resources will be ignored (although there is a means to access them if you so wish).

  107. 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.

  108. Re:Improvements by LizardKing · · Score: 1

    I agree that something like C++ has better scalability from a pure language perspective but java far more scalable from an environmental perspective.

    Threading and locking are far easier to implement in Java rather than C++, as they're built into the language and libraries. The concurrent add ons that came with Java 1.5 improved things as well.

  109. Re:Improvements by GooberToo · · Score: 1

    (Andriod comes close if you could even call it Java still).

    We don't. Its not.

    Android's use of Java and UI's have absolutely nothing to do with the topic at hand. Your reference is neither applicable or relevant.

  110. Re:Improvements by Lisandro · · Score: 2

    I love Python, don't get me wrong, but it is nowhere near Java regarding raw performance. Even the developers acknowledge this, with stuff like the Google sponsored Unladen swallow and PyPy.

    Haven't toyed much with Ruby these days though. I should :)

  111. Re:Improvements by silentcoder · · Score: 1

    >I love Python, don't get me wrong, but it is nowhere near Java regarding raw performance.

    I did say in SOME situations, in most cases you are right. Ruby - particularly the RoR setup beats it hand's down though, and I honestly do believe that zope holds up well against glassfish in all but the most strenuous environments.

    --
    Unicode killed the ASCII-art *
  112. Re:One day we will be done with java... by LizardKing · · Score: 1

    No, but in practice Java never really lived up to that promise either, except for very trivial applications.

    Bollocks. I've worked on at least three non-trivial systems that are written in Java and run on at least two platforms (Linux and Windows) without modification. The first is a warehouse management system for a multi-national publishing company, the second is the front end to a repo trading platform used by a dozen Wall St or City of London based banks and the last is a large suite of applications for a government organisation. The only way it can "fail to work in reality" is if you deliberately use classes you shouldn't (eg. those in the sun.com hierarchy) or ignore the few areas where you have to use the - well documented - portability features of the class library (an example is using File.separator when manually constructing filesystem paths).

  113. Re:Kill it Oracle by GooberToo · · Score: 2

    Let me get this straight - you think that a harder programming language increases programmer competence. While I'm not defending Java, this logic is deeply flawed.

    Glad to know you're here to fix the entire world's education system. Sorry, but YOUR logic is deeply flawed. With your logic, none of the "good schools" are actually any good. So yes, clearly those capable of mastering difficult tasks show they are better in any way.

    I'm going to take a wild stab here and say, perhaps you are a Java programmer? And even if you are not, YOUR logic is dubious at best and in no way invalidates the line of thinking which spurred your initial response.

  114. Re:Improvements by sproketboy · · Score: 1

    sigh - so 1990's.

    http://www.brackeen.com/javagamebook/

    Grab chapter 12 and build it. It's a 3D game using only the Java 2D APIs. Not OpenGL, No DirectX. It's under 200k JARed with the resources.

  115. Fork-Join in Java 7 is a calamity by cooper6 · · Score: 1

    The fork-join framework pushed in Java 7 as the "way to parallelism for applications" is seriously flawed, http://coopsoft.com/ar/CalamityArticle.html

  116. Re:One day we will be done with java... by GooberToo · · Score: 1

    Its funny that Python has had this licked for some time now. In fact, they have an entire interface to allow for clean resource acquisition and release of any object and even added a statement to compliment.

    Python's combination of, "with/as", context management, and, "try/except/else/finally", make error handling and recovery for even complex use cases fairly easy and extremely powerful.

  117. Re:One day we will be done with java... by benjymouse · · Score: 1

    Cool! Can I use this C# language to create desktop apps that run without modification on Linux, Mac OS X and Windows?

    yes: http://www.mono-project.com/Main_Page.

    You have a choice between Windows Forms or GTK as the widget toolkit. Both are supported on X11, Win32, and OSX.

    Is there a cross platform IDE for this C# language that allows me to develop in the same IDE on Linux as my colleagues do in Windows or OS X?

    yes: http://monodevelop.com/

    --
    Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
  118. Re:A language with a file system? by GooberToo · · Score: 1

    When I first started doing Java, I was shocked and amazed at how very shitty the entire IO model and APIs were for IO and Data/Time. Literally, doing it in C++ and especially Python would have been leaps about bounds faster, easier, and better. I quickly found my self wonderful why so many claim Java development is faster than C++ when in these areas, clearly it is not.

  119. Re:Kill it Oracle by GooberToo · · Score: 1

    I don't really get why people emphasize to be able to program in assembler. Or machine code ...

    Says a lot. There are still plenty of platforms where assembler is REQUIRED. Furthermore, on others, even where higher level languages, such as C, are available, to access certain hardware features are still only available via direct assemble and/or machine code.

    Do you really believe a programmer who can program in Java or even Visual Basic is incapable of learning assembler?

    Bit of a red herring there. Capable of learning? Probably they are capable of learning. Do they have a desire to learn it? Probably not. Are they capable of learning it well? Maybe. Are they capable of understand the overall implications of some of the code they may generate at this level? Its iffy if we're talking about the average Java coder.

    nevertheless assembler is easy to learn.

    Reading a dictionary is easy. Remembering the words and knowing how to put them together properly and concisely is an entirely different animal.

  120. Re:Improvements by Hatta · · Score: 1

    Arguments for slow Java are so 1990's. Every Java application, desktop or otherwise, I have written has been very snappy, very responsive.

    Where do I find some of this snappy java?

    --
    Give me Classic Slashdot or give me death!
  121. Re:One day we will be done with java... by EdgeCreeper · · Score: 1

    And of course, don't forget how try-with-resources fixes common bugs where an exception in closeFile gets swallowed, or overrides the original exception...

    This is what I do these days to avoid these problems:

    Exception exception = null;
    FileInputStream input = null;
     
    try
    {
      input = new FileInputStream("example.txt");
    // Reading and processing of file content goes here
    }
    catch (Exception e)
    {
      e.initCause(exception);
      exception = e;
    }
    finally
    {
      try
      {
        if (input != null)
          input.close;
      }
      catch (Exception e)
      {
        e.initCause(exception);
        exception = e;
      }
    // For other statements in the finally clause the same thing can be repeated
    }
     
    // Throw exception if one has been thrown
    if (exception != null)
      throw exception;
     
    // Return value from method

    Handling exceptions this way has the advantage that I can see exactly what has happened even if statements in the finally clause throw an exception after another exception has been thrown. It also doesn't matter if many exceptions get thrown in the finally clause, they are all recorded in the stack trace. That is just the basics, helper classes can be created to make this even easier to write with fewer lines of code. Some exceptions may need to be caught and wrapped in another exception. For instance, SQLException has the SQLState and vendorCode properties which do not print in the stack trace. This means that another exception needs to be created to wrap SQLException and put these properties in its detail message.

  122. Re:Improvements by BotnetZombie · · Score: 1

    Both python and ruby can outperform it in at least some situations

    [Citation Needed]

  123. Re:One day we will be done with java... by leighklotz · · Score: 2

    C# had it 10 years ago.

    Lisp had it 30 years ago. Go suck eggs.

  124. Re:One day we will be done with java... by EdgeCreeper · · Score: 1

    I would just like to post a link to my other comment which shows the way I handle exceptions. I believe this is superior because I can see every exception that gets thrown in the one stack trace, and that all the exception logging can be handled in one area of the program. It has worked very well for me.

  125. New Java Developer Advice? by jon3k · · Score: 1

    I've been considering using some free time to play around writing Android apps for fun (I have no ambitions of trying to make any money at it) but I'm really nervous about the time investment with all the uncertainty around java. I have literally zero experience programming in Java, but I've played with C++ a little bit and several other higher level object oriented languages.

    Can anyone give me some advice here? Is my time better spent just brushing up on HTML5 and Python?

    1. Re:New Java Developer Advice? by slim · · Score: 1

      Very little of your time spent learning Java will go to waste.

      1. It's a very marketable language, and looks good on your CV even if you don't end up using it
      2. Most of the concepts are transferable

      'Effective Java' is a good book. A lot of the advice applies to every OO language.

    2. Re:New Java Developer Advice? by bobaferret · · Score: 1

      Everyone will have their own opinions, but here is mine. The nice thing about java is that you can run the code just about anywhere. There are great libraries out there for free to help you accomplish almost anything. The web is filled with examples and documentation for Java. Lots and Lots of enterprises use it for critical things. Java projects are fairly easy to maintain. Eclipse is a very capable editor, and does re-factoring pretty well. My understanding is that python can have some complicated version issues. Java has maintained backward compatibility fairly well. I like being able to develop on any platform in the same IDE and run it on any other platform w/o really worrying about compatibility issues. If you were talking about writing GUI apps as opposed to web apps, I'd suggest you might want to go someplace else though, as I've never had much luck with any of the visual form editors, and doing it by hand is tedious. JavaFX has some buzz around it, but I'm not going to hold my breath. I think there is a lot of potential with HTML5/and SVG canvases, XML/XSL, and Java which when using Saxon's XML libraries can do some crazy things. Java Servlets handle interaction with AJAX pretty well too.

    3. Re:New Java Developer Advice? by sourcerror · · Score: 1

      "but I'm really nervous about the time investment with all the uncertainty around java."

      It's very unlikely for Google to abandon Dalvik.
      Microsoft paid for the same patents (to use it in .Net), and I expect Google to do so as well:

      "Under the 10-year pact with Microsoft, the software company will pay Sun $700 million to resolve antitrust issues and $900 million to resolve patent issues, the companies said. The companies will pay royalties to use each other's technology; Microsoft is paying $350 million now, with Sun to make payments when it incorporates technology later"

      Read more: http://news.cnet.com/2100-1014_3-5183848.html#ixzz1W4P96FFM

      But the worst case is, that you learn some Java, and OpenJDK isn't going anywhere.

  126. Re:Improvements by silentcoder · · Score: 1

    First example that comes to mind: a command-line only program, unix style with a lot of standard libraries pulled in. Both python and ruby would be faster there since execution time is a minimal aspect of the running time of the program - java's slower startup time would be a much larger percentage of the total run-time and the java program would thus perform slower over-all.

    Hell.. a BASH script would outperform java in this scenario.

    I never said in all cases or for all jobs - I said SOME scenarios. This is an example of such a scenario - and such programs are a very large subset of the software in the world.
    The unix approach to design of building lots of small tools that can interoperate and do complex tasks by being plugged together differently is almost impossible to achieve in java development because startup times on individual programs is so much higher. It works well with native code, the difference with languages like python, ruby and even bash is so small that users never even notice.

    I'll tell you this though - if you replicated the standard unix user-space in java it would be an absolute and unusable nightmare to work with, the same clearly doesn't apply to bash or python since large parts of the contemporary unix userspace stack is ALREADY written in them. This is even true of the much older perl.

    In short - there are use-cases where java performs worse than even wholy interpreted scripting languages, I've shown you own, that's enough.

    --
    Unicode killed the ASCII-art *
  127. Re:One day we will be done with java... by serviscope_minor · · Score: 2

    That is great (really), but it does not support inheritance.

    Huh?

    If you want inheritence, you have to do it with pointers.

    auto_ptr p(get_from_factory());
    throw "An error!\n";

    Is that what you meant? It still works...

    --
    SJW n. One who posts facts.
  128. Re:Kill it Oracle by alexo · · Score: 2

    Let me get this straight - you think that a harder programming language increases programmer competence. While I'm not defending Java, this logic is deeply flawed.

    Not speaking for the GP, but my take is that the harder the language, the less incompetent programmers it will attract.

    Think about it this way: if any idiot can do VB then every idiot will do VB (in preference of other languages).

    That said, if a language is merely hard, with no added benefits in power, expressiveness, etc., it will also fail to attract the competent programmers.

  129. Re:A language with a file system? by DrXym · · Score: 1

    Date & time is a particular bug bear because I had to write an embedded system which dealt with time dependent data, had to cope with local time zones, daylight savings changes and data which was based off UTC. I think I did a pretty good job in the end but it sure as hell wasn't helped by the system libraries. The trick is to use time in millis from the epoch and never attempt to convert to / from local date at all except to present the data to the user. It's still a pain though. I would have used Joda time but it was too big and bloaty for embedding properly.

  130. Re:Improvements by Jmc23 · · Score: 1

    ,fter it's all beautiful an working properly you can throw in all your declarations to get performance on par or greater than C. I think most ppeople just don't learn that part, somethings still slower though. I'd rather the tradeoff of elegance with.the ability to get performance than having to write it ugly to begin with.Actually

    --
    Don't complain about syntax, grammar, or spelling. There is no.hell like input on android.
  131. Java...Yawn. I care about the JVM. by TheTyrannyOfForcedRe · · Score: 1

    Java the language is dead to me. I could care less. What I do care about are JVM improvements that speed execution of the alternate JVM based languages: Scala, Rhino, jRuby, Clojure, Groovy, and to a much lesser degree Jython. The alternate languages are where all the action will be over the next ten years.

    If you're a Java-only guy and haven't looked at Scala, run don't walk! You will love it, especially if you've played with any of the functional languages at Uni or on your own time.

    I can only hope that someone will do a JVM Haskell and that the OCaml-Java project will mature into a stable platform.

    --
    "Liechtenstein is the world's largest producer of sausage casings, potassium storage units, and false teeth."
  132. Re:Improvements by BotnetZombie · · Score: 1
    I just did a small test on all three for the fun of it and you're right about the startup time. For a simple hello world on my machine, Ruby 1.9.2 takes on average ca 50 ms to execute, python 3.2 70 ms and Java 6 100 ms. That startup time difference is too small for user-detection and once the program starts doing anything the difference will be in the other direction.

    Other things you talked about don't have anything to do with performance, so you haven't talked about use-cases in plural but only about the small amount of startup time difference.

  133. Re:Kill it Oracle by Toonol · · Score: 1

    I think that the best programmers learn the hardest and most difficult languages in order to improve their skill, and then actually program in the simplest language that meets the criteria for the task.

    I don't like Java much, but it has a purpose, and good code can be written in it. Heck, old VB had it's purpose, and a niche where it was far superior for development purposes than C++.

  134. Apple and Java SE 7 by monzie · · Score: 1

    Now that Apple is moving away from Java and we dont have Java SE 7 downloads from Apple I do not see Java SE 7 downloads on Oracle's page as well. Is building OpenJDK on mac the only option left?

  135. Question by warrax_666 · · Score: 1

    What happens if, say, a close() fails during the destructor call?

    --
    HAND.
    1. Re:Question by shutdown+-p+now · · Score: 1

      Destructors should never throw (in C++11 this is further enforced by marking them noexcept by default). A well-written destructor will wrap any potentially-throwing operation into a swallowing try.

      Note that this is not just a C++ issue. Generally speaking, any unconditional, unparametrized cleanup operation must not throw in any language, because, well, what is the caller supposed to do when cleanup fails? He's now holding a resource that he is, on one hand, obligated to release (since he's the owner), but, on the other hand, cannot do so because it's failing.

  136. Re:Improvements by silentcoder · · Score: 1

    Now take your python script and stick 100 include lines on top. The use 100 standard libraries in your Java app. No need to do anything. Just call them and compare the results. Java startup times increase exponentially the more libraries it calls. Python has no such issues. Bet its user noticeable now.

    The Unix style of design is just as useful and powerfull in application development. Building a complex app out of lots of small specialized little apps makes your app much more powerful and scalable. If those little tools are executable program s then that itself is a feature. Users can plug them together in ways you could never have thought off or provided. That entire design philosophy and the myriad programs that use it is ruled out in Java. Even a 5% increase in startup times add up to an unacceptable load when normal operation will start hundreds of apps in unpredictable order. Especially if they can't share resources like Library memory or fully benefit from copy on write like.

      program

    --
    Unicode killed the ASCII-art *
  137. Wrong. by sidragon.net · · Score: 1

    One tool is better than another when it helps you accomplish the same task with less effort.

  138. No. by warrax_666 · · Score: 1

    An intermediate representation is being interpreted.

    --
    HAND.
  139. If you have only by warrax_666 · · Score: 1

    simply scoped resources that is.

    --
    HAND.
  140. Re:Kill it Oracle by Raenex · · Score: 1

    Did you really choose Perl as your unsafe language? I thought you were going to describe C. Perl copies lists and strings by default because it's the safe thing to do, even though it is inefficient. Perl added "use strict" and it is widely encouraged and used. Perl doesn't enforce public and private because it is a dynamic language derived from shell programming, and its object-oriented features were tacked on with superglue.

    Perl does have a lot of crazy magic and syntax, but that's just a reflection of the designer. Lots of good programmers don't like it, and hence Python was born.

    The reason you have more bad Java developers is because that's the language business gravitated to after tons of bad developers were making a mess in other languages, like C and C++. As another example, PHP, has a lot of confusing design choices and lots of ways to screw up, but tons of programmers use it, bad ones included, because it's a very popular language on the Web.

  141. Re:Kill it Oracle by Raenex · · Score: 1

    The correct use of apostrophe is grammar, not spelling, as it concerns syntax.

  142. Lazy evaluation by warrax_666 · · Score: 1

    Lazy evaluation has nothing to do with it.

    Not even lambdas are needed, nor anonymous classes. All you need is the ability to instantiate objects (with state) dynamically (aka. "new").

    Of course anonymous classes and (especially) lambdas make such an API much nicer to use.

    --
    HAND.
  143. Re:One day we will be done with java... by http · · Score: 1

    You never owned a mac, right? PowerPC, not Intel. All kinds of fun with not working, on MacOS, OS X, and GNU/Linux.
    Pardon me for remembering more than the last decade of my life.

    --
    If opportunity came disguised as temptation, one knock would be enough.
    3^2 * 67^1 * 977^1
  144. Re:Improvements by Raenex · · Score: 1

    Alternatively, why are bloated apps written in C++ just as slow to load?

  145. Re:Improvements by Raenex · · Score: 1

    I did say in SOME situations

    I've never heard of Ruby or Python outperforming Java, Rails included. Do you have a cite?

  146. Re:Kill it Oracle by Ragondux · · Score: 1

    I didn't describe Perl as unsafe, but as difficult to use for bad programmers, and requiring skill to be used properly. That's also the case with C, but for historical reasons and because C is closer to the hardware. Perl was designed that way.

    The rest of your message is rephrasing what I meant, so I agree... but maybe I wasn't very clear in my post.

  147. Re:One day we will be done with java... by shutdown+-p+now · · Score: 1

    its compiler type inference (you know, the one it got in 3.0) wipes the floor with that cute diamond syntax thingie.

    For the most part this is true, but C# "var" is only usable for local variables, whereas Java diamond inference can also be used with fields.

  148. Re:Kill it Oracle by rhendershot · · Score: 1

    I don't really get why people emphasize to be able to program in assembler. Or machine code ...

    Says a lot.

    says nothing at all. using C++ or C# or Java is a conceptual skill quite apart from machine level programming. Everything from threading to object/data maintenance to looping is different in a fundamental way.

    I'm one of those "uneducated" (my background is Electronics, not CompSci) java programmers doing mostly business applications. I would only assert my competence. I also entered machine code in Heathkit ET3400 as well as C= Vic20/128. I repaired arcade video games like Defender and MsPackman also.

    People learn what they're interested by and what they are required. The "average" anybody is not going to excite... talk about red-herring...

    Do you really believe a programmer who can program in Java or even Visual Basic is incapable of learning assembler?

    Bit of a red herring there. Capable of learning? Probably they are capable of learning. Do they have a desire to learn it? Probably not. Are they capable of learning it well? Maybe. Are they capable of understand the overall implications of some of the code they may generate at this level? Its iffy if we're talking about the average Java coder.

    The truth of the matter is that C and below programming is really not necessary to the majority of today's programmers. I also modified xmodem on a coherent system where I had dial up. I did that to skip the 64, 128, 256 progression it did to bring up to speed. most of my transfers were 1k or greater and starting at 1024 made a huge difference in the kind of quick transfers I needed to do. I got my first job in software programming by showing the place in that C source code that I modified... why and how.

    Even today I think the better, elegant solution eluded me at the time. But it worked; both in a pragmatic and preparatory sense.

    That's all starkly irrelevant to job-health today for me though.

  149. Re:Improvements by shutdown+-p+now · · Score: 1

    The point is that the only difference here is whether the compilation happens "ahead of time" or "just in time". End result is still the same.

    Note that, in case of Java, the actual story is more complicated, since it also does have a true bytecode interpreter (as in, a loop that processes opcodes one by one and performs the corresponding operation), and switches from that to JIT only for "hot" methods. This is because JIT-compiling itself is not free, esp. if you do advanced optimizations, and for a method that's only called once or twice, you waste more time JIT-compiling than you gain from its faster execution.

  150. Re:What Java really needs by shutdown+-p+now · · Score: 1

    This new Java statement, C#'s blocks and C++'s destructors are all hacks that solve a problem that would not exist in the first place if those languages had lazy evaluation: the code that uses those resources could have been passed as a functor to another function that opened the resources, called the functor and then closed the resources.

    It seems that by "lazy evaluation" here you mean closures/lambdas. C# has them for 6 years now, and there are libraries that do precisely as you want, i.e.:

    DoSomethingAndCleanup(x => {
    ...
    }); // x is freed automatically here

    There are two basic reasons why IDisposable/"using" is still preferred. The first one is perf - calling a lambda is a virtual call, and any local variables captured are lifted onto the heap. This is theoretically fixable by a better optimizer with escape analysis. The second problem is that many language features do not work across the boundary of the lambda - e.g. you can't goto into or out of it; if it's in a loop, you can't break/continue; and you can't immediately return from the enclosing function.

    The other reason is that the wrapper-with-lambda approach can only handle the same as "using", but there are more cases than that. In particular, the case when one object owns another, and they should be freed together. You have to do this manually in C# (by implementing Dispose in owner, and calling the same on the owned object), but at least you can do it. If the only way to clean up the owned object is with a wrapper, you can't do that.

    C++ can clean up owned objects fully automatically, so there's even less reason for using that pattern there (though in C++11, with its lambdas, you can if you want to).

  151. Re:Regarding multicore usage... by shutdown+-p+now · · Score: 1

    No. Fork/join is a higher-level thing that still (usually) works on top of threads, and usually helps you avoid fragile explicit locking.

    Your question is, basically, akin to "is there something you can't do with assembler that you can do with C"? The point of C is to be a convenient higher-level abstraction, not to provide completely new functionality.

  152. Re:Kill it Oracle by Raenex · · Score: 1

    What you described as features for bad programmers in Java were safety features. The only really valid claim you'd have for Perl was the horrid syntax and abundant magic, but you didn't mention those. You also can't explain why PHP is so popular and full of mediocre programmers when it's essentially Perl for the Web.

  153. Re:Java...Yawn. I care about the JVM. by shutdown+-p+now · · Score: 1

    I can only hope that someone will do a JVM Haskell

    No can do. JVM doesn't guarantee tail call optimization for method calls, which is a must for Haskell (and most other FP languages). It's why Clojure has that ugly explicit "recur" hack.

    Unfortunately, JVM wasn't really originally designed for languages other than Java, and it shows. They're trying to patch it up now with things like invokedynamic, but it needs far more than that.

  154. Isn't this just a scoping trick? by greed · · Score: 1

    It's just scoping, really. You can do it in C++ if you like, here's one way to DIY (without the error checking):

    #include <cstdio>
    struct myFile {
    FILE *file;
    myFile(const char *name, const char *mode) { file=fopen(name,mode); };
    ~myFile() { fclose(file); };
    };

    Note that C++ only guarantees destructors are not run before something goes out of scope; exactly when after is Implementation Defined. So if a file MUST be closed (say, because you just wrote it and want to pass it to another program), you still need to invoke the close method explicitly.

    Perl does much the same thing when a reference to an IO::File class or a filehandle gets garbage-collected. This Java feature just makes it part of the language syntax, rather than having to glom on yet another library.

  155. Re:Kill it Oracle by leenks · · Score: 1

    Not speaking for the GP, but my take is that the harder the language, the less incompetent programmers it will attract.

    Surely the harder the language, the less programmers it will attract. There will be a similar proportion of incompetent ones in that language.

    Think about it this way: if any idiot can do VB then every idiot will do VB (in preference of other languages).

    Then why don't the programming Gods use VB? I'm pretty sure they can all code VB if they wanted.

  156. Re:Java...Yawn. I care about the JVM. by kirkb · · Score: 1

    Ah, the impetuousness of youth. All of those "alternate languages where all the action is" are great toys ... until you need to get a job (or leave academia).

    PS - Java ain't dead til netcraft says so!

    --
    Slashdot: come for the pedantry, stay for the condescension.
  157. Re:Improvements by Chaos+Incarnate · · Score: 1

    There's not differing branches of the CLR proper, but there is a Client Profile version of the framework which omits some of the standard libraries.

    --
    Benford's Corollary to Clarke's Law: "Any technology distinguishable from magic is insufficiently advanced."
  158. Re:Improvements by m50d · · Score: 1

    The problem with java IMHO is that it gives the bright young things a lot of fun toys to play with and opportunities to create write only source code.

    Exactly wrong. The big (in fact almost the only) thing java has going for it is that its strong typing and verbose, rigid syntax limit how clever you can be, and mean the structure of any piece of java code remains clear. You can do a much better job of write only source in either C++ (operator overloading, unmanaged memory) or dynamic languages (reuse the same variable for different types, play with all the funny-looking operators in the syntax).

    --
    I am trolling
  159. Re:Kill it Oracle by alexo · · Score: 1

    > Surely the harder the language, the less programmers it will attract. There will be a similar proportion of incompetent ones in that language.

    Not so, the incompetent one will choose easier languages instead, ones that mask their incompetence.

    > Then why don't the programming Gods use VB? I'm pretty sure they can all code VB if they wanted.

    I knew at least one that did.
    He used VBA for MS-Office macros and straight VB for prototypes.

  160. Re:Improvements by thsths · · Score: 1

    > Arguments for slow Java are so 1990's.

    Which is why it is such a shame that they are still true. In fact Java 1.0 would start in 3 seconds on my PC back then when it is up to date. Java 1.6 takes 10 seconds to start...

    > Every Java application, desktop or otherwise, I have written has been very snappy, very responsive.

    Once they are up and running that may be. But the start-up time is always terrible, and it seems to be getting worse with every new version of Java, even the ones that promise more speed.

  161. Re:Kill it Oracle by angel'o'sphere · · Score: 1

    Says a lot. There are still plenty of platforms where assembler is REQUIRED. Furthermore, on others, even where higher level languages, such as C, are available, to access certain hardware features are still only available via direct assemble and/or machine code.

    Sorry, that si completely incorrect. Everything I can do with assembler, I as well can do with C/C++ or Modula 2 even. Except emitting the INT xyz opcode which is *perhaps* required for something.

    I'm not really sure people know the difference between assembler and machine code ... there are far to many strange posts using the words ;D

    I saw a post on stackoverflow lately where people talked about displaying java byte code operations by reading the class file and showing its opcodes. Some guy strongly argumented this was not "disassembling" as it only translated a byte into a mnemonic ;D

    --
    Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  162. Re:"Java 7: What's In It For Developers" by jordan_robot · · Score: 1

    This is your sense of humor calling to tell you -- calm down, its just a joke. Jeez-luise.

  163. Re:"Java 7: What's In It For Developers" by mrmeval · · Score: 1

    OK this is not fanboi spew it is succinct and informative and told me what I'd want to know. It's not the masturbatory glee of the article that tried to slather me with vapid goo.

    Thank you.

    --
    I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
  164. The new Java 7 resource statement by warrax_666 · · Score: 1

    The new Java 7 resource statement does something more useful here. It catches the exception and attaches the stack trace to the original exception (if there was one). If there wasn't a pending exception when the close failed, it actually throws.

    That's not something which can be done in C++ because destructors (as you say, and of course, I knew before asking :)) cannot throw. ... but this also means that if a file fails to close() during normal RAII (perhaps because of a failing flush), there is absolutely no way to tell the user code. So you end up with subtly broken behavior.

    In Java (7 or earlier) your code WILL get an exception and won't fail silently. ... and that is why RAII is broken (in C++ at least).

    --
    HAND.
    1. Re:The new Java 7 resource statement by shutdown+-p+now · · Score: 1

      The new Java 7 resource statement does something more useful here. It catches the exception and attaches the stack trace to the original exception (if there was one). If there wasn't a pending exception when the close failed, it actually throws.

      That's not something which can be done in C++ because destructors (as you say, and of course, I knew before asking :)) cannot throw. ...

      Destructors in C++ can throw. You're going to break a lot of libraries if you use them with destructor-throwing classes, but you can make it work if you really want. The language lets you do this, and the behavior is well-defined (even if you throw while unwinding). You can even check for std::uncaught_exception, and implement something like the logic you've described for Java 7 (i.e. only throw if safe), though you wouldn't be able to chain exceptions directly.

    2. Re:The new Java 7 resource statement by warrax_666 · · Score: 1

      I was basing my information on this:

            http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.9

      but apparently I hadn't read it thoroughly enough :). Good to know that it's a least technically possible.

      Still, even if it is technically permissible to throw in destructors, it seems too fraught with danger to actually contemplate seriously. I wonder if the standard fstream classes do something like this if running in "exception mode"...

      --
      HAND.
  165. Re:Improvements by silentcoder · · Score: 1

    I gave two examples in other posts replying to this one. Read more.

    --
    Unicode killed the ASCII-art *
  166. Re:One day we will be done with java... by FlyingGuy · · Score: 1

    I guess you think it stylish to use profanity, but since you are posting as AC I suppose you can get away with that.

    Advancements in given programming language are great, advancements that encourage both laziness and a lack of attention to detail are worthless.

    Is this what we have come to? Writing languages where programmer laziness and lack of attention to detail is heralded as the next great thing?

    Someone mentioned programmers saying "High Level Languages" replacing assembler is bad? No that is not bad, it is a better means of programming when absolute metal level control is not required.

    NO STATEMENT I MADE even attempted to assign any attribute to myself resembling anything like or even alluding to perfection.

    Was it a true error of units that sent a billion dollar spacecraft into the surface of mars or was it someone who replied on the framework or the RTL working all that out for them? Could one ascribe that oversight as a lack of attention to detail? I think so, but that is just my opinion for whatever someone else things its worth.

    It wasn't as if moving from assembler to C required less attention to detail, it simply made writing the code easier to understand 6 months later and took care of the really really love level things for you.

    I have found many many bugs in my own code where I forgot to close a file before exiting and have lost data because the files contents were not flushed to disk and then properly closed and I found those bugs and fixed them before the code went out my door.

    How much more will we push Moore's Law by adding yet more and more and more code to do things we as programmers should just remember to do? At what point will it take a machine with two quad core processors and 12 gigs of ram to run a simple program? Is there no limit to the lengths that we will go to take up the slack for basic laziness and lack of attention to detail so that some slack jaw can write code that will work to say nothing of having excellent performance?

    Vernon D. Buerg (rip) wrote fast tiny programs that did big jobs and he did it elegantly. I shudder to think what kind of monster it would take to duplicate even LIST in Java.

    M point is this. Programming takes attention to detail, it takes concentration, it takes keeping track of what you use and giving it back when you are done with it, not just skipping on to the next thing and saying "The RTL will take care of that, no need to waist my time on doing things like that.".

    And yeah I have been around for a long time and I can tell by some of the low ID's replying that some of you have been around for a while as well and could see where you want to forget as many of the details as you can because of deadlines and this that or the other. Yet at the same time I see those same low ID numbers bitch and moan about bad code, programs that just blow up when you least expect it. When you bitch about that look in the mirror and tell yourself that you asked for it because you did when you advocate for things that are just automatic because really when you think about it there is not much in this world that works well 100% of the time automatically.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  167. Re:One day we will be done with java... by FlyingGuy · · Score: 1

    If programming were easy everyone could do it. Well it is... Sorta... and everyone can sorta do it they all just can't do it correctly and well.

    Yup dealing with those is a PITA but you knew the job was dangerous when you took it aye?

    For years I have used the same bit of code to open and close files, streams, etc. One function to open one function to close and they have yet to fail me. The logic for opening is pretty simple, if you can't open it you report back and in certain very specific instances you have to bail out with a meaningful error message. Closing is pretty straight forward as well. If you cant release a resource ( close a file or what not ) then something is pretty drastically wrong and again time to bail out meaningful error message instead of a couple hundred lines of java stack trace which is practically meaningless to the end user.

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  168. Re:Improvements by Raenex · · Score: 1

    You talked about command line apps, and that's only one example, unless you are talking about "particularly the RoR setup beats it hand's down though", which I find unbelievable unless you've got a cite.

    As for the Unix command line, I'm willing to bet Java would do fine. Files are all cached in memory these days.

  169. Re:Improvements by silentcoder · · Score: 1

    And if you think file access time has anything to do with java's slower startup times you are an idiot not worth debating with. File access is handled by the OS, whether the intermediary layer is a python interpreter or a JVM will make no difference to the time it takes too access files (the only thing affected by caching) - since neither does it (indeed neither CAN do it - it's a kernel-space activity).
    The reasons why java slows down with library loads is completely unrelated to file caching - and has been clearly spelled out by other posters, it relates to how java loads the libraries into the JVM's memory base.

    I also pointed out another problem - JVM's cannot share resources very efficiently with one another - notably two java apps that load the same library cannot gain full effect of copy-on-write. This means the library must be copied into memory TWICE, always. Both compiled and interpreted languages however do get copy-on-write and the library once loaded is already loaded for ALL programs that need access to it, only in the event that a program changes something in the library's own memory space does that chunk get copied into private memory and even then it's a memory-to-memory copy.

    This is one reason why java is among the worst memory hogs around. I know it's become fashionable to treat ram as infinite and not part of performance but this is false - memory is always constrained - and java uses up more of it.
    Even high-level enterprise systems have a limit of memory and it's often the first resource constraint reached. Long before CPU runs out even big iron servers are pushing RAM usage limits. I speak as somebody whose job i involves working on just that problem.

    On a server with maxed out ram, I can show how 9/10 times 95% of the ram is tied up by the java portions of our stack - not the mod_perl or python parts (and this while java is the smallest part of the stack - even if you include glassfish as part of the java stack).

    In any environment where the task of the applications require significant amounts of memory to be allocated, Java will perform worse than any other language because it will start swapping out first.

    In benchmark tests where all things are optimal and all you measure is CPU times of execution and such - yes java outperforms python or RoR. In the REAL world where even 32 gigabytes of memory gets used up by big database apps during normal operation sometimes, java is frequently slower.
    It's just a fact - first to swap out = last to finish.

    Now I just hope I explained it in simple enough terms for somebody who thinks disk-caching has anything to do with why java has a slower start time than python apps. And even if it had you're wrong. File caching makes disk access more efficient, it sure as hell doesn't make it unimportant. At best it makes the files that are used the most accessed faster, it will never be so perfect that you can completely ignore seek times when building high-performance applications, and no programmer who does that for a living ever would.

    --
    Unicode killed the ASCII-art *
  170. Re:Improvements by Raenex · · Score: 1

    And if you think file access time has anything to do with java's slower startup times you are an idiot not worth debating with.

    http://en.wikipedia.org/wiki/Java_performance#Startup_time

    "It seems that much of the startup time is due to IO-bound operations rather than JVM initialization or class loading (the rt.jar class data file alone is 40 MB and the JVM must seek a lot of data in this huge file).[25] Some tests showed that although the new Split bytecode verification technique improved class loading by roughly 40%, it only translated to about 5% startup improvement for large programs.[58]

    Albeit a small improvement it is more visible in small programs that perform a simple operation and then exit, because the Java platform data loading can represent many times the load of the actual program's operation.

    Beginning with Java SE 6 Update 10, the Sun JRE comes with a Quick Starter that preloads class data at OS startup to get data from the disk cache rather than from the disk."

    [25]: ""At the OS level, all of these megabytes have to be read from disk, which is a very slow operation. Actually, it's the seek time of the disk that's the killer; reading large files sequentially is relatively fast, but seeking the bits that we actually need is not. So even though we only need a small fraction of the data in these large files for any particular application, the fact that we're seeking all over within the files means that there is plenty of disk activity. "

    Both compiled and interpreted languages however do get copy-on-write and the library once loaded is already loaded for ALL programs that need access to it, only in the event that a program changes something in the library's own memory space does that chunk get copied into private memory and even then it's a memory-to-memory copy.

    You must be speaking of mod_perl in particular, because by default if you run two separate interpreters in two separate processes they will not share libraries unless they are native .so libraries.

    And if it's a server you're talking about, then there's only one JVM anyways running multiple threads.

    On a server with maxed out ram, I can show how 9/10 times 95% of the ram is tied up by the java portions of our stack - not the mod_perl or python parts (and this while java is the smallest part of the stack - even if you include glassfish as part of the java stack).

    Java EE servers aren't designed to run as a small footprint because it takes an "everything and the kitchen sink" design. That said, if you are eating up all the ram on the server it's because of your app code, not Java.

    At best it makes the files that are used the most accessed faster, it will never be so perfect that you can completely ignore seek times when building high-performance applications, and no programmer who does that for a living ever would.

    Only if your "high performance application" entails starting up a new process every time that won't be in the cache.

  171. Re:Improvements by silentcoder · · Score: 1

    You do realize that the cache is in MEMORY right ? The SAME memory where applications and data has to live ? So you realize that the first thing the OS does when memory use gets high is to shrink the cache ?
    When the load on your apps from having ten-thousand concurrent connections each doing heavy-load transactions is pushing a 32Gb ram server to 95% memory use, for all matter of practice there IS no cache. This is why programmers who write the kind of software that has to perform under these kinds of loads and don't get the benefit of running on large clusters (and that is how it is in some fields) actually don't count on caching. In fact they base their performance metrics on worst-case-scenario (that would be zero cache and the highest possible seek and read times for the hardware types).
    Since many of these servers also need 3-5 year uptimes hardware upgrades are infrequent and that means they are not reading from SSD's.

    That's the real industry world - both my previous and current employer are in business that has to design around those kinds of constraints. In both cases java is very powerful and useful in many ways but it's the biggest single performance problem because these assumptions that other programmers can make don't apply in the world of high-vollume enterprise management systems.

    So now I've given you TWO use-cases where java is not the optimal performing tool. That doesn't mean it's not powerful or useful, in both cases it gets used DESPITE that because the overall software stack is better with it than it would be without it and you can design around the performance issues, but make no mistake what I DO for a living is design server and OS platforms for high-vollume, heavy load applications to operate in. I know from daily experience what resources get used first, and I've done this on multiple stacks by different teams in different companies so I know that the problem exists across many types of applications.

    You can argue theory as much as you want - I am telling you in the real world, it doesn't work that way. In the real world uptime requirements beat upgrade requirements EVERY TIME. Performance bottlenecks need to be dealt with and memory is ALWAYS the first to go and even when only 5% of the stack is written in java it's always chewing 85% or more of the memory.
    None of this is meant to say java is bad, it's an excellent platform for many things - but to just blatantly assume that it will always outperform every other non-compiled language in every use-case is thoroughly naive.
    I'm not talking from education, generic benchmarks or all-things-equal studies here. I am talking about what I get paid to find sollutions to in the real world every day for the past 5 years.

    Making java not kill servers practically IS the job I get paid very handsomely for because it's a bloody hard job.

    --
    Unicode killed the ASCII-art *
  172. Re:One day we will be done with java... by TheTurtlesMoves · · Score: 1

    I wish i could use lisp for my day job. Unfortunately I can't.

    --
    The Grey Goo disaster happened 3 billion years ago. This rock is covered in self replicating machines!
  173. Re:One day we will be done with java... by LizardKing · · Score: 1

    Have you tried using Mono on Mac OS X? I have, and it's alpha quality. Also, Windows Forms has been superseded by WPF - which is far less painful to use than Forms - but isn't supported by Mono.

  174. Re:One day we will be done with java... by DrXym · · Score: 1

    It's not a case of "if programming was easy...". Programming is already hard enough without a language throwing spanners at your head all the time. Java is a good language but it has some well publicized annoyances, long winded syntax and pitfalls. Anything that reduces bloat & boiler plate and reduces causes of bugs is a good thing. The problem is that Java the language isn't developing fast enough and Sun / Oracle have been loathe in many instances to implement things as best they could, e.g. generics.

  175. Re:One day we will be done with java... by Crag · · Score: 1

    Preventing mistakes is nice, but the best reason to delegate resource control is code clarity. Allocating and freeing resources is something that has to be done all the time, like moving data in and out of registers in a CPU. We didn't move from ASM to C just to save us from mistakes in register allocation. We did it to save us from tedium and allow us to focus on new problems once we'd figured out how to generalize the old ones enough to hand them off to compilers. Memory and handle allocation is a solved problem. There are multiple competing solutions (reference counting, mark and sweep, etc), but it doesn't matter much which one your compiler/library/interpreter uses because unless you're writing a compiler/library/interpreter, that's not what your project is about.

    So yes, humans are fallible, but taking control out of their hands is not the greatest benefit of higher level languages. The greatest benefit is increases in expressiveness.

  176. Re:Improvements by Raenex · · Score: 1

    You do realize that the cache is in MEMORY right ? The SAME memory where applications and data has to live ? So you realize that the first thing the OS does when memory use gets high is to shrink the cache ?
    When the load on your apps from having ten-thousand concurrent connections each doing heavy-load transactions is pushing a 32Gb ram server to 95% memory use, for all matter of practice there IS no cache.

    That's quite ridiculous. Nobody with a clue runs their server to 95% memory capacity, and even if they did, the cache required for a single JVM is going to be on the order of 100MB, not gigs.

    And if you're talking 10,000 concurrent connections, startup time and caches are not the issue. This isn't a problem with Java, it's a problem with your app. You're not going to magically shrink the memory requirements where you are pushing the limits of 32 gigs by switching from Java to Perl.

    but make no mistake what I DO for a living is design server and OS platforms for high-vollume, heavy load applications to operate in

    So you say, but it doesn't mean you actually are an expert at it. Everything you've said so far leads me to believe the opposite.

  177. Re:Improvements by silentcoder · · Score: 1

    >That's quite ridiculous. Nobody with a clue runs their server to 95% memory capacity, and even if they did, the cache required for a single JVM is going to be on the order of 100MB, not gigs.

    Oh I agree, but if the customers want a system that can handle connections from 10000 users at a time - who am I to tell them they can't do it ? My job is to make sure it doesn't fall over, and since it never does - that's why I get called an expert.

    >So you say, but it doesn't mean you actually are an expert at it. Everything you've said so far leads me to believe the opposite.

    That's because your experience is obviously ... a bit more limited. When your customers are mostly the world's largest telcos - that's what you're dealing with. A server gets put down and is expected to stay stable even if it's pushed to 100% memory at times, and not upgraded for 3 to 5 years. That's the reality of the business. I don't like it, I would LOVE to agree with you - I don't get to say that.

    At least in my new job those servers are running linux, the previous job had an overlapping customer base - but those servers were mostly running 10 year old versions of Unix, hell I actually had to maintain two original 30 year old DEC Alpha's - indeed being run to maximum capacity.
    These people don't overbuy, if they need 8Gb of ram for a machine, they expect it to be using 8Gb. They will not buy 10. It's not how they operate. There's good money in making things work despite that.

    I'm tired of arguing with somebody whose view is so limited. You know one side of IT and don't realize how truly pervasive it is - it operates in many places and a lot of us deal with worlds where we don't get ideal setups to support us. We cope with the shortcomings and make things work anyway. I would love to put 64Gb of ram in a server if I know the average use will be 30Gb. The reality is that the only reason my customers even gives me the 2Gb buffer is because 32Gb is the LOWEST you can go over 30Gb.

    Get real dude, we don't all get to design hardware around software requirements. Many of us are designing software and OS configurations around hardware limitations.

    --
    Unicode killed the ASCII-art *
  178. Re:Improvements by Raenex · · Score: 1

    Oh I agree, but if the customers want a system that can handle connections from 10000 users at a time - who am I to tell them they can't do it ?

    Who said not to? That doesn't mean you push the server to 95% memory capacity where a small amount of variation will put you over 100%. Either get more memory, another server, or figure out why you are using so much memory. Blaming the JVM footprint when you've got 32GB while also talking about Perl tells me that you just don't know what you are talking about.

    A server gets put down and is expected to stay stable even if it's pushed to 100% memory at times

    This is truly idiotic. Even the kernel has variable memory usage. Once you go over 100% your machine is going to start thrashing and your performance is going to go all to hell.

    That's because your experience is obviously ... a bit more limited.

    Why, because I'm not huffing and puffing like you are? I judge you on your technical statements, not some e-peen Slashdot resume.

  179. Re:Where is J7 Update 1 ? by mark_dot · · Score: 1

    I noticed the same thing. According to http://blogs.oracle.com/java/entry/java_7_questions_answers, the fix is only in "current builds of JDK 7 Update 1". I imagine you can download it from the OpenJDK site somehow, but it does not seem that JDK 7 Update 1 has actually been released yet.