Welcome!

Java Authors: Elizabeth White, Pat Romanski, Liz McMillan, Sandi Mappic, Esmeralda Swartz

Related Topics: Java

Java: Article

One Size Fits No One

At a presentation given by Josh Bloch he made a comment that Java as a language hit the 'sweet spot'

At a presentation a number of years ago given by Josh Bloch he made a comment that Java as a language hit the "sweet spot" of programming. His metaphor was based around the fact that the language was straightforward to learn and that rather than containing many esoteric coding constructs, writing and understanding a Java program was a relatively easy task.

I think Java is at a very critical point at the moment where it is slipping away from its sweet spot and this worries me. Two things are to blame: annotations and aspects.

An annotation allows a programmer to flag a part of a program with @ statements that at first glance are a glorified comment. A developer can define his or her own annotation that has typed properties and validation rules about where it can be used in code, both of which the compiler enforces. What you do with annotations is up to you, but a good example could be to formally flag which methods were fixed in a particular release, by whom, and why. For example, with an annotation called Mod you could write code like:

@Mod(bugNumber=5477,fixedBy="Fred");
public void foo(){
   ...
}

This is better than putting the details in a comment // Fixed by Fred for 5477 because programs can use the java.lang.reflect API to query classes and methods for the presence of annotations, so a report of fixes done by Fred could be written.

The problem occurs when an annotation is more than a glorified comment and contains information that is an instruction to the program itself. EJB 3.0 has fallen desperately foul of this and I saw some horrid sample code recently:

@Stateless
@Remote(Example.class)
public class ExampleBean implements Example
{
   @PermitAll
   @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
   public String getName(int id)
   {
   // Method body here
   }
   @RolesAllowed({"administrator","power_user"});
   public void deleteName(int id)
   {
   // Method body here
   }

What has occurred is, basically, a ton of semantic program details about how the EJB should be deployed that used to be provided in the deployment descriptor has been slammed into the class as annotations. It is way, way wide of the sweet spot and looks more like a cross between a set of assembler op-codes mixed with some kind of fourth generation language syntax. Whatever it is, it isn't Java.

Kent Beck once said that having lots of classes and lots of methods is basically what good OO is about. Design Patterns, the bible of good OO practice, espouses patterns such as the strategy and mediator that encourage and teach the strength and power of separation. By contrast, the EJB specification actually boasts the fact that having everything defined in a single file is a good thing. Separate XML wasn't great but what would have been wrong with just moving from XML to something akin to BeanInfo where the logic and rules were held in Java code elsewhere?

This segues nicely into aspects. At the first presentation I saw on the subject I was told that the raison d'etre for their existence is so that only a single source file has to be touched to implement a piece of functionality. While I understand this as a goal, it just isn't really practical to make this your overriding goal and then jump through hoops to ensure that this is the focus of all your development. In my experience, with all but the most trivial change, to fix a bug or implement a feature you need to change several classes, perhaps an interface or two, and hopefully do some refactoring along the way to improve the overall system entropy. There is nothing wrong with good old-fashioned programming like this and, when I encounter aspects, I see a group of people driven with a zeal to do differently. Instead they code files that contain sets of instructions to a preprocessor that will go and modify the existing multiple files that you should have fixed by hand in the first place. As with annotations, there are good uses of aspects, namely introducing logging behavior, performing code metrics, or coding rule enforcement. Too far beyond this and they just become clever magic that is both confusing and silly. Aspect fever seems to be riding the hit parade at the moment as the silver-bullet answer to everyone's problem.

What both annotations and aspects bring to Java is some kind of powerful dark magic where source is now littered with semantic fluff disguising itself as something more trendy but wielding terrible power. What you write is no longer what gets run - someone else's preprocessor mangles it, clever code obscures this fact from you while you debug it, and rather than the JVM just executing the bytecodes from the source you wrote, there is now some kind of execution inference engine analyzing formalized comments to determine the code path instead.

I fear the worst for the language. Pandora's box has been opened, Java coding no longer has any rules to govern it, and muggle programmers are no longer safe.

More Stories By Joe Winchester

Joe Winchester, Editor-in-Chief of Java Developer's Journal, was formerly JDJ's longtime Desktop Technologies Editor and is a software developer working on development tools for IBM in Hursley, UK.

Comments (6) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
peterk 10/21/05 10:43:07 PM EDT

I've been doing quite a bit of .NET programming against some "legacy" web services on Java-based Axis. Almost all of the linkage between the .NET classes and the web-services XML is done with attributes in the class definition. Like magic, it hides a lot of stuff and makes some debugging a lot harder, and you have to know the correct magic words.

BUT... This is what Microsoft does: it lowers the bar for entry level and intermediate programmers, and makes the code much more opaque to those who have to get into the guts to debug or tweak behavior.

Java, on the other hand, should stick to power and elegance through simplicity. If attributes are to be used, then keep the effects simple and clear, and don't hide the generated code.

--Peter

slackerdave 10/21/05 10:16:31 AM EDT

Trackback Added: One Size Fits No One Indeed…; One Size Fits No One
— At a presentation a number of years ago given by Josh Bloch he made a comment that Java as a language hit the ’sweet spot’ of programming. His metaphor was based around the fact that the language was straightforwar...

ed 10/21/05 05:30:52 AM EDT

I agree with this article entirely. Surely we learned from our initial mistakes from EJB 1 with the likes of entity beans. What is with the complexity? If it carries on like this, we will soon have masses of "developers" ala Clarion/VB etc. No IDE no code?????

Infernoz 10/21/05 02:43:16 AM EDT

Agreed, Aspects are bogus since they modify the source in possibly unexpected ways and without showing the developer the final results, so debuggers effectively become useless! As for annotations, there are some legitimate uses, but other techniques like proxies (not just java.lang.reflect.*) can be more readable, easier to debug and don't require Java 1.5, quite a critical requirement for a lot of mission critical code!

JDJ News Desk 10/19/05 01:24:47 PM EDT

Java Developer's Journal - One Size Fits No One
At a presentation a number of years ago given by Josh Bloch he made a comment that Java as a language hit the 'sweet spot' of programming. His metaphor was based around the fact that the language was straightforward to learn and that rather than containing many esoteric coding constructs, writing and understanding a Java program was a relatively easy task.

Gurvijay Singh Bhatti 09/29/05 05:38:05 PM EDT

When I was writing real time complex software, the complexity was in the application not in the code. Simple C or C++ would do. Debugging was easy, though there were lots and lots of threads but we know where the code is and what it was doing.

Then comes the tech boom, when every spreadsheet was to be converted into a web application. Humans want to be praised, so to write a simple application simplicity does not bring any praise, then comes hoard of XML configurations and frameworks and so on. This caused a small application to look like a bloody complex piece of software.

That trend is still going on. Imagine a complex application written using complex frameworks and XML configuration files. It will be a nightmare to maintain it.

I would like to keep everything simple and nothing more.