Slashdot Mirror


Java's New G1 Collector Not For-Pay After All

An anonymous reader writes "As a follow-up to our previous discussion, Sun appears to have quietly edited the Java 6u14 release notes language to say now: 'G1 is available as early access in this release, please try it and give us feedback. Usage in production settings without a Java SE for Business support contract is not recommended.' So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."

18 of 171 comments (clear)

  1. Right path? by DoofusOfDeath · · Score: 5, Funny

    In either case it's nice to see Java's back on the right path.

    Did kdawson even read the article before writing the summary? I don't see anything in the article about Java becoming more like Haskell!

  2. But it could be! by BadAnalogyGuy · · Score: 5, Insightful

    Garbage collection is an amazingly boring field of computer science. It's all about tracking references and trying to keep memory from filling up while also trying to keep the overall impact on the running system down. But as boring as it may be, it's also absolutely critical in today's interpreted languages.

    Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted. Java has no such guarantee, so expecting an object to clean itself up once it goes out of scope is a fool's errand. It will get finalized eventually, but the lack of deterministic behavior in this critical part of the object lifecycle means that there is a very big chance that unacceptable delays may occur in practice.

    Give me deterministic behavior over faster GC any day.

    1. Re:But it could be! by yacc143 · · Score: 4, Informative

      Deterministic behaviour => use reference counting. E.g. Python has it.

      But the situation with C++ is not as rosy as you paint it.

      E.g. there are no guarantee that destructors on static object will be called.
      Nor are destructors called on longjmp.

    2. Re:But it could be! by siloko · · Score: 4, Funny

      Where Java really fails is in the inability to trust the finalize method. At least in C++, the destructor of an object is guaranteed to be called as soon as the object is deleted.

      Destructor!? Finalize!? Deleted!? You talking like a crazy man, have you never heard of a system REBOOT?

    3. Re:But it could be! by tepples · · Score: 4, Informative

      Nor are destructors called on longjmp.

      That's one reason why setjmp was deprecated in favor of try/catch and longjmp in favor of throw.

    4. Re:But it could be! by Ethanol-fueled · · Score: 5, Informative

      What you just said makes no sense. The whole point of Java is that you don't have to mess with memory management. You've just admitted that you want to invest more time and complexity in building "mini-projects" by switching to C++. Good for learning, but otherwise practically silly if you're a noob, and you've implied that you are.

      As far as Java goes, ignore the command line for now. You don't need it to quickly build decent-performing applications.

    5. Re:But it could be! by mpsmps · · Score: 4, Informative

      there are no guarantee that destructors on static object will be called.

      Actually, Section 3.6.3p1 of the C++ standard guarantees it. (Wonder why people who can't validate technical language claims feel qualified to mod posts that make them).

  3. Well.... by samriel · · Score: 4, Insightful

    I think this means that, if you use the new GC in a production setting and it clobbers some mission-critical piece of data, they would really like you to have some support contract with them, rather than never using G1 or Java again. It is 'early release' after all.

  4. Not quietly by RPoet · · Score: 5, Informative

    Sun didn't "quietly edit" the release notes; they announced it publicly and appologized for having been unclear (which seems like a bit dishonest, but not quiet).

    --
    "Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
    1. Re:Not quietly by causality · · Score: 4, Funny

      What you said here. People were so buy foaming at the mouth that they never bothered to read the actual article or the thousands of posts that spelled out pretty clearly how and why the slashdot story got it wrong.

      Never seen that before. No, not ever.

      It's funny when you can cut+paste your comment and drop it into multiple discussions without having to modify it. It is truly one-size-fits-all.

      "Stop. Look. Listen, learn, read, think .. SHUT THE FUCK UP!" - Bill Hicks

      --
      It is a miracle that curiosity survives formal education. - Einstein
  5. Slashdot editors don't read slashdot? by argent · · Score: 5, Informative

    This is not a change, it was clear in the previous thread that the article was completely misinterpreted. The Slashdot summary made no sense at all once it was pointed out that G1 was GPL+Classpath.

  6. Probablly just a misunderstanding by petermgreen · · Score: 4, Insightful

    I would guess a developer said something vauge like "don't use this in production without a support contract" and it got misunderstood by the person writing the release notes. If they really wanted to forbid it I'd expect them to be competant enough to do that in the license.

    --
    note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  7. No Way! by Anonymous Coward · · Score: 5, Funny

    A kdawson article that totally blew something out of proportion? What a shock!

  8. Was this ever an issue? by Lemming+Mark · · Score: 4, Insightful

    Argh, so I'm turning into the kind of person who comments without reading *either* article in question but ...

    Last time this came up, plenty of people pointed out that the G1 garbage collector was available to anyone, Open Source but that it was in development and you weren't recommended to use it in production without a support contract. A number of people even pointed out the settings that anybody could change to enable the experimental G1 garbage collector on their own system.

    Perhaps this is case of adjusting their wording to make it easier for Slashdot to not report incorrectly ;-)

  9. Stop spreading FUD by harryandthehenderson · · Score: 5, Insightful

    So does this mean it was all one huge typo? Or was Oracle/Sun tentatively testing the waters to see the community's reaction? In either case it's nice to see Java's back on the right path."

    No, it means that the original article was a misleading pile of FUD since the G1 garbage collector was released GPL + Classpath exception from the beginning. It's amusing that after being pointed out that the original submission was misleading and wrong that instead of this being a retraction that this article still tries to implicitly claim that Sun or Oracle did something wrong.

  10. Popular Java Myths by javacowboy · · Score: 4, Informative

    1) Java is slow
    2) Java is not yet open source (or only parts of it are or isn't "really" open source)
    3) Java is not available in any Linux distro's package manager
    4) Java does not meet the needs of the enterprise
    5) Nobody uses Java anymore
    6) "Java is a heavyweight ball and chain"
    7) Sun is charging people to use the new G1 garbage collector.

    Java has some weaknesses and disadvantages, but the above are not among them.

    --
    This space left intentionally blank.
  11. Java doesn't fail by beldraen · · Score: 4, Informative

    The reason why you are confused is because you're used to a compiled environment, where every call is an immediate action. A C/C++ program must be coded to (i.e. explicitly) deletes memory references. If you explicitly delete, you can also tie in other explicit behavior; therefore, it's common "duh this is how you do it" practice to tie "finalize" behavior to the object's deletion. But remember, it is your program's logic that has decided when to get rid of it. In a GC environment, deletion is no longer an explicit event--it is autonomous, automatic; therefore, it is illogical to tie anything to the deletion of the memory reference to anything other than deletion of the memory reference. There is no connection between when the object was dereferenced and when the GC chooses to clean up the reference. Generally, the only events that are tied to the finalize method are sanity checks to make sure non-Java code knows the reference is going away. Put differently: in Java, memory deallocation is not a part of the running logic of your program and so the program must create an explicit method of releasing resources in your program's logic. In other words, do what you were doing before, just don't call it finalize. That's a gripe of mine about Java: It confuses C++ users who are used to using the function finalize because Java gives finalize a specific purpose that cannot act the same way.

    --
    Bel, the mostly sane.. "Of course I can't see anything! I'm standing on the shoulders of idiots." -- Me
  12. Not Oracle/Sun Yet by fm6 · · Score: 4, Informative

    Or was Oracle/Sun tentatively testing the waters to see the community's reaction?

    It's a little early to talk about Sun as a part of Oracle. It's probable that the acquisition will clear regulatory approval, but until it does, Oracle can't play anything resembling a decision-making role in something like this.

    I work at Sun, and right now our contacts with Oracle are actually more circumscribed than they'd normally be.