Java Gets New Garbage Collector, But Only If You Buy Support 587
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?"
Maybe (Score:1, Interesting)
Someone can add this to OpenJDK or a fork of OpenJDK?
Garbage collector? (Score:4, Interesting)
As a non-programmer, can someone give a brief explanation of what a garbage collector is as it pertains to programming.
This was BEA's model with JRockit (Score:5, Interesting)
Perhaps (Score:5, Interesting)
"Will OpenJDK be doomed to a feature-castrated backwater while all the good stuff goes into the new Java SE for Business commercial version?""
Perhaps. But now that its GPL, maybe IBM, RH and the rest of Java's stakeholders will get onto making openjdk better than oracle's. Ill sure contribute: this is a strategic need for the foss movement.
It's still experimental (Score:5, Interesting)
Methinks they just want to make damn sure nobody uses this feature in a production environment. This is more of a sneak peek for paying customers who are contractually bound against using this in a production environment.
If this was included in the standard distribution, then people would use it no matter what the documentation said. And then Sun would be saddled with bug reports and whining.
Almost (Score:2, Interesting)
1. From your Main object, create an object A.
2. Have object A create an object B. Have it pass itself as an argument to the ctor.
3. Have object B keep the reference to object A.
At this point you have 2 references to object A (one from the Main object and one from object B) and 1 reference to object B (from object A).
Now just set object A to null to destroy the reference from Main to A. The reference counter to A drops from 2 to 1 (and object B still has 1). Both objects continue to exist in memory but they cannot be referenced by your program.
Voila! Memory leak in Java.
Forgive my ignorance WAS:re: Garbage collector? (Score:3, Interesting)
I know I am profoundly ignorant and as thus should be modded into oblivion, but I don't do any programming where the memory allocation is variable. Is there a good reason are people really relying on hidden mechanisms to manage it? I would think it would be a lot more robust to keep track of allocation and deallocation explicitly, add when you need, and delete when you don't need, and not count on some generic mechanism. I know it happens, I see the memory leaks, but it would seem eminently avoidable.
Brett
Re:Seriously Java? (Score:4, Interesting)
Re:Seriously Java? (Score:5, Interesting)
I don't know which is true but the second possibility seems far more likely to me, making this story completely pointless and unfair - but hey this is slashdot.
Btw, off topic but is it just me or the subjects in replies are showing up as white text on white bg in Firefox but look ok in IE. I even tried in on another pc and same thing.
Re:It's "experimental" (Score:3, Interesting)
1. Distribute working but unlicensed software
2. Encourage developers to use the software
3. Audit companies using said software
4. Profit!
We've gone through more than one episode that starts with: "shite -- we have to rip out this proprietary Oracle crap or pay another X (usually 6+ figures) per year in licensing fees.
The more devious method Oracle also uses is:
1. Package licensed software components into specific products
2. Change products, moving commonly used components into rarely licensed products
3. Notify customers right before negotiating new license
4. Profit!
sensationalism (Score:5, Interesting)
The slashdot summary seems to me to have a heavy dose of sensationalism.
Oracle's implementation of java is GPL'd. What more do we want from them?
I doubt that there's been any recent research that's uncovered some fantastic new mechanism for garbage collection that was never known before. Garbage collection used to suck, and that was one of the problems, historically, with LISP. Over the decades, garbage collection has gradually gotten better. All the improvements in garbage collection are in the public domain. Gc is not generally a performance bottleneck for modern garbage-collected languages.
It would be slightly more worrisome if this new gc algorithm was patented -- but I haven't seen any evidence that it is. If it's not, then nothing is preventing anyone from making a fully GPL'd version of java with the new algorithm. If it was patented, then this would be a problem for all garbage-collected languages with open-source implemtations, not just java.
Does java's performance really depend much on the efficiency of its gc? My main complaint about java's performance is that the VM and libraries take too long to load.
RTFA (Score:2, Interesting)
Seriously, your headline is exactly backwards. Read what the pay for support [sun.com] is for. The G1 is beta so you pay for support... the older versions of Java that are out of date are also pay for support.
Hate to say, I told you so... (Score:1, Interesting)
I said this would happen: http://slashdot.org/comments.pl?sid=1240121&cid=28039069 [slashdot.org]
Oracle gives away stuff, and then charges for the good features or forbids usage 'till paid. Else, the Oracle Police will come around...
Good thing they are not part of the BSA, are they? I dont remember, my memory slips... Darn garbage collector, if I only were allowed to use the new one I wouldnt have memory problems!
Thanks for nothing, Oracle!
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:3, Interesting)
I find it unrealistic to think that you could prevent deliberate "dangling pointers".
Which is strange, because languages that do so have been around for ages, and certainly much earlier than Java (e.g. Smalltalk is one).
Most such languages have an "out" somewhere, so that you can use the language to call C system APIs, or use device-mapped hardware, because that's all that commercial software *did* in the olden days.
Also, if you do deallocations (or close file handles, or free locks or other resources) in destructors of man classes, you eventually screw up
Why?
Of course, idiomatic C++ is not to close file handles in destructor of every class that needs one, but to write a class encapsulating a file handle (which does close it in its destructor), and then use it in all other classes that need to own a file handle.
Yes, that was my point. Don't free resources in the destructor of every class that uses resoruces. There should be only one destructor that frees memory, only one that closes a file handle, etc. And those all fit a similar pattern and can themselves derive from a common base class/template to further reduce the possibility of error.
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:3, Interesting)
Re:In this day and age of "green" businesses... (Score:4, Interesting)
Despite the humor, you make an interesting point. Had garbage collectors been invented in the 21st century, they might have been called "memory recyclers" rather than "garbage collectors". Primarily because the GC is actually reclaiming memory for reuse. Yet when the term "garbage collection" was coined, the concept of recycling hadn't yet entered common thinking. Ergo, it was identified with "taking out the trash" rather than "recycling something useful".
Re:A Java hate piece on Slashdot??? (Score:5, Interesting)
Java got a bad rap back in the day when the language was poised to take over the desktop and then everyone used it, and were killed by its abysmal performance. Back in the 2000, I cursed java every week as I entered my development time into this crap-ola windows box that performed like a fat man running through a river of melted taffy. Loading an applet was a painful flow breaking experience that usually did nothing to a page. When people think of java, they think of this time. it's the slashdot two minute hate.
These days, Java works well both on the desktop and on the server. Shocking, I know. I'm currently developing a desktop app for OS X and people have no idea it's a java project. It looks and behaves as if written in Objective C. Our engineering team just wrote a server app in java that had over three million entries. At one point, it was creating nine hundred entries per second without breaking a sweat. But people don't see that. They just have mental images of all the crappy applets back in the days of yore, then make uninformed opinions about the current state of the language.
My biggest complaints about java are the inconsistent implementations between platforms so something might work great on a mac, but throws exceptions on windows. Write once, run everywhere is a lie. My code is 100% java (no native code) that runs perfect in both mac and windows, yet makes the official Linux JVM puke. I hate the fact the language is object orientated, but objects are expensive to create. I hate the fact that Swing makes it easy for good java developers to write terrible user interfaces. The GridBag layout was designed by a very bitter programmer. I hate the fact that java eats and eats all the memory it can find like a kid diving his face into birthday cake. People say there's no memory leaks in Java, but once you start playing with JOptionPane, you realize that's a nice little lie. And there is work in managing your objects. I can make an app bloat up like firefox in no time. There's a few other nitpicks, but speed has never been one of them. If it were, I would be writing my app in C++ with QT, or Objective C.
Re:Forgive my ignorance WAS:re: Garbage collector? (Score:3, Interesting)
True, but Java is not immune from that kind of problem, either. A common case is adding an object to a map, and forgetting to remove it when it's no longer needed. Ta-dah, memory leak..
As long as there are no references to the object the GC will reclaim the memory in that map. (see java.lang.ref.Reference and all the subclasses)
The problem I was thinking about occurs when the map in question has a much longer lifetime than the objects it contains. For example, a multi-window application may implement a Windows menu by maintaining a map, that maps window names to window instances; the map's key set would be used to build the window menu, and the map itself would live for the application's entire lifetime. Now, unless you remove windows from the map when you dispose them, you'll have a memory leak.
It's usually not hard to get this kind of thing right, but you do have to write code to make it work correctly; the GC will not prevent this kind of leak. Using a WeakHashMap can often help, but still, you'd have to remember where to use WeakHashMaps and where to use the regular kind, which requires thinking about object ownership... and my original point, a couple of posts back, was that once you have a clear picture of how object ownership should be managed in your app, you won't find it very difficult to use explicit memory management correctly, either. That said, GC does undeniably require you to write *less* code, so I wouldn't argue that GC is a Bad Thing -- just something you should not blindly trust to prevent all memory leaks.
Re:Seriously Java? (Score:3, Interesting)
Wrong. And unlike you, I can actually backup my statement.
Write once, run anywhere = very cool. Always backwards compatible = very cool. Much cleaner than C and C++ code that it was competing with = very cool. It does all of this while offering performance superior to most languages.
There are newer nifty-neato languages out there but Java is a workhorse language that is still extremely valuable to corporations around the world. Sun actually has a pretty remarkable achievement on their hands, and I can assure you that I have no problems criticizing Sun.
Re:Seriously Java? (Score:5, Interesting)
I don't know about Java, but I've been playing with Google's V8 [google.com] and that sucker is fast, at least on Windows.
now that the java-haters have cleared out (Score:4, Interesting)
.
Sounds like any other typical OSS business model from Ubuntu, Novell, RedHat, IBM, and even Microsoft.
Re:To View Comment Subjects (Score:3, Interesting)
Thanks for this tip!
Not being able to read the headers and moderator points made me realize just how much it influences how I read slashdot, which is interesting and unnerving...
Re:Seriously Java? (Score:3, Interesting)
device support? at least the free Unix (known as the BSD) are really catching up well to Linux with that.
Re:Seriously Java? (Score:3, Interesting)
[Open]Solaris in some aspects might be better, but it is OSS anyway.
Re:Seriously Java? (Score:3, Interesting)
That keeps people writing crappy software on C++ or C when quite often Java would be a good fit for them and the performance is mostly a non-issue these days (unless you write very inefficient programs).
Or programs that need floating point. Several of the commonly used functions in java.lang.Math are implemented by processor specific instructions, e.g. Math.exp(), yet Java refuses to use them, instead preferring an integer-based approach that's 5-10 times slower, but maybe a bit or two more accurate. Despite repeated requests, no option is as yet available to use them anyway in applications where that accuracy is not required. This makes many high-performance computing systems (particularly neural nets) substantially slower on Java than other systems.