Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by ScuttleMonkey on from the putting-on-the-squeeze dept.

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

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

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

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

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