Editor's Daily Blog: A split in Java

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.

The JELC 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 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 thejava.net News RSS feed.

Current and upcoming Java Events :

July 23 - 25 Desert Southwest Software Symposium
July 29 O'Reilly Open Source Convention

Registered users can submit event listings for the java.net Events Page using our 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 Java 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 java.net Archive.

Bookmark blog post:

del.icio.us

Digg

DZone

Furl

Comments

Comments are listed in date ascending order (oldest first) | Post Comment

Anxiety is unfounded
Calling 5 a split in Java is quite melodramatic. Given that Java is 8 years old it stands to reason that there are heck of a lot of experieinced Java programmers. I do not think many of them are going to have trouble transitioning to 5. However it is quite possible that new comers to java might have a slightly steeper learning curve. I do think many of the features do make Java a lot easier at least from my perspective. As to how all this is going to be used, its sort of like a car isn't it. If driven safely and with common sense its all right but its also killing more humans per capita than the second world war.

Posted by: suhail on July 21, 2004 at 03:06 AM

Split in Java
I dunno about a split. I think most people will live with the new stuff.

However, we are moving towards an undiciplined Java. That is, Java 5 will be to Java 2 what C++ was to C (not a perfect analogy). "Pro" developers will love it, hackers will prefer it.. but those commitee types, the coding standards types will hate it (I'm one of them :) ).

Java has matured.. and as such we will be seening more spaghetti and hacks than ever.

Posted by: dog on July 21, 2004 at 03:59 AM

Easier to use - for whom?
The obvious problem with making a language easier to use is deciding who it is that you want to make things easier for.

If you are interested in making writing EJBs easier, then XDoclet was fine. If you are concerned with making it easier to get "richer" descriptions of objects at runtime, then you have to go for Java metadata.

My own focus seems to be in making it easier to map requirements to implementation... this seems to cry out for higher level or more domain specific language features.

I think that "Groovy" is a portent of the future for making things "easier". I'm personally wild about Groovy itself, but I am happy to see a widely supported alternative to the Java language that is compatible with the Java ecosystem.

In many ways, Java Server Faces is also going in the direction of a seperate language also. JSF certainly doesn't look like either HTML or Java... it's more like (and should probably be recast as) a domain specific language for writing web-based front ends.

Perhaps splits in Java are really a good thing...

Posted by: johnreynolds on July 21, 2004 at 05:57 AM

Easier to use - for whom?
Most of my C++ programming friends won't touch Java as long as C++ Templates are not in place, so for the first time even those people will be able to move to a more mature language without finding they have to loose all those nice features they are used to.

Posted by: zander on July 21, 2004 at 05:16 PM

Powered by
Movable Type 3.01D

java.net RSS Feeds