Posted by daniel
on July 21, 2004 at 8:40 AM PDT
What happened to making it easier?
What happened to making it easier?
Ted Leung blogged about the recent SeaJUG post JavaOne meeting. He reports that there "was some feeling that Java 5 was going to create two languages, pre Java 5 and Java 5. The fact that many of the new JSR's are already incorporating generics and attributes will only strengthen that separation. A few people felt that it would be even worse, that due to the timing of the releases, Java developers would actually have to deal with 3 dialects of Java. Takes a bit of wind out of the write once run anywhere sails."
He ends by repeating a question asked by one attendee, "what happened to making it easier?"
That is an important and core question. Much of the Java promise was that developers would be able to identify and fix mistakes at compile time. Without the explicit pointer arithmetic, some of the obscure tricks of C and C++ were not available to Java developers. On the other hand, this made Java code easier to understand. Maybe once I have spent more time with generics and metadata and other language additions, I will find code that uses these features more readable than I do today.
For now, I worry that we are making Java code harder to read. Also, there is no way to ensure that these new language features will be used for good and not for evil. Maybe that's a bit melodramatic. Consider metadata - there are solid uses of decorating code to make it more readable. For example, adding metadata to a property that automatically generates a getter and setter that you would write by hand seems harmless - although it does seem to argue in favor of Allen Holub's complaints about getters and setters. But as more of our programming logic moves to the metadata, it becomes harder for the compiler to help us and harder for us to spot our errors. Are we headed for a split in Java? Is it any different than the split between people and programs using AOP and those not?
In Also in Java Today , the book "Better, Faster, Lighter Java" offers five principles for "combating the 'bloat' that has built up over time in modern Java programming". In Better, Faster, Lighter Programming in .NET and Java , co-author Justin Gehtland takes those principles and and applies them to the .NET platform. .NET is supposed to offer a response to the accumulated bloat in COM, and Justin says its up to developers to lighten that load.
In a recent Core Java technical tip, John Zukowski explains Understanding Rendering Hints . He shows you how to apply alpha levels, color rendering, dithering, fractional metrics, interpolation, rendering, stroke control, and text anti-aliasing.
The EJB metaphor contest continues in
Weblogs with David Rupp's post Everything I need to know about EJB I learned from watching Bugs Bunny. You'll find "leave the singing frog alone", "the roadrunner probably isn't worth the effort", "ACME = CRAP" (should probably be ACME == CRAP), "An umbrella provides very little protection from falling anvils", and "Consequences, schmonsequences, as long as I'm rich".
John Reynolds has been reading Esther Dyson and recounts his thoughts in Dyson's Meta-Mail: merging email with business processes . He writes "email needs structure. Without structure there is not much that can be done to categorize email beyond the results of text searches. In Dyson's words:
'Text search can catch topics (or nouns, what something's about), but it can't catch the implicit 'transactions' (or verbs, such as commitments, deadlines and decisions).'"
Hans Mueller responds to Joshua Marinacci by saying " the next time a fellow developer asks you about consumer facing Java, or Java in web advertising, you can tell them not to worry. Java is already a part of their paycheck." In Desktop Java: Over Three BILLION Videos Served Mueller explains why "It's all about advertising".
In today's Forums , moderator Ron Hitchens asks if you Always override hasCode when you override equals . ". The hashCode() and equals() methods are inextricably linked. Have you ever run into problems caused by failing to keep these two methods in sync? How did you find it? Are overriding hashCode() or equals() too tricky for the average Java coder? "
S Blundy provides a link on Avoiding creating duplicate objects . "Here's a paper on IBM's site that addresses Object Pools, plus Finalizers and Immutability as a bonus. http://www-106.ibm.com/developerworks/java/library/j-jtp01274.html"
As for Eliminating obsolete object references , Berend writes "We had a class in which we kept object references to set the layout of them dynamically. These were kept in a list. As you may guess, we forgot to remove references from the list as they no longer became necessary. And no, it was not a Weak-Reference List either."
In Projects and Communities , the Apple software download site now includes the Mac OS X version of the BlueJ IDE. The tool targets educators and students and the new version features improvements to the UI and J2SE 1.5 support.
links to Brad Wheeler's Educause Review article Open Source 2007: How Did This Happen? looks at how OS software can meet academia's need for experimentation and innovation at a reasonable price.
In today's java.net News Headlines
Registered users can submit news items for the
href="http://today.java.net/today/news/">java.net News Page using
our news submission
form . All submissions go through an editorial review before being posted to the site. You can also subscribe to
News RSS feed .
Current and upcoming
Registered users can submit event listings for the
href="http://www.java.net/events">java.net Events Page using our
href="http://today.java.net/cs/user/create/e"> events submission
form. All submissions go through an editorial review before being
posted to the site.
Archives and Subscriptions: This blog is delivered weekdays as the
Today RSS feed . Also, once this page
is no longer featured as the front page of
java.net it will be archived along with other past issues in the