Slashdot Mirror


Java Gets New Garbage Collector, But Only If You Buy Support

An anonymous reader writes "The monetization of Java has begun. Sun released the Java 1.6.0_14 JDK and JRE today which include a cool new garbage collector called G1. There is just one catch. Even though it is included in the distribution, the release notes state 'Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.' So the Oracle touch is already taking effect. Will OpenJDK be doomed to a feature-castrated backwater while all the good stuff goes into the new Java SE for Business commercial version?"

114 of 587 comments (clear)

  1. Seriously Java? by jlechem · · Score: 5, Insightful

    You used to be cool.

    --
    Hold up, wait a minute, let me put some pimpin in it
    1. Re:Seriously Java? by Anonymous Coward · · Score: 2, Insightful

      Too cool for its customers.

    2. Re:Seriously Java? by Lord+Ender · · Score: 4, Insightful

      So long as they publish the spec, we can't accuse them of being proprietary. So long as the free version is superior to other similar free technologies, they will still be the market leader. Sounds like they know what they're doing.

      --
      A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
    3. Re:Seriously Java? by __aaclcg7560 · · Score: 5, Funny

      Garbage in, garbage out.

    4. Re:Seriously Java? by JonTurner · · Score: 5, Funny

      Write once. Pay everywhere.

    5. Re:Seriously Java? by patro · · Score: 2

      You used to be cool.

      Really? When?

    6. Re:Seriously Java? by bnenning · · Score: 3, Funny

      Very briefly around 10 years ago, when it was a clear improvement over C++ and hadn't yet been infested by architecture astronauts.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    7. Re:Seriously Java? by theeddie55 · · Score: 4, Interesting

      java was cool when it was a great idea, then it was implemented. it has never really been all that cool since then.

    8. Re:Seriously Java? by clarkkent09 · · Score: 5, Interesting

      As per release notes, this is an experimental feature. It may be that Sun intends to provide it only to paid customers or it may be that they want to make sure you don't use it in "production" environment until it's ready and then whine that Java is buggy if it doesn't work 100%.

      I don't know which is true but the second possibility seems far more likely to me, making this story completely pointless and unfair - but hey this is slashdot.

      Btw, off topic but is it just me or the subjects in replies are showing up as white text on white bg in Firefox but look ok in IE. I even tried in on another pc and same thing.

      --
      Negative moral value of force outweighs the positive value of good intentions.
    9. Re:Seriously Java? by jd · · Score: 2, Funny

      That was back when it was called Oak, right?

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    10. Re:Seriously Java? by binarylarry · · Score: 2, Insightful

      Right, Java wasn't ever cool, which is why every major software company seems to be scrambling to make their own Java style platform (.NET, the new Flash stuff, etc).

      --
      Mod me down, my New Earth Global Warmingist friends!
    11. Re:Seriously Java? by maxume · · Score: 5, Informative

      Java and Javascript are only nearly identical in that they both contain Java in their names.

      Javascript is much closer to Ruby than it is Java (but the built in objects aren't generally as rich, and people scream and whine about the prototype based object system).

      --
      Nerd rage is the funniest rage.
    12. Re:Seriously Java? by 1729 · · Score: 4, Insightful

      You could also dispense with having to maintain two nearly-identical languages (Java and Javascript)

      Huh? How are Java and Javascript nearly identical?

    13. Re:Seriously Java? by Anonymous Coward · · Score: 5, Funny

      Huh? How are Java and Javascript nearly identical?

      They were both slow when they came out, they're both slow now, and they both have a bunch of people saying "oh, but it's faster now!"

    14. Re:Seriously Java? by turgid · · Score: 3, Informative

      Please provide me one example of a free/OSS platform implementation of a commercial product that is inarguable BETTER than the original proprietary version

      Linux > Unix.

    15. Re:Seriously Java? by Anonymous Coward · · Score: 2, Informative

      It gets better. (Or worse, depending on your point of view.)

      This version also adds a blacklist to the JRE, so Oracle can ban people from running various applications.

      Just what I want to do, give Oracle the power to randomly stop applications I use from running. I wonder how long it will take for Eclipse to "accidentally" make it onto the blacklist?

      Oh stop.

      Support for blacklisting signed jar files has been added to 6u14. A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that's on the blacklist. By default, blacklist checking is enabled. The deployment.security.blacklist.check deployment configuration property can be used to toggle this behavior. .

      You guessed it - the blacklist applies to applications you can launch from untrusted sources. Go back to thy cave, troll.

    16. Re:Seriously Java? by shutdown+-p+now · · Score: 5, Insightful

      So long as they publish the spec, we can't accuse them of being proprietary.

      Yeah, just like .NET, right?

    17. Re:Seriously Java? by joelgrimes · · Score: 4, Funny

      Huh? How are Java and Javascript nearly identical?

      In the same way lightning is nearly identical to lightning bugs.

    18. Re:Seriously Java? by shutdown+-p+now · · Score: 3, Informative

      This version also adds a blacklist to the JRE, so Oracle can ban people from running various applications.

      It's not nearly as sinister as it sounds, at least judging by release notes:

      "Support for blacklisting signed jar files has been added to 6u14. A blacklist is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications. A system-wide blacklist will be distributed with each JRE release. Java Plugin and Web Start will consult this blacklist and refuse to load any class or resource contained in a jar file that's on the blacklist. By default, blacklist checking is enabled. The deployment.security.blacklist.check deployment configuration property can be used to toggle this behavior."

      So it's opt-out, but configurable. You're still free to run whatever you want.

    19. Re:Seriously Java? by Zardoz44 · · Score: 2, Insightful

      Please provide me one example of a free/OSS platform implementation of a commercial product that is inarguable BETTER than the original proprietary version

      Linux > Unix.

      Git > Sourcesafe.

    20. Re:Seriously Java? by moonbender · · Score: 4, Insightful

      Great, Ruby will fit right in.

      --
      Switch back to Slashdot's D1 system.
    21. Re:Seriously Java? by wed128 · · Score: 3, Informative

      It's all a fad.

      Soon we'll be back to paper tape and punchcards. damn whipper-snappers with your fancy garbage collection.

    22. Re:Seriously Java? by shutdown+-p+now · · Score: 2, Insightful

      Making it technically opt-out if you're a developer. But no normal user will figure out that they need to disable it in the first place, let alone how to disable it.

      A "normal user" rarely starts a Java application by double-clicking a .jar - instead, he'll usually use the developer-provided .exe wrapper which will start up the JVM properly configured (and to which the installer for the application will create a shortcut in Start Menu and/or on the desktop). That wrapper can set properties the way developer wants, including this particular one.

      On a Unix system, the wrapper will most likely be a shell script instead, in which case - as another AC has posted already - it'd just use -D, as with any other property:

      java -Ddeployment.security.blacklist.check=false -jar foo.jar

    23. Re:Seriously Java? by flydpnkrtn · · Score: 3, Informative

      This is a very common misconception (at least in my humble experience...)

      Javascript was born at Netscape at a time when the buzzword Java was cool and hip... it really should be called EMACSscript but that's not cool and hip enough

      From the Wikipedia article:
      'JavaScript, despite the name, is essentially unrelated to the Java programming language even though the two do have superficial similarities. Both languages use syntaxes influenced by that of C syntax, and JavaScript copies many Java names and naming conventions. The language's name is the result of a co-marketing deal between Netscape and Sun, in exchange for Netscape bundling Sun's Java runtime with their then-dominant browser. The key design principles within JavaScript are inherited from the Self and Scheme programming languages.

      "JavaScript" is a trademark of Sun Microsystems. It was used under license for technology invented and implemented by Netscape Communications and current entities such as the Mozilla Foundation."'

    24. Re:Seriously Java? by flydpnkrtn · · Score: 2, Insightful

      Hah whoops please `sed s/EMACS/ECMA/` in that last post... everyone knows EMACS has its own scripting language (it is an operating system, after all)

    25. Re:Seriously Java? by Anonymous Coward · · Score: 3, Insightful

      Java "stopped being cool" when your average C/C++ alleged hotshot realised other developers who were not as good at fancy pointer tricks but better at CS could get 10 times the performance within the same deadline by focusing on algorithms instead of fixing memory leaks.

    26. Re:Seriously Java? by ahabswhale · · Score: 2, Interesting

      Wrong. And unlike you, I can actually backup my statement.

      Write once, run anywhere = very cool. Always backwards compatible = very cool. Much cleaner than C and C++ code that it was competing with = very cool. It does all of this while offering performance superior to most languages.

      There are newer nifty-neato languages out there but Java is a workhorse language that is still extremely valuable to corporations around the world. Sun actually has a pretty remarkable achievement on their hands, and I can assure you that I have no problems criticizing Sun.

      --
      Are agnostics skeptical of unicorns too?
    27. Re:Seriously Java? by amRadioHed · · Score: 4, Insightful

      Linux is better than some Unix's in some circumstances. It is not however an inarguable matter of fact. ZFS is just one possible example where an argument could be made that Solaris is better.

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    28. Re:Seriously Java? by dedazo · · Score: 5, Interesting

      I don't know about Java, but I've been playing with Google's V8 and that sucker is fast, at least on Windows.

      --
      Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
    29. Re:Seriously Java? by MikaelC · · Score: 2, Insightful

      Firefox > Internet Explorer

    30. Re:Seriously Java? by nanoflower · · Score: 4, Insightful

      Could you please provide me with examples of why Linux is better than Unix? Keep in mind that there are many varieties of Unix ranging from the paid kind to the free kind and that most of what people like to think of as Linux isn't really part of the OS but just open sourced programs that will run on many systems including those based on Unix. I'm not saying that Linux is bad, just that it seems difficult to really say one is better than the other since they are so intertwined.

    31. Re:Seriously Java? by GigsVT · · Score: 2, Insightful

      Yeah, in some fantasy world where Java programs just work.

      More realistic is that you get some mess of stuff with nothing obviously executable, and then once you figure out what thing you are supposed to run, it complains about something called a CLASSPATH and refuses to run.

      --
      I've had enough abrasive sigs. Kittens are cute and fuzzy.
    32. Re:Seriously Java? by wideBlueSkies · · Score: 3, Funny

      Emacs > vi

      --
      Huh?
    33. Re:Seriously Java? by SplashMyBandit · · Score: 5, Informative

      You're a funny guy but obviously have zero idea about what you are talking about. It's a bit aggravating that ignorant folk still come out with the same old 'slow' mantra and unfortunately even more ignorant folk buy into it. That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).

      I used to eschew Java for the speed of C++ but now I've completely switched to Java for most development tasks (apart from some C glue-code [JNI] when I need to integrate some scientific instrument or another). I'm doing instrument control, image processing and analysis and I need both reasonable latency, multithreading support, and every performance cycle I can get, and yet Java is plenty fast enough for me (and even embedded devices these days have relatively large amounts of RAM this is far less of an issue than it used to be).

      Seriously Java is very fast these days. Graphics2D is all done in Direct3D or OpenGL shaders, the VM is very optimised and quite often approaches FORTRAN (which is faster than C). Don't believe me? check out the links below.

      So please, next time stop with the FUD (that used to be marginally true 5 years ago) and start with an open mind.

      • From http://en.wikipedia.org/wiki/Java_performance#Use_for_High_Performance_Computing
        "However, High Performance Computing applications written in Java have recently won benchmark competitions. In 2008, Apache Hadoop, an open source High Performance Computing project written in Java was able to sort a terabyte of integers the fastest.[46]"
      • INRIA (French scientifc Institution) report on High Performance Computing with Java [Summary: Java approaching FORTRAN for speed, although some network intensive speed bumps still remaining]
        http://hal.inria.fr/inria-00312039/en
      • From http://blogs.sun.com/jag/entry/current_state_of_java_for
        Current State of Java for HPC

        At the last JavaOne I did a walk-on talk during the AMD keynote where I talked about how incredible HotSpot's performance had become - beating the best C compilers. I ended my talk with a joking comment that "the next target is Fortran". Afterwards, Denis Caromel of Inria came up to me and said "you're already there". He and some colleges had been working on some comparisons between Java and Fortran for HPC. Their final report Current State of Java for HPC has been made available as a Tech Report and makes pretty interesting reading. There are a lot of HPC micro benchmarks in it which look great. Thanks! Permalink Comments [3]
    34. Re:Seriously Java? by jlarocco · · Score: 4, Insightful

      I don't buy it.

      The first clue is that the speed of the C++ version doesn't match the C version. Of course there's a difference between "good C++" and "good C", but if your goal is speed then you're not typically concerned about those differences.

      Second, reading through the scienceblog.com article, the author calls the (unavailable) code "carefully optimized," yet he claims the C code is slower than the others because of pointer aliasing. However, any modern C compiler has pragmas and compiler optimization flags that tell it to assume no aliasing occurs. How carefully could he have optimized the code if he didn't even bother turning on compiler optimizations?

      I don't think the scienceblogs guy really knows enough about C and C++ to back up his claim.

    35. Re:Seriously Java? by rubycodez · · Score: 2, Interesting

      device support? at least the free Unix (known as the BSD) are really catching up well to Linux with that.

    36. Re:Seriously Java? by ToasterMonkey · · Score: 2

      Yah, Solaris is totally behind Linux. Oh wait, it isn't.

    37. Re:Seriously Java? by Tranzistors · · Score: 2, Interesting

      [Open]Solaris in some aspects might be better, but it is OSS anyway.

    38. Re:Seriously Java? by jgrahn · · Score: 3, Insightful
      Grandparent: "using std::vector::at and std::iterator to access it in c++, then c++ would be significantly slower"

      Oh, I know - and I can think of a dozen similar ways to make the C++ version slower than the C version. But nobody with any sense would do that if they were trying to speed up the code as much as possible.

      If you're thinking of vector::at() you're possibly right. But a vector::iterator doesn't have to be slower than a pointer, and avoiding it for fear of speed issues would be stupid. I can imagine some C++-y things being slower (std::copy compared to memcpy, in some situations) but not simple iterators.

      In fact, when I ran the code below across a 200,000 element array/vector, the std::vector version was 10% faster. (Note that I didn't benchmark array indexing; I am so used to iterators that [begin, end) is the style which feels natural to me even when I use raw pointers.)

      int bencharray(int * const a, int * const b)
      {
      int val;
      for(int i = 0; i < 50000; ++i) {
      int * p = a;
      val = random();
      while(p!=b) {
      *p++ = val++;
      }
      }
      return val;
      }

      int bench(std::vector<int>& v)
      {
      const std::vector<int>::iterator a = v.begin();
      const std::vector<int>::iterator b = v.end();

      int val;
      for(int i = 0; i < 50000; ++i) {
      val = random();
      std::vector<int>::iterator p = a;
      while(p!=b) {
      *p++ = val++;
      }
      }
      return val;
      }

      So I still don't understand how that benchmarking guy (who knew C++ well!) managed to make it three times slower than C. We should probably ignore his results altogether, since his source code is lost.

    39. Re:Seriously Java? by julesh · · Score: 2, Interesting

      That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).

      Or programs that need floating point. Several of the commonly used functions in java.lang.Math are implemented by processor specific instructions, e.g. Math.exp(), yet Java refuses to use them, instead preferring an integer-based approach that's 5-10 times slower, but maybe a bit or two more accurate. Despite repeated requests, no option is as yet available to use them anyway in applications where that accuracy is not required. This makes many high-performance computing systems (particularly neural nets) substantially slower on Java than other systems.

  2. Let the man answer please... by SurfMan · · Score: 3, Insightful

    With the JavaOne starting this week, it might be a nice opening question on day one... "What the hell are you thinking, mister Schwartz??"

    1. Re:Let the man answer please... by AKAImBatman · · Score: 3, Funny

      "What the hell are you thinking, mister Schwartz??"

      I'm thinking he turned to Ellison and said... "Let the Schwartz be with you!"

  3. Garbage collector? by smooth+wombat · · Score: 4, Interesting

    As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.

    --
    We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
    1. Re:Garbage collector? by gubers33 · · Score: 5, Informative

      Garbage collection is the process freeing objects that are no longer referenced by the program.

      --
      Just because you are wrong and I called you out on it doesn't mean I am a Troll.
    2. Re:Garbage collector? by whiledo · · Score: 2, Funny
      --
      Moderators: Before moderating a comment Insightful/Informative, check to see if a child post has already refuted it.
    3. Re:Garbage collector? by HBI · · Score: 5, Informative

      Java hides the details of memory allocation from the programmer. Objects, strings, etc use memory. When they are first used, Java makes sure that the appropriate amounts of memory are allocated for the item in question. When these items are no longer in use, the garbage collector finds them and frees the memory so that it can be used for other parts of the application.

      VB is another place where a garbage collector would be found. Ditto .NET.

      --
      HBI's Law: Frequency of calling others Nazis is directly correlated with the likelihood of the accuser being Communist.
    4. Re:Garbage collector? by morgan_greywolf · · Score: 2, Informative

      Okay, here's a better description: garbage collection is a means of freeing memory by cleaning out old objects (variables, buffers, data structures, code, etc.) the program doesn't need anymore.

      Example: I open a file in an application and work with it. While working with it, the programs allocates buffers (temporary holding places) and data structures and so forth in memory. When I'm done, I close the file. The application needs no longer needs all this data associated with the file, so it calls garbage collection routines to free them up.

    5. Re:Garbage collector? by forkazoo · · Score: 3, Informative

      As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.

      C++ has two important keywords: "new" and "delete." You use new when creating an object, and when you are done with it, you use delete to free up the memory it was using. (And, depending on the object, it may do some special stuff while being deleted, like close network sockets, or write a log entry about how sad being deleted is.)

      Java has a concept of "new," but it doesn't have a "delete." (Well, the concept exists behind the cutain, but programmers never delete things themselves when using Java.) Java assumes that you are more interested in creating stuff, and don't want to be bothered with the minutia of getting rid of it when you no longer care about it. So, the Java run time goes around deleting stuff that seems like it is no longer being used. (Reference count indicates it can no longer be used.) This is called garbage collection. It's a surprisingly tricky, and nuanced process to figure out when stuff should be deleted. You want to be pretty prompt in deleting stuff that is no longer used so it doesn't sit around using memory for no reason. But, you don't want your garbage collector to be so manic about cleaning things up that the actual program doesn't get enough CPU time to get anything done. You also want a garbage collector to be fairly predictable. It's great if it usually has a low overhead, but terribly if it occasionally goes insane and locks everything up for three minutes under some use cases.

      This new garbage collector is a little more sane, a little quicker and a little less manic. For many well written programs, the difference won't be that huge because they shouldn't creating and abandoning enough stuff for garbage collector to really matter. At least, that's my assumption. If I ever actually meet a well written program, I'll be able to verify that. :)

    6. Re:Garbage collector? by KeithIrwin · · Score: 4, Informative

      When computer programs need to keep track of information, they store it in the computer's memory. The information they store is generally arranged into structures. In object-oriented languages like Java, these structures are called objects. Every object has to have its own place in memory, called an address. Two different objects cannot use the same space in memory at the same time. When a program has a new object that it needs to create, it has to know where to put it. To do this, it uses a system which allocates some memory for it. When the program is done with the object, it should be deallocated so that the same memory can later be used for a different object. If objects are not deallocated when they are done being used, then the program will grow to take up more and more memory over time until the computer runs out of memory. This is called a memory leak.

      There are two main scheme for deallocating an object's memory once the program is done with it. Older programming languages use explicit memory deallocation, meaning that when the program is done with an object, it says so. This can unfortunately be somewhat problematic. If a program forgets to say that it's done with an object, then that object never gets deallocated and the program leaks memory. If the program says that it's done with an object when some other part of the program is still using the object, then a new object of a different type might be written over the old object but because the other part of the program doesn't know this has happened, all sorts of odd problems can occur.

      To solve this many newer languages including Java use a technique called garbage collection. In a garbage collecting language, the program does not explicitly say when it is done with an object. Instead the garbage collection system examines the cross-references between different objects to determine whether or not it is still possible for the program to use a particular object. If using it is impossible, then the system will deallocate it. In most systems, the garbage collection doesn't run continually swooping up every new bit of space the moment it becomes available, but instead just runs periodically clearing out anything which has become unusable since the last time it ran.

    7. Re:Garbage collector? by bjourne · · Score: 2, Informative

      A gc (garbage collector) is what programmers use instead of manually handling memory. In non-gc languages such as C programmers have to spend a lot of time being careful not to inadvertently create memory leaks. So programming in languages with gc is generally faster than in those without.

      The drawback is that memory is often handled less efficiently by the gc than by the programmer so the program becomes slower and uses more memory. However that depends on the quality of the gc. It is quite easy to write a gc, but that one probably will have awful performance. Writing a good is harder and takes more time. Writing one with performance that handles memory as good as a skilled programmer handling manual allocation is exceptionally hard and requires man-years in effort.

      It's like a chess engine, most programmers can write one but if you want one that can match a human or even Big Blue then you need to spend some time on it. So from Oracles perspective, it very much makes sense to try and monetize their high performance gc even if it's a shitty move overall. Most chess players has no use for a chess engine stronger than grandmaster level. But there are professional players out there who has a genuine need for a more challenging chess engine and would pay good money for it. In a similar vein most Java programmers can live with the default gc, but some big enterprises will feel they need a better one and pay lotsa $$$ for it even if the performance gain is only 5-10%.

    8. Re:Garbage collector? by drinkypoo · · Score: 4, Funny

      So, which pay-for-answers site do you plan to post the responses on? Or are you feeding a plagiarism detector?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    9. Re:Garbage collector? by mikael · · Score: 2, Informative

      When you create objects to represent information consisting of things like character strings, arrays, lists and hierarchical trees, you make a system call to create a new list of data objects.

      In languages like 'C', this would be like 'malloc( number of bytes) ' or 'calloc( number of bytes)'. You would then have to match every such call with an equivalent 'free( pointer)' to ensure the memory was freed. Failure to do so leads to 'memory leaks' where the memory space is allocated but incorrectly freed (caused by uninitialised pointer variables, missing calls or faulty decision making).

      C++ tried to fix this by having 'new' and 'delete' operators which were intended to be called through the constructor (a function automatically called with the object is created) and the destructor (a function automatically called when the object is destroyed). However, there were times when these functions also needed to be called throughout the lifetime of the object, so memory leak problem crept in again.

      JAVA attempts to fix C++ by eliminating the need for the 'delete' operator. Since every function always belongs to a class, and consequently a data object, data always belongs to a data object. Memory is allocated as before, but when a data object ceases to be in use (return of a function call), it is placed in the garbage area. At periodic intervals, the garbage collector is called and all the allocated memory blocks are collected and freed. The disadvantage is that an application could build up a large amount of "garbage memory" and could freeze for several seconds while this process occurred.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    10. Re:Garbage collector? by nog_lorp · · Score: 5, Insightful

      Substitute "objects" with "memory" and "referenced" with "used", and you might actually reach the intended audience (people who aren't programmers).

    11. Re:Garbage collector? by jeremyp · · Score: 5, Informative

      As a beer drinker, I drink lots of beer. When I was a C++ programmer, I had to make sure I threw away my empty beer cans after drinking the beer. Unfortunately, occasionally, I forgot to do that and pretty soon my room would fill up with empty beer cans so that I couldn't get to the fridge to get more beer out of it.

      However, now I am a Java programmer and I have a servant (a beer can collector) who comes around and clears up the beer cans for me every now and again. I no longer have to worry about throwing them away myself.

      --
      All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
    12. Re:Garbage collector? by gbjbaanb · · Score: 4, Informative

      good analogy - except you forgot some important bits:

      1. you have to ensure you drink all the beer, and not leave any in the can, or the servant will give it a little shake, and think "masters not finished with this one yet, I'd best leave it".

      2. You are never surrounded by a clean room, there are always empty beer cans lying around waiting for the servant to collect them.

      Now, as a C++ drinker, I have a mechanism that help out, every time I go to the fridge to get a beer, I pour it into the glass object and throw the can away immediately - thus never having empty cans lying around, when the glass is empty, I refill and find the empty can problem is a non-issue. (that's such a convoluted analogy for RAII!)

  4. In this day and age of "green" businesses... by thomasdz · · Score: 5, Funny

    Shouldn't we have "recycling collection" instead of "garbage collection"?
    C'mon guys all those big 1MB and 4MB malloc()s are being shipped over to third world countries to be disassembled into bits and bytes. We should be recycling things HERE.... not throwing them away for Java to come and pick up.

    --
    Karma: Excellent. 15 moderator points expire sometime.
    1. Re:In this day and age of "green" businesses... by AKAImBatman · · Score: 3, Interesting

      Shouldn't we have "recycling collection" instead of "garbage collection"?

      Despite the humor, you make an interesting point. Had garbage collectors been invented in the 21st century, they might have been called "memory recyclers" rather than "garbage collectors". Primarily because the GC is actually reclaiming memory for reuse. Yet when the term "garbage collection" was coined, the concept of recycling hadn't yet entered common thinking. Ergo, it was identified with "taking out the trash" rather than "recycling something useful".

  5. Troll? by iamhigh · · Score: 5, Funny

    If you post a troll comment to an article tagged troll, do you get insightful mods?

    In Soviet Russia, article trolls you!

    --
    No comprende? Let me type that a little slower for you...
    1. Re:Troll? by keithjr · · Score: 2, Informative

      Only if the article actually is a sensationalist piece of trolling. Sun is releasing an experimental feature to a subset of customers rather than the entire world. And Oracle does not own Sun yet, since the deal has not even been finalized, and therefore is not making decisions about Java.

      Slashdot, you disappoint me. Again.

  6. This was BEA's model with JRockit by MarkEst1973 · · Score: 4, Interesting

    JRockit has all kinds of monitoring features, memory profilers, and other useful metrics built into the JRE, but you need a license key to unlock them. Core Java was always free. You pay for the value-added stuff.

  7. Perhaps by alexborges · · Score: 5, Interesting

    "Will OpenJDK be doomed to a feature-castrated backwater while all the good stuff goes into the new Java SE for Business commercial version?""

    Perhaps. But now that its GPL, maybe IBM, RH and the rest of Java's stakeholders will get onto making openjdk better than oracle's. Ill sure contribute: this is a strategic need for the foss movement.

    --
    NO SIG
  8. It's "experimental" by ensignyu · · Score: 5, Insightful

    To try G1, specify these command line options:

    -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

    I don't see anything obvious preventing you from using it (no license/support keys?), it's just not recommended since it's experimental. If you're crazy enough to use it on a production server, you better have a support contract so Sun/Oracle can fix any problems that come along. That seems reasonable.

    Although it'd be better if they just said "don't use it for production, period."

    1. Re:It's "experimental" by fatp · · Score: 3, Informative

      It is the tradition of Oracle to distribute software with all functionality (including those separately licensed expensively) and let the user to make sure they don't use unlicensed features.

    2. Re:It's "experimental" by deraj123 · · Score: 4, Insightful

      I don't know...the release notes specifically say:

      Although G1 is available for use in this release, note that production use of G1 is only permitted where a Java support contract has been purchased.

      On the other hand, I was unable to find any specific mention of G1 anywhere in the licensing agreement. However, I did find this:

      Sun grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally Software complete and unmodified for the sole purpose of running Programs.

      If anyone is able to point out in the actual licensing where the quote from the release notes is backed up, I'd be interested. (text near the second quote there did allow for "exceptions" and "supplemental terms" - but I wasn't able to find any pertaining to G1)

    3. Re:It's "experimental" by Anonymous Coward · · Score: 3, Interesting
      For those who need this spelled out:

      1. Distribute working but unlicensed software
      2. Encourage developers to use the software
      3. Audit companies using said software
      4. Profit!

      We've gone through more than one episode that starts with: "shite -- we have to rip out this proprietary Oracle crap or pay another X (usually 6+ figures) per year in licensing fees.

      The more devious method Oracle also uses is:

      1. Package licensed software components into specific products
      2. Change products, moving commonly used components into rarely licensed products
      3. Notify customers right before negotiating new license
      4. Profit!

  9. Oh you Smelly Software Socialists! by Dystopian+Rebel · · Score: 4, Funny

    I just know you're going to make a lengthy complaint thread of this.

    If you would simply put down your Silver Surfer comics, comb the crumbs and insects out of your beards, cut your straggly hair, have a bath and a good scrub, and eagerly learn all the new technologies as our Marketing department invents them (and disposes of the old technologies), we could see the dawn of a New Age of incredibly rich CEOs and VPs who live in mansions, collect cars, race boats and planes, and in general protect the freedoms that your betters fought so hard to establish.

    The meek shall inherit my EULA.

    --
    Rich And Stupid is not so bad as Working For Rich And Stupid.
  10. Pull your head out of your ass by Anonymous Coward · · Score: 5, Informative

    The G1 collector is still a "work in progress" so they are suggesting that you use it *in production* only if you have a support contract with Sun (Oracle?). This is not a big deal. You can still use it, just enable it with "-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC" on the command line...

    1. Re:Pull your head out of your ass by teknopurge · · Score: 2

      The G1 collector is still a "work in progress" so they are suggesting that you use it *in production* only if you have a support contract with Sun (Oracle?). This is not a big deal. You can still use it, just enable it with "-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC" on the command line...

      Your pragmatism and obvious correctness has no place on this site. Good day, Sir.

  11. Prediction by system1111 · · Score: 2, Insightful

    Put a fork() in her she's done!

  12. Tony Soprano in charge by Alzheimers · · Score: 5, Funny

    Meet Vinny and Guido, my business associates in the waste management business.

    You see, it's like this. I gotta eat. My kids gotta eat. Vinny and Guido's families have to eat.

    We know where you live. It's a nice place, big houses, fancy cars. You can afford to eat, very well.

    You wouldn't your neighboorhood to fall victim to all sorts of garbage dumpers, would you? How about a recycling plant, right next to where you work?

    No? Well, I'm sure you'll understand when I say that it is in your best interest to respect our business model. Or else, Vinny and Guido might have to go hungry for a bit. And I assure you, they get very unfriendly when they get hungry.

    Capiche?

    1. Re:Tony Soprano in charge by frank_adrian314159 · · Score: 5, Funny

      That's a real nice production server you got here. It'd be a shame to see something unfortunate happen to it. I mean a server room's a dangerous place, ain' it? You got cables and electricity around and, well... accidents happen, if you know what I mean.

      Especially with garbage lyin' around all over your memory. Pipes could get clogged, tables could fill up, processes could meet an untimely demise... you know what I'm talking about.

      Now for a very reasonable fee, we can see that your garbage is collected regularly. It's a very small fee, once you think about what could happen if you didn't have folks like us around to help you. We'll see that this very nice production server continues to run in tip-top shape. Yes, our small garbage collection fee could help you avoid all sorts of unpleasantness...

      --
      That is all.
  13. It's still experimental by MrEricSir · · Score: 5, Interesting

    Methinks they just want to make damn sure nobody uses this feature in a production environment. This is more of a sneak peek for paying customers who are contractually bound against using this in a production environment.

    If this was included in the standard distribution, then people would use it no matter what the documentation said. And then Sun would be saddled with bug reports and whining.

    --
    There's no -1 for "I don't get it."
  14. Get 'r done takes money by dazedNconfuzed · · Score: 2, Insightful

    The ongoing problem with FOSS is that hard, un-cool, gritty, vital work ultimately takes money to do right. Cool gets projects only so far; money is needed for viable completion.

    --
    Can we get a "-1 Wrong" moderation option?
  15. Re:No malloc( )s by gbjbaanb · · Score: 3, Funny
    whooooosh.

    * <- joke

    o
    -|- <- you.
    / \

  16. Forgive my ignorance WAS:re: Garbage collector? by Brett+Buck · · Score: 2, Interesting

    I know I am profoundly ignorant and as thus should be modded into oblivion, but I don't do any programming where the memory allocation is variable. Is there a good reason are people really relying on hidden mechanisms to manage it? I would think it would be a lot more robust to keep track of allocation and deallocation explicitly, add when you need, and delete when you don't need, and not count on some generic mechanism. I know it happens, I see the memory leaks, but it would seem eminently avoidable.

            Brett

    1. Re:Forgive my ignorance WAS:re: Garbage collector? by publiclurker · · Score: 5, Informative

      While in theory, avoiding memory leaks is easy, in practice, it is rather difficult for anything but the most trivial programs. that's one of the reasons why garbage collection was created in the first place.

    2. Re:Forgive my ignorance WAS:re: Garbage collector? by rdavidson3 · · Score: 2, Informative

      Programming in C gives you more control over managing memory, but the price comes if the programmer is not careful about collecting the garbage up afterwards and you'll end up with the application taking more and more memory and your computer will eventually starting slowing down and could start complaining about not enough memory.

    3. Re:Forgive my ignorance WAS:re: Garbage collector? by geekboy642 · · Score: 4, Insightful

      It would not be more robust.
      The more things you have to pay attention to at the nuts-and-bolts level, the fewer things you are able to pay attention to at the business logic level. The key difference between managed languages like Java and non-managed languages like C, is that the uninteresting grunt work is done for you by the compiler. A vast majority of security flaws are related to programmers thinking exactly like you do. Even if the programmer is very highly skilled, memory management is tedious and difficult, and it is impossible to never make a mistake. Mistakes in memory management lead to segfaults or remote exploits.
      Non-managed languages should be used only when the performance benefits outweigh the dangers.

      --
      Just another "DOJ fascist authoritarian totalitarian bootlicker" -- Zeio
    4. Re:Forgive my ignorance WAS:re: Garbage collector? by hibiki_r · · Score: 5, Informative

      Even in modern C++, memory allocation and destruction is commonly done behind the scenes using reference counting pointers.

      Whenever you are dealing with anything that resembles a complex data structure, making sure that the programmer has to think very little about memory allocation is a huge boon. Programmer productivity across the alst 50 years hasn't changed much, if we look at statements written per month. The main difference is that 50 years ago, our statements did a lot less than they do now. A programmer that doesn't have to think of memory requirements can spend more time thinking about the actual business requirements, and improving the core algorithms.

      Leaving the memory management to a library is also a good way of minimizing the damage that a careless programmer can make. I remember the cost of a bad programmer in a team coding in C: It'd take longer to track his memory leaks, pointer overlaps buffer overruns than it would have taken the more reliable programmers to write the code from scratch. In languages like Java and C#, one has to really be working hard to be a true liability. There's just a lower barrier of entry. In a world that's not filled with uberprogrammers, but barely competent ones, this is a huge boon.

      And that's why few shops making business software would even dare to start a new project in a language without garbage collection: Unless you have quite a special team, a great QA process and are memory constrained, you'll be more productive in a language that is further away from the metal.

    5. Re:Forgive my ignorance WAS:re: Garbage collector? by Thomasje · · Score: 5, Insightful
      The reason why Java has garbage collection has nothing to do with programmer convenience; it is needed in order to make Java's security model work. Without garbage collection, a thread could allocate a chunk of memory and then free it, while hanging on to the pointer -- and then periodically take a look at what shows up in the memory area where the previously freed block used to be. Any Java process running in the same VM would be at risk. This kind of deliberate use of "dangling pointers" is easy to prevent if using garbage collectors, very difficult to prevent otherwise.

      Protecting processes running in the same VM from each other may not seem terribly useful now, but Java was originally designed to be used in embedded controllers, where the JVM would *be* the operating system, and where processes had to be protected from each other without the help of a hardware memory management unit.

      FWIW, I also beg to differ about the difficulty of manual memory management. In C++ it is usually very easy, as long as you're consistent about doing deallocations in destructors. I once had to write a 40,000+ line C++ program, with lots of dynamic memory management going on; once development was complete, I ran a complete test suite under Purify, and found 5, yes, five, memory leaks. Considering that most leaks are the result of mis-handled object ownership, which is an issue that garbage collection does not eliminate in general, you should be careful about your design, *and* use memory analyzers like OptimizeIt, even when developing in a GC environment.

    6. Re:Forgive my ignorance WAS:re: Garbage collector? by vux984 · · Score: 4, Insightful

      would think it would be a lot more robust to keep track of allocation and deallocation explicitly, add when you need, and delete when you don't need, and not count on some generic mechanism.

      Ok... so I allocate object A. Then I allocate object B, C, and D that all reference A but aren't aware of eachother. Then I release D, and don't know whether to release A, so now A needs to have some sort of reference counting mechanism, and I have to remember to use it each time I create or copy or pass a reference to A.

      Or... I can use a language that implements the reference counting stuff for me and implicitly calls it when I allocate new objects, create, copy, or pass references, and expire them as they go out of scope, without me having to write explicit destructors.

      Basically, if you do any sort of remotely complicated object allocation where you are going to need to implement reference counting to keep track of them, you might as well use a garbage collector. That's what it does, it comes thoroughly debugged, and you don't have to waste time implementing and debugging your own.

      So, a garbage collector language is MORE robust (assuming robust means 'more reliable').

      That's not to say unmanaged code doesn't have its place, but in my experience managed code tends to get developed faster and cheaper than equivalent unmanaged code, so it only makes sense to use unmanaged code where you really need the performance or nuts&bolts control. Your typical productivity or business logic application don't. Drivers, real-time systems, etc do.

      As always, use the best tool for the job. C is not always the best tool.

    7. Re:Forgive my ignorance WAS:re: Garbage collector? by Red+Flayer · · Score: 5, Funny

      I ran a complete test suite under Purify, and found 5, yes, five, memory leaks

      Five memory leaks!
      Ah-ah-ah.

      One... two... three... four... five memory leaks!

      Ah-ah-ah.

      Sorry. I have a toddler at home. I couldn't help counting out loud in a silly voice when you mentioned the number 'five' twice.
      br.Now my coworkers are eyeing me even more strangely than usual.

      --
      "Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
    8. Re:Forgive my ignorance WAS:re: Garbage collector? by mario_grgic · · Score: 3, Insightful

      Nice, now try couple of million lines of code, maintained by 50 or so developers of various levels of experience and see how many memory leaks there are then.

      --
      As the island of our knowledge grows, so does the shore of our ignorance.
    9. Re:Forgive my ignorance WAS:re: Garbage collector? by Thomasje · · Score: 2, Informative

      Is there no way to copy the bitwise contents of a pointer into an int in Java, then later copy it back?

      No.

      I find it unrealistic to think that you could prevent deliberate "dangling pointers". That kind of security is what hardware-level memory management is about.

      ...and the Java security just does what it takes to provide that kind of security on devices where hardware memory management is not available.

      Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up, and get a memeory leak every few thousand lines of code.

      True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak... Which is why using a memory analyzer is a good idea *even* in GC environments.

    10. Re:Forgive my ignorance WAS:re: Garbage collector? by lgw · · Score: 2, Interesting

      I find it unrealistic to think that you could prevent deliberate "dangling pointers".

      Which is strange, because languages that do so have been around for ages, and certainly much earlier than Java (e.g. Smalltalk is one).

      Most such languages have an "out" somewhere, so that you can use the language to call C system APIs, or use device-mapped hardware, because that's all that commercial software *did* in the olden days.

      Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up

      Why?

      Of course, idiomatic C++ is not to close file handles in destructor of every class that needs one, but to write a class encapsulating a file handle (which does close it in its destructor), and then use it in all other classes that need to own a file handle.

      Yes, that was my point. Don't free resources in the destructor of every class that uses resoruces. There should be only one destructor that frees memory, only one that closes a file handle, etc. And those all fit a similar pattern and can themselves derive from a common base class/template to further reduce the possibility of error.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    11. Re:Forgive my ignorance WAS:re: Garbage collector? by FiskeBoller · · Score: 3, Interesting

      If you're a sole programmer writing everything yourself, I'd be inclined to agree with you. Most work I see, however, involves significantly larger chunks than 40,000 LOC and coordination with other teams or contributors. C/C++ has no inherent unified memory management scheme, and so the patterns and responsibilities for memory management can vary widely between teams, libraries, or chunks of code. That is something that often gets overlooked when discussing Java memory management. Java GC has literally has made the coordination and use of library code very simple.

    12. Re:Forgive my ignorance WAS:re: Garbage collector? by shutdown+-p+now · · Score: 2, Informative

      Most such languages have an "out" somewhere, so that you can use the language to call C system APIs, or use device-mapped hardware, because that's all that commercial software *did* in the olden days.

      In case of Java it's native methods / JNI. However, it's still not on JVM level - Java can only declare some method as native, it's the JNI spec that defines how such a method could be implemented in C. However, a JVM can refuse to execute native methods, and does so when running sandboxed (e.g. as an applet). But it still needs to manage memory for all the sandboxed code in a guaranteed-safe way, hence the need for GC.

      On the other hand, .NET has the full bunch right in the VM - raw data & function pointers with arithmetic, explicit arbitrary-layout structs (which include unions as a subset), etc. But it also divides all opcodes into "verifiable" (meaning no statically-uncheckable pointer trickery) and "unverifiable", and does not execute methods containing unverifiable code when sandboxed. So it also needs GC for verifiable code.

    13. Re:Forgive my ignorance WAS:re: Garbage collector? by idontgno · · Score: 5, Funny

      In C++, there are better ways to prevent memory leaks than carefully freeing everything in your destructors (which doesn't work anyhow if your constructor throws an an awkward moment).

      You accidentally a few words. You might say you accidentally a grammar exception at an awkward moment.

      --
      Welcome to the Panopticon. Used to be a prison, now it's your home.
    14. Re:Forgive my ignorance WAS:re: Garbage collector? by Thomasje · · Score: 2, Interesting

      True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak..

      As long as there are no references to the object the GC will reclaim the memory in that map. (see java.lang.ref.Reference and all the subclasses)

      The problem I was thinking about occurs when the map in question has a much longer lifetime than the objects it contains. For example, a multi-window application may implement a Windows menu by maintaining a map, that maps window names to window instances; the map's key set would be used to build the window menu, and the map itself would live for the application's entire lifetime. Now, unless you remove windows from the map when you dispose them, you'll have a memory leak.

      It's usually not hard to get this kind of thing right, but you do have to write code to make it work correctly; the GC will not prevent this kind of leak. Using a WeakHashMap can often help, but still, you'd have to remember where to use WeakHashMaps and where to use the regular kind, which requires thinking about object ownership... and my original point, a couple of posts back, was that once you have a clear picture of how object ownership should be managed in your app, you won't find it very difficult to use explicit memory management correctly, either. That said, GC does undeniably require you to write *less* code, so I wouldn't argue that GC is a Bad Thing -- just something you should not blindly trust to prevent all memory leaks.

  17. Re:suprised???? by KerberosKing · · Score: 3, Insightful

    did anyone really think Oracle was going to continue to release fully featured JDKs for free?????.....this is why the day Oracle bought Sun, i started learning C#....

    lol, yes because C# is owned by a much more FOSS-friendly company. Microsoft would never charge to support experimental features in production-code.

  18. G1 is already in OpenJDK by TeaCurran · · Score: 5, Informative

    G1 is in the latest OpenJDK builds. Since it is GPL you are free to use it without any license restrictions.

    The note in the release notes is only saying that Sun won't officially support it in their releases without a support contract.

    If you are concerned, use OpenJDK.

  19. Re:Almost by 3p1ph4ny · · Score: 3, Informative

    That works as long as the only strategy used is reference counting. There are others, and I think Java uses a fancy version of mark and sweep.

  20. Reference Counting != Garbage Collection by samweber · · Score: 5, Informative

    No, no, no! Creating a cycle of object references does not cause a memory leak in Java!

    You are assuming that a garbage collector uses reference counting. However, reference counting doesn't work for the very reason you state, and therefore GCs don't do it that way. They actually check whether an object is usable by the program, and not just whether it has any old reference to it.

  21. Re:Almost by TheRaven64 · · Score: 4, Informative

    To clarify, it only works if the strategy is pure reference counting. Mark-and-sweep and reference counting with cycle detection are both special cases of the same generalised algorithm (see the IBM TJ Watson papers for more info). Generally, ref counting + cycle detection plays nicer with virtual memory and non-uniform memory architectures than mark-and-sweep, although this is less true in an aggressively generational system like G1.

    --
    I am TheRaven on Soylent News
  22. Re:No malloc( )s by kailoran · · Score: 2, Informative

    Not only did you not get the joke, you also have some misconceptions about how the Java GC works. There is no counter, instead the program state is analysed for unreachable objects. Also, memory is not freed immediately, but some unspecified time later (i.e. during the next GC cycle)

  23. Bad Oracle touch by NewbieProgrammerMan · · Score: 3, Funny

    So the Oracle touch is already taking effect.

    Fork you, Oracle!

    --
    [b.belong('us') for b in bases if b.owner() == 'you']
  24. Why would you call it G1? by Sangbin · · Score: 2, Insightful

    Developers may search for JRE on Android...which is also called G1.

    Do you really want mixed results on Google search for "G1 Java"?

  25. Oracle deal not done yet. by cneth · · Score: 4, Informative

    Oracle does not yet own Sun and can't (yet) set business direction for it. It's just a new, experimental feature, folks.

  26. sensationalism by bcrowell · · Score: 4, Interesting

    The slashdot summary seems to me to have a heavy dose of sensationalism.

    Oracle's implementation of java is GPL'd. What more do we want from them?

    I doubt that there's been any recent research that's uncovered some fantastic new mechanism for garbage collection that was never known before. Garbage collection used to suck, and that was one of the problems, historically, with LISP. Over the decades, garbage collection has gradually gotten better. All the improvements in garbage collection are in the public domain. Gc is not generally a performance bottleneck for modern garbage-collected languages.

    It would be slightly more worrisome if this new gc algorithm was patented -- but I haven't seen any evidence that it is. If it's not, then nothing is preventing anyone from making a fully GPL'd version of java with the new algorithm. If it was patented, then this would be a problem for all garbage-collected languages with open-source implemtations, not just java.

    Does java's performance really depend much on the efficiency of its gc? My main complaint about java's performance is that the VM and libraries take too long to load.

  27. G1 is for the Entreprise by jeanph01 · · Score: 5, Informative

    Here [http://developers.sun.com/learning/javaoneonline/j1sessn.jsp?sessn=TS-5419&yr=2008&track=javase] what sun says about it : The Garbage-First garbage collector (G1 for short) is the next-generation low-pause garbage collector that will be included in the Java HotSpot virtual machine. G1 will be the long-term replacement for the Concurrent Mark-Sweep (or CMS) garbage collector, Sun's current low-pause garbage collector. G1 targets medium to large multiprocessor machines and large heaps, relying heavily on the concurrency and parallelism such machines offer. Like CMS, G1 is generational, which benefits throughput. Unlike CMS, G1 compacts to battle fragmentation and to achieve more-consistent long-term operation. As its name suggests, G1 concentrates its collection and compaction activity first on the areas of the heap that are likely to be full of reclaimable objects, thus improving its efficiency. G1 uses a pause prediction model to meet user-defined pause time targets. It achieves smoother pause times than CMS, with fewer or no outliers at comparable or better throughput, as this presentation shows. The initial target pause times are in the low tens of milliseconds. === So this is more for entreprise multiprocessors, multiservers java. And those entreprise normally will buy a support contract. So it's almost a no news.

  28. A Java hate piece on Slashdot??? by COBOL/MVS · · Score: 2, Insightful

    But that's the kind of stupid shit that's been spewing from here for the last 10 years.

    PS - the look and feel of slashdot sucks

    --
    GOBACK.
    1. Re:A Java hate piece on Slashdot??? by WankersRevenge · · Score: 4, Interesting

      Java got a bad rap back in the day when the language was poised to take over the desktop and then everyone used it, and were killed by its abysmal performance. Back in the 2000, I cursed java every week as I entered my development time into this crap-ola windows box that performed like a fat man running through a river of melted taffy. Loading an applet was a painful flow breaking experience that usually did nothing to a page. When people think of java, they think of this time. it's the slashdot two minute hate.

      These days, Java works well both on the desktop and on the server. Shocking, I know. I'm currently developing a desktop app for OS X and people have no idea it's a java project. It looks and behaves as if written in Objective C. Our engineering team just wrote a server app in java that had over three million entries. At one point, it was creating nine hundred entries per second without breaking a sweat. But people don't see that. They just have mental images of all the crappy applets back in the days of yore, then make uninformed opinions about the current state of the language.

      My biggest complaints about java are the inconsistent implementations between platforms so something might work great on a mac, but throws exceptions on windows. Write once, run everywhere is a lie. My code is 100% java (no native code) that runs perfect in both mac and windows, yet makes the official Linux JVM puke. I hate the fact the language is object orientated, but objects are expensive to create. I hate the fact that Swing makes it easy for good java developers to write terrible user interfaces. The GridBag layout was designed by a very bitter programmer. I hate the fact that java eats and eats all the memory it can find like a kid diving his face into birthday cake. People say there's no memory leaks in Java, but once you start playing with JOptionPane, you realize that's a nice little lie. And there is work in managing your objects. I can make an app bloat up like firefox in no time. There's a few other nitpicks, but speed has never been one of them. If it were, I would be writing my app in C++ with QT, or Objective C.
       

  29. RTFA by Anonymous Coward · · Score: 2, Interesting

    Seriously, your headline is exactly backwards. Read what the pay for support is for. The G1 is beta so you pay for support... the older versions of Java that are out of date are also pay for support.

  30. Even when... by jd · · Score: 2, Insightful

    ...you have explicit allocation/deallocation, you get holes in memory. There's no way to avoid it, for the same reason that fragmentation occurs on disks. Unless the chunk you allocate is exactly the same size as the chunk last deallocated, there will be a region of memory that cannot be used.

    This means that your heap will end up looking like swiss-cheese, unless you have some means of shuffling things around. Unless the programmer can absolutely guarantee that mallocs and frees only occur in such a way that no space unusable to the program's next malloc is ever left, the program will always have the potential of exhausting resources even without leaking memory.

    This is why there are all kinds of malloc() substitutes for C, including several with garbage collection. If the program runs for long enough, the vanilla malloc() in most C libraries is simply not good enough.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  31. Re:wait, I am confused... by raijinsetsu · · Score: 3, Funny

    What situation is that? If you're talking about tying a customer to a painful and harmful contract, then yes.

  32. It's in OpenJDK too by arthurp · · Score: 5, Informative

    G1 is in OpenJDK and JDK7 as well as the new JDK6. So it's open source. So fear not. I think that as people have mentioned below they are simply trying to protect themselves from people turning on this feature in a production environment and then bitching to them about it.

  33. Re:No malloc( )s by TimeTraveler1884 · · Score: 5, Funny

    Holy crap! That joke cut his head off!

  34. To View Comment Subjects by kumanopuusan · · Score: 4, Informative

    Just click on the "change" button after the summary and the comment subjects display correctly. Whatever the problem is with the cached story pages, comments.pl is fine.

    --
    Use of the words "good", "bad" or "evil" is almost invariably the result of oversimplification.
    1. Re:To View Comment Subjects by Unoti · · Score: 2, Interesting

      Thanks for this tip!

      Not being able to read the headers and moderator points made me realize just how much it influences how I read slashdot, which is interesting and unnerving...

  35. Re:aha! I knew all along by Verdatum · · Score: 2, Informative
    No, the old, old garbage collector was rubbish. Java has been taking crap for it ever since, even though it changed garbage collecting mechanisms ages ago.

    From en.wikipedia.org/wiki/Java performance:

    "The 1.0 and 1.1 Virtual Machines used a mark-sweep collector, which could fragment the heap after a garbage collection. Starting with Java 1.2, the Virtual Machines switched to a generational collector, which has a much better defragmentation behaviour. [2] Modern Virtual Machines use a variety of techniques that have further improved the garbage collection performance.[10]"

  36. Irrelevant by hackus · · Score: 3, Insightful

    The entire Java Stack has long since been opened up. The community essentially owns it now. What Oracle does with "Java" I could care less.

    Anything that is worth while to build design and construct/maintain Java applications and VM's is all open source.

    If they want to fork and become irrelevant that is there choice.

    -Hack

    --
    Got Geometrodynamics? Awe, too hard to figure out? Too bad.
  37. now that the java-haters have cleared out by recharged95 · · Score: 3, Interesting
    So basically what we're talking here is:
    • Use Sun's JDK and want support (i.e. you don't figure out the solution)? Pay for it.
    • Use openJDK and want support (ie.. you figure it out)? Have fun.

    .

    Sounds like any other typical OSS business model from Ubuntu, Novell, RedHat, IBM, and even Microsoft.

  38. Linux UNIX by jimfrost · · Score: 3, Insightful
    Linux > Unix.

    Other than cost, I'm curious as to what you are measuring.

    It's not performance. Solaris 10 on a PC outperforms Linux when stressed, sometimes by huge margins. It's not a complete blow-out with modern kernels, like it was in the 2.4 days, but it's still significant -- and there are corners where it really still is a complete blow-out (like: What does fsync() do?).

    It's not stability. Again, Solaris 10 is much less likely to crash or go all wonky when stressed, and AIX is similarly robust. And again there are corners here that can have large impact on reliability of applications (e.g. I recall some annoyances with direct io, although the specifics are escaping me at 3am).

    It's not core features, by and large Linux lags the commercial UNIXen in that arena (e.g. Dtrace), which isn't really surprising since Linux is effectively a clone.

    Having said that, there are certainly UNIXen that do not stand up so well to Linux (*cough* HP/UX *cough*), but there certainly exist UNIXen that are generally superior.

    Of course, a lot depends on what you're doing with the system. If I need to push the system as hard as possible then I want Solaris if it is an option. If I am looking for general usability I find Linux preferable. The differences in the latter case are often minor (like the -c argument to "script") but taken en-masse they make for a more pleasant experience.

    That's the way I see things today. I am not at all sure we won't see Linux pull into the lead over time -- it is getting better and better with age, and most UNIX systems appear to be seeing improvement stagnation. (And that may well be universal soon: What are the odds that Solaris doesn't see its R&D budget chopped under Oracle?) In summary I would generally prefer to do development on Linux, but want production on Solaris. Best of both worlds, at least today. It may be telling, though, that on my personal server systems I run Linux even when I am concerned about performance -- the ongoing administration is significantly easier it you pick the right Linux distribution, and it isn't picky about hardware like Solaris is, and the tool suite is free as in beer without any extra effort.

    Except on the desktop. There MacOS is supreme IMO. All the goodness of UNIX, plus stellar UI and commercial applications. I dunno how it does in stress situations (almost nobody buys Apple servers) but it's a great desktop system.

    --
    jim frost
    jimf@frostbytes.com
  39. Re:Linux UNIX by turgid · · Score: 2, Insightful

    Solaris is a specific case of original, commercial unix which went open source a few years ago.

    Back in the '90s, when Linux distributions started to get really popular, the Linux kernel and the distributions overtook many of the old commercial unices (e.g. SCO Unix, AIX, IRIX...) and effectively killed them.

    Linux was cheaper (free), the user-land was more user-friendly (GNU tools, GNOME, KDE...), and truly cross-platform.

    Linux's and GNU's openness and freedom was and is the key to its success. There are now millions of people around the world proficient in Linux/Unix who wouldn't have been for this very reason. There are people like me who made it all the way to being a Software Engineer simply by having a Linux system in the home to learn on.

    Solaris is still ahead by a long way on high-end technical features like ZFS and is quite possibly the only commercial unix that has a future now.

    I have 3 Solaris 11 UltraSPARC boxes in my house just now: a SunBlade 100 and two Ultra 80s (4 CPU).