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."
Not quietly (Score:5, Informative)
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).
Slashdot editors don't read slashdot? (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.
Re:But it could be! (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.
Re:No Way! (Score:4, Informative)
Re:But it could be! (Score:3, Informative)
use reference counting != deterministic behavior
reference counting + any indirect circular reference == memory leak
hybrid GC with both reference counting and mark and sweep for cycle detection == closer to deterministic than what Java offers in the good case (no circular references) while still correct in the bad case (circular reference becoming detached from main())
Re:But it could be! (Score:5, 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.
Popular Java Myths (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.
Re:But it could be! (Score:1, Informative)
Java doesn't fail (Score:5, 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.
Re:But it could be! (Score:5, Informative)
As far as Java goes, ignore the command line for now. You don't need it to quickly build decent-performing applications.
Re:But it could be! (Score:5, Informative)
there are no guarantee that destructors on static object will be called.
Actually, Section 3.6.3p1 of the C++ standard [open-std.org] guarantees it. (Wonder why people who can't validate technical language claims feel qualified to mod posts that make them).
Re:But it could be! (Score:3, Informative)
I write in Java every day, but if my code was running on anything other than an application server that takes care of most of my non-memory resources, I'd be wishing for the equivalent of a destructor every week.
It's not really about memory management though, but about resource management. Initialize your resources at object construction and release them at destruction is a very simple and elegant solution that is common on many C++ projects. In Java, we can't really do anything like that. We can't really encapsulate the resources without jumping through hoops.
So use real-time Java (Score:4, Informative)
Not Oracle/Sun Yet (Score:5, 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.
Re:But it could be! (Score:3, Informative)
I find on Google mentions that Python which uses ref counting detects cycles.
It does, though, as I understand, the behavior is the way it is mostly for backwards-compatibility purposes.
Guido once made a list of things that he considers "implementation details" for Python, and not guarantees of the language spec - meaning that alternative Python implementations could deviate on those points from CPython. Reference counting is on that list, and e.g. Jython and IronPython do not use it at all, relying strictly on tracing GCs provided by their respective VMs.
Re:But it could be! (Score:3, Informative)
Is this a matter of your code holding references to your object, or other libraries holding references to your object?
Other libraries. You may not have a cycle between objects you control, but as soon as you expose any single one of them outside, that one can become a part of a cycle (an external object that is in a cycle holds a reference to yours), and, by extension, all objects it references. At this point, when it will die, it will die on a GC thread, when GC frees the cycle.
Then what is the right way in Java to automatically write whatever finally blocks need to be written, in the manner of Python's with statement?
Python's with statement has nothing to do with reference counting at all. It's a much simpler strategy where the programmer explicitly defines the boundary at which the resource is to be freed, irrespective of how many references there are to it. C# has a similar construct, using, which behaves much the same except for name of method that is called on block exit (__leave__ in Python, Dispose in C#), and it doesn't use reference counting at all, for any purposes.
Java actually had a bunch of proposals for a very similar thing (e.g. here [java.net] is one from Google). However, none of them were accepted for Java 7 (fools...).
Re:But it could be! (Score:3, Informative)
Smart pointers, as something you can just use, were introduced in Boost several years ago, and are in the standard now via Technical Report 1. In the mid-90s, they were possible (given template support, which was not universally good at the time), but not widespread.
Nor do I roll my own. I write the destructors, of course, and then I just use smart_ptr instead of * (okay, a bit more syntax difference than that). By now, it's not custom code.
So, in about 2000 the Java approach was generally better. Smart pointers weren't really available then for C++, and Java programmers at least didn't have to worry about memory management. Nowadays, I consider the C++ solution to be superior, since it's more general.