Slashdot Mirror
Java Gets New Garbage Collector, But Only If You Buy Support
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?"
It gets better. (Or worse, depending on your point of view.)
This version also adds a blacklist to the JRE, so Oracle can ban people from running various applications.
Just what I want to do, give Oracle the power to randomly stop applications I use from running. I wonder how long it will take for Eclipse to "accidentally" make it onto the blacklist?
The more things you have to pay attention to at the nuts-and-bolts level, the fewer things you are able to pay attention to at the business logic level. The key difference between managed languages like Java and non-managed languages like C, is that the uninteresting grunt work is done for you by the compiler
Unless, of course, you're solving a technical, rather than business, problem. At that point the product that you're selling is doing the "uninteresting grunt work" for someone else. For example, writing a compiler. To a geek, that's far mor fun than implementing a payroll database for the one billionth time.
Even if the programmer is very highly skilled, memory management is tedious and difficult, and it is impossible to never make a mistake.
This is simply false. I've never made such a mistake, not in 20 years of coding. When I'm the technical lead or architect for a project, there are no memory leaks in the project (or at leats none where I have authority). It's a matter of programming style (and using C++, not C). I have, however, had to fix others' memory leaks in garbage-collected languages. You have to try pretty hard to leak memory in C#, but it's not perfect.
Non-managed languages should be used only when the performance benefits outweigh the dangers.
Naturally, every tool should be chosen such that the benifits outweigh the dangers. But it's not just performance: garbage collect languages only manage memory for you, not file handles, locks, or other resources. A generation of programmers with no resource allocation discipline *at all* has led to some pretty bad leaks of resoruces other than memory.
Socialism: a lie told by totalitarians and believed by fools.
Yeah, but C/ASM/a custom ASIC is still faster for $SPECIFIC_THING so it's slow.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
And yet you're incorrect. Further, I could teach you how to do the same, as I have many people over the years, from junior programmers to team leads. Like I said, a coding style requiring you to check for mistakes in every function or class means mistakes are inevitable. That's why I've never liked C. However, there are C++ coding styles where the particular problem of leaking resources becomes very simple and managable.
I work on the sort of software where resource leaks (in particular) are going to be noticed. I've worked for companies with QA engineers who were dedicated full time to leak detection, because leaks in production code would affect customer perception of the product quite badly.
Socialism: a lie told by totalitarians and believed by fools.
Java is faster then C++ for any non trivial use case. This is because of 2 reasons:
- It compiles more natively then C++: C++ is compiled for just "Windows", while Java is hotspot compiled at runtime (where necessary, after a startup delay) to "Windows XP SP3 Intel processor".
- A garbage collector is faster for non-trivial use cases then malloc because it can free entire chunks of memory at once. When someone walks into your living room with muddy shoes, it's more efficient to mop the entire room then it is to clean only the footprints with a toothbrush.
As a planning solving programmer, I 've seen this in practice.
Planning problems are problems that run for hours and do virtually no IO, they simple take up all the CPU power and evaluate an exponential of billions solutions.
Real-world use case performance competitions prove that Java implementations are faster then C++ implementations:
- Terrabyte sort benchmark: http://sortbenchmark.org/
- International timetabling competition: http://www.cs.qub.ac.uk/itc2007/
Java does have downsides over C++: it has a terrible warmup time and it loves to grab and hold lots of RAM, because garbage collectors work faster with more RAM. So in use cases like gedit/kate/jedit where startup time is more important than performance, I'd stick with C++.