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

Re:But it could be!

[shutdown -p now]

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.

It not only "looks more elegant", it is more elegant and concise, because for any given resource type, you write the cleanup code once, and then it is called automatically. With Java, you still write the code once (preferably implementing Closeable), but then you also have to call it manually all the time, resulting in a mess of nested try-finally calls:

InputStream in = new FileInputStream("foo");
try {
  OutputStream out = new FileOutputStream("bar");
  try {
...
  } finally {
    out.close();
  }
} finally {
  in.close();
}

At least C# had the decency to provide syntactic sugar for this in form of using:

using (Stream input = File.Open("foo"))
using (Stream output = File.Create("bar"))
{
...
}

But even that only deals with resources local to a method, not instance fields. And it still isn't automatic.

Even so, this feature alone would make Java so much easier to deal with. I can't believe they decided not to add it to Java 7, especially when there was a sane proposal already, and the implementation is trivial. It's probably the single most convenient feature C# has over Java (considering how often it's used).