History Never Repeats
Wave goodbye to languages without garbage collection
It's not news to us -- we noted Java displacing C++ as the top language on Sourceforge a couple years ago, to say nothing of thousands of projects here on java.net. But Slashdot took the hint yesterday, asking Are C and C++ Losing Ground? They link to a Dr. Dobb's interview with TIOBE's Paul Jansen about the Programming Community Index, which "measures the popularity of programming languages by monitoring their web presence." This also shows Java on top, trailed by C, Basic / Visual Basic (which is trending upwards), PHP, and the falling C++.
Paul says the story behind the overall trends is that one of Java's defining traits, automated memory management, is increasingly being considered a neccessity:
C and C++ are definitely losing ground. There is a simple explanation for this. Languages without automated garbage collection are getting out of fashion. The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.
It wasn't all that long ago that Java's use of garbage collection was considered a ridiculous liability, a sop to bad programmers that would destroy performance and render Java totally non-competitive. It hasn't quite turned out like the critics say, and even if some naysayers still won't embrace Java, you don't exactly see Ruby or Python making developers
free their memory.
And come to think of it, could you go without garbage collection at this point? I was poking around in C the other day, and found myself unwilling to even attempt to figure out where to match my
frees, figuring I'd get the damn thing working first and then figure out how to deal with the memory leaks I was creating. Not a real sound approach, admittedly.
So, on the topic of garbage collection, the latest java.net Poll asks "Could you work with a non-garbage-collected language?" Cast your vote on the front page, then check the results page for current tallies and discussion.
In Java Today,
Joe Darcy continues a recent run of blogs discussing the specifics of what it means for changes to be "compatible" with a case study: Compatibly Evolving BigDecimal. "Back in JDK 5, JSR 13 added true floating-point arithmetic to BigDecimal, which involved many new methods and constructors along with new supporting classes in the java.math package. I was actively involved in the JSR 13 expert group and integrated the code into the JDK. These changes had some surprising compatibility impacts which can be classified according to their source, binary, and behavioral effects."
The article New Features in EJB 3.1, Part 3 is the latest installment of an ongoing series on TheServerSide by Reza Rahman, who writes, " In this third article, I'll cover two more features that have been discussed in detail--asynchronous Session Bean invocation and EJB Lite. Remember, none of this has been finalized yet. All of this is really just a peek into the inner workings of the JCP so that you have a chance to provide feedback."
JavaWorld takes an in-depth look at the Wizard project in Open source Java projects: The Wizard API. "If you're faced with creating a Swing-based wizard from scratch, you'll want to know about Tim Boudreau's Wizard project. This installment of Jeff Friesen's Open source Java projects series gets you started with the Wizard API and concludes with a hands-on installation wizard that is sure to please users and impress the boss."
We've updated this week's Spotlight on
Collabnet's tutorial and Q&A for new java.net project owners. The tutorial, held on Thursday, is now available as an WebEx recording. To learn more about setting up and managing java.net projects (including branding of left nav, project membership, roles and permissions, setting up mailing lists, etc.), check out the stream or download the entire session.
ME for Windows Mobile? Still there, as Terrence