Java's New G1 Collector Not For-Pay After All 171
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."
But it could be! (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.
Re:Right path? (Score:0, Insightful)
Well.... (Score:4, Insightful)
Probablly just a misunderstanding (Score:5, 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.
Re:Not quietly (Score:3, Insightful)
Was this ever an issue? (Score:5, 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 ;-)
Re:But it could be! (Score:3, Insightful)
Re:But it could be! (Score:2, Insightful)
use reference counting != deterministic behavior
reference counting + any indirect circular reference == memory leak
That sounds pretty deterministic to me. Indirect circular reference == memory leak, all the time. You can count on that.
Stop spreading FUD (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.
Re:But it could be! (Score:4, Insightful)
Nor are destructors called on longjmp.
For the love of God, man, use exceptions! That's what they're for!
Re:But it could be! (Score:3, Insightful)
Re:Popular Java Myths (Score:4, Insightful)
1) Java is slow.
I'm generally a Java advocate, but you have to take into accounts when Java *is* slow. This is mostly where Java has to get down to the nitty gritty of the bare metal. Examples are cryptography (lots and lots of low level operations on bytes, 32 and 64 bit words) and processor based instructions. In those cases it makes sense to use a well defined C library (avoiding C++ if possible) and interface with that. These are also the places where it makes sense to really optimize the hell out of an application or library.
But for general business logic this arguement is indeed long gone. I do believe that my Java applications are normally faster than their C++ counterparts for the simple reason that I've got more time to design my classes well. Even if it's slower then it's offset by the much lower maintainance cost. And it's way faster than most specialized languages. Then again, specialized languages can make sense if they are delivering lower maintainance cost. Lets just say that not choosing Java because is it slower *per se* is absolutely wrong.
Re:Java doesn't fail (Score:3, Insightful)
If you're coding in lots of explicit memory reference deletes, what you're writing is not C++ but C. A C++ codebase would use RRID and automatic memory management to obviate the need for any explicit memory management. My last C++ project at work contained zero (yes, zero) calls to delete/free() out of around 20000 lines of code and a year of development/testing.
You're making the same mistake you're accusing C++ developers of making - you're viewing C++ through Java lenses.
Re:But it could be! (Score:1, Insightful)
We can't really encapsulate the resources without jumping through hoops.
Those hoops are the same hoops you're jumping through with destructors on C++. It only looks more elegant because the complexity has all been pushed into ensuring that all objects are properly destroyed when they need to be. You're doing the exact same thing using the dispose pattern in a GC'ed language, only it feels difficult because you're normally reliant on the collector, but there is a distinction between "resources" and "objects".
Re:But it could be! (Score:3, Insightful)
'exit' is a system call ...
That was about where I stopped reading the comment.
The modern "high-level" programmers who do not understand (nor bother to try to) how their own programs actually work, fit with the system and how system is used to implement language features deserve no pity.
Go back to your Java cave.
Re:Popular Java Myths (Score:3, Insightful)
Re:But it could be! (Score:3, Insightful)
Of course you don't implement finalize in Java. Since it may or may not get called, it's almost completely useless. The reason the non-deterministic behavior is not an issue is that it is assiduously avoided. What is an issue is the lack of a useful analog to finalize.
However:
I don't call delete in C++ programs, in general. I let smart pointers take care of all of it. This means that all my resources, including memory, are automatically managed for me in a uniform manner.
This means that resource management is easier in C++ than in Java. As a C++ guy, I never have to worry about calling close or delete or anything like that. I don't have to worry about closing something too soon or too late. I don't have to worry about resource leaks, unless I do some odd things with the pointers.
You, on the other hand, have to make sure you close things. You may use the try...finally idiom, which enforces a non-cohesive chunk of code with very high coupling. In resources that get passed around and used in multiple places, you have to figure out when to call close.
In short, C++ started with a general solution for resource management, and extended it to memory management. Java picked off the easy case of memory management, and left everything else to the developer, without the tools C++ gives to manage resources.
Re:Java doesn't fail (Score:1, Insightful)
Unfortunately, the standard C++ containers are deeply flawed: they can only hold objects by value. Which means they're useless for OO code, because you can't have a container of a base class and store instances of subclasses in it. No inheritance, no polymorphism.
To get round that, you'd have to store pointers in your container... at which point it instantly stops managing the memory for you. The obvious answer is to use a smart pointer! And the standard smart pointer is std::auto_ptr, which ... oops, looks like using that in an STL container is a sure-fire recipe for horrible disasters.
Now, boost does indeed solve this; it has a set of special pointer containers that can handle objects properly, as well as a set of smart pointers that don't actually suck. But boost is a large, complex third-party library, and that means that a heck of a lot of C++ coders simply can't use it. Sure, some of it's going to be in the next version of C++, but that's too little, too late.
Re:Not quietly (Score:3, Insightful)
Sun didn't "quietly edit" the release notes; they announced it [sun.com] publicly and appologized for having been unclear (which seems like a bit dishonest, but not quiet).
It was established in the prior slashdot post ranting about it that it was just headline mongering. Nobody commenting had trouble understanding the true meaning.
But as usual, anything Java is SLOW, EVIL, BAD and out to steal your monies!