JSR 308: Unwarranted Increase in Java Language Complexity?

by Alexander Olaru on May 14, 2008 |

The overview of JSR 308 (Annotations on Java Types) took an important stage as part of last week's JavaOne presentation about new language features proposed for Java SE7 ("TS-5581: Upcoming Java Programming-Language Changes"). Other new features covered by the presenters - Alex Buckley (Sun Microsystems), Michael Ernst (MIT) and Neal Gafter (Google) - were: Improved catch clauses (multi-catch), Safe re-throw, and Java Modules.

JSR 308 attempts to solve two issues currently present in the Java 1.5 annotations:

  • Syntactic limitation on annotations: Annotations can only be written on declarations
  • Semantic limitation of the type system: The type system does not prevent enough bugs

The solutions provided by JSR 308 to these problems are:

Extend the language syntax to permit annotations in more locations which include: method receivers, generic type arguments, arrays, typecasts, type tests, object creation, type parameter bounds, class inheritance and throws clauses.
Enable creation of more powerful annotation processors through the introduction of pluggable type systems. Code annotated with type qualifiers can be analyzed by type checkers which will warn about violations (bugs).

Following this presentation, Michael Nygard wrote about JSR 308 in the When Should You Jump? JSR 308. That's When. post about his views on the impact of the JSR 308 on the language and the Java developers. After providing a few examples in his post on how these annotations can be used, Nygard argues that this JSR alongside with the generics introduced in Java 1.5 increase the language complexity with little added benefit:

Every language has a complexity budget. Java blew through it with generics in Java 5. Now, seriously, take another look at this:

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>

Does that even look like Java? That complexity budget is just a dim smudge in our rear-view mirror here. We're so busy keeping the compiler happy here, we'll completely forget what our actual project it.

Nygard sees the timing of the new proposal even more worrisome given the increasing interest among developers towards dynamic languages:

All this is coming at exactly the worst possible time for Java the Language. The community is really, really excited about dynamic languages now. Instead of those contortions, we could just say:

var strings = ["one", "two"];

Now seriously, which one would you rather write? True, the dynamic version doesn't let me enlist the compiler's aid for enforcement. True, I do need many more unit tests with the dynamic code. Still, I'd prefer that "low ceremony" approach to the mouthful of formalism above.

Nygard believes that Java developers should jump to a new language when JSR 308 becomes part of the language and concludes:

So, getting back to that mainstream Java developer... it looks like there are only two choices: more dynamic or more static. More formal and strict, or more loosey-goosey and terse. JSR 308 will absolutely accelerate this polarization.

Unsurprisingly, this point of view generated a number of reactions from various commentators. cfagan responded to another commentator who found that annotations are a convenient escape route for developers to not have to read the API docs or focus and think about what they are doing:

In the end the code is the ultimate documentation. These annotation attempt to express intent. Which is something that can be lost with documentation when it's not kept up to date, or missing. I agree that superior talent produces superior results, regardless of language. Still moving any runtime error to compile time speeds up the development process and saves the overhead of a bug that would otherwise be caught by testing.

Josef wrote about the optional nature of the annotations and shared his view about their probable adoption path. He argues that Nygard:

[...] talks like the annotations JSR 308 enables are mandatory and that all Java programmers have to write them from the moment JSR 308 is accepted. I expect that very few Java developers will be using them in the beginning. It will only be companies that write very high assurance software and that need these kinds of things to specify correctness condition and check them automatically or semi-automatically.

and explains how they are different from generics:

The nice thing with these annotations is that they are always safe to ignore. You cannot of course do that with generics because then you wouldn't know what type your program had. But with JSR 308 annotations you can code along just fine without paying the least bit of attention to them. They only come in play when you start using a checker that actually cares about the annotations.

The "Upcoming Java Programming-Language Changes" presenters summarized the main principles by which new features to be added to the Java language should be evaluated, as follows:

  • Encourage high-level practices (Do the right thing)
  • Covet clarity (Do the thing right)
  • Prefer static typing (Stay safe)
  • Isolate the language from APIs (Stay abstract)

Based on the context of these principles, JSR 308 seems to fit well with the general future direction of the Java language. Are the recent discussions around the addition of this new feature representative of certain diverging interpretations of these principles or do they signal concerns with the principles guiding the Java language evolution set forward by its stewards?

Related Editorial

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Some real benefit by Rod Johnson 

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>


It's optional. It adds some documentation and compiler enforcement. If you don't like it, don't use it.

I don't see a problem here. I would personally like to have this choice.




Rgds

Rod

Not a fan of multi-catch by Rod Johnson

Must admit I'm not a fan of the multi-catch concept. This introduces a concept of sharing methods other than by Java inheritance which seems to me to be a fundamental language change for a small convenience. If this were introduced, I think such parameter types should be made available to arbitrary methods.

Re: Some real benefit by Stephen Molitor

It's optional. It adds some documentation and compiler enforcement. If you don't like it, don't use it.


Yes but others have to read it if you write it. Otherwise just use Perl, a write only language. There's more than one way to do it -- if you don't like a feature don't use it. We can see where that got us with C++ and Perl.

Java has become the breadboard of programming languages... by Clinton Begin

I find Sun's lack of understanding and focus, disturbing.

Rather than focusing on a full upgrade with language integration features for backward compatibility (see Groovy or JRuby), Sun and the JCP have decided to evolve Java with the idea that software developers enjoy half-implemented, inconsistent bolt-ons that are completely out of place. And they even manage to do a piss-poor job of that.

Java should not have evolved in this way. It's irresponsible, unprofessional and it will ultimately spell the beginning of the end for Java.

There's no defending this sort of ad hoc evolution, while clearly missing the mark on so many other (simple) things. It's clear that the JCP expert groups are treading to keep their heads above water, with limited (or no) budgets, artificially constrained schedules and a lowest common denominator to satisfy.

I'm disgusted by this lack of focus and absolute ignorance about what developers need in the world's most popular programming language.

Java will fail, if it has not already begun to. Long live other languages on the JVM... hopefully.

Clinton

Re: Java has become the breadboard of programming languages... by Clinton Begin

Dear InfoQ: There were line breaks in that post. Perhaps JSR-2113492 will add a language level "Ease of Use" feature for textile rendering, with a keyword. ;-)

Re: Some real benefit by Keith Haber 

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>();


Maybe the above is just a bad example of what the JSR is all about. (And I'd accept that argument, especially since creating a new empty ArrayList probably isn't supposed to compile with that @NotEmpty annotation... :-) But it seems to me that a better approach to this kind of situation would be a normal interface rather than annotations. I'm thinking something simple like:



public interface NotNullList<T> extends java.util.List<T>{}



Then instead of the JSR-308 annotation example, I'd be using a List implementation that obeys the NotNullList contract, and I'd find myself with something more normal-looking:



NotNullList<String> strings = new NotNullArrayList<String%gt;();



Which is still assignable to a normal List<String> (because it is one). The not-null constraint would be enforced at runtime instead of compile-time, but runtime checks would only happen when the list is created/modified, and I could safely skip testing for nulls when iterating over the contents of the list. No weird language features or special annotation handlers in the compiler required -- just a simple, boring object obeying its contract. Is making this type of check at compile-time instead of at runtime worth the extra language complexity? I'd have to say I agree with the author of the linked blog that it's probably not in this case, and I'm usually a big fan of static typing.



I glanced at the JSR summary page linked in the article. One example of the proposed syntax is this Map declaration:




Map<@NonNull String, @NonEmpty List<@Readonly Document>> files;



I find this declaration to be... impressive. But I realized that the idea could be taken further - how about including regex validation annotations on String values? Then we could make the declaration even *more* "safe":




Map<@NonNull @MatchesRegex("\\d{8}\\.\\d{3}") String, @NonEmpty List<@Readonly Document>> files;




Well, why not? :-) Personally, I'd say defining a DocumentDirectory class to impose these constraints would be much better for developer productivity.



Keith

Re: Java has become the breadboard of programming languages... by Maurizio Turatti

+1

I think even the move to Java 5 has not yet happened in the enterprise, I still see a lot of Java 1.4 development. Sadly, Java is going toward complexity, but the average developer is not necessarily a genius and needs something simpler than a new version of unreadable C++


My mind is limited so I'm already jumping into Groovy when I can.

Re: Java has become the breadboard of programming languages... by Yasin Hamid

+1


I totaly agree. What I liked most about Java was its simplicity. It all changed with Java 1.5 and it's getting worse and worse.

Re: Some real benefit by Marc Stock

I would prefer they make the language more simple and easier to read, like adding inferred types before they think about ways to make it more complicated. It shows extremely poor prioritization and just lends itself to the ugly syntax referenced above. One of the best things about Java has always been that because it's simple it's easier to read/understand than most other languages. They are destroying that release by release.



As for multi-catch, I'll take it. It improves readability by reducing the amount of unnecessary code that must be written. The formula for all new features to Java should use the formula: less code, less complexity = good; more code, more complexity = bad. Of course, I could be wrong and the reason people are flocking to dynamic languages is because of the free pizza and beer.

Retarded by Simon Lin

As Dr. Venkat Subramaniam once said, Java Generics is already retarded. This just seems like another step toward retardation. I don't understand how they can pull this feature out of nowhere while ignoring others, such as a TRUE Generics implementation and Closure, which the developers have been crying for.

Now back to that example:

@NotEmpty List<@NonNull String> strings = new ArrayList<@NonNull String>()>
<bloclquote></bloclquote>
That is totally tailored for incompetent programmers who don't even know whether their lists are empty or can have null elements and don't write any unit test. Is Java becoming the nanny government of the programming language? </@nonnull></@nonnull>

A language is like an object... by Francois Ward

I always felt that a programming language (not talking about the framework here) should be like an object in OOP. It should have one ultimate function, and do it well.



Java had always striked me as a "pure" language... Very few constructs, fully centered on purist-style OOP, with almost everything implemented in the framework and libs, aside for the core constructs that were selected as "what java should be".



If you needed anything beyond that, frameworks such as Spring or J2EE itself were what you used. It created a very "clean" community. If I take 10 java projects from serious companies, 8 of em will use the exact same conventions, the exact same patterns, the same way of coding, and on those 10, 5 of em will even use the same frameworks to solve the same solutions.



The more you add, the less that becomes true. I am personally a C#/.NET programmer, but I always envied the Java world because of that. In .NET (i'm a consultant/contractor), if I work for 10 companies in a row, everytime I felt like I had to start from scratch. Everyone uses the framework -totally- differently (its not even CLOSE, from conventions, to framework design, to librairies, to architecture). C#/.NET has the advantage of being the kitchen sink, a C++/VB6/Java hybrid, at the cost of uniformity and purity.



So, until more recently, if you wanted that kitchen sink (at the language level, I'm not talking about the ecosystem here), you went the .NET path. If you wanted purity (which is a very, very disirable thing to have), you went Java.



But now, Java is going the way of .NET, while its current users are closer to the purist lines, all while considering the fact that it was never designed for this in the first place.



In other words: its a royal mess.

The race is on... by Jim Leonardo

To see which language can become more complex... Java or C#. Maybe we all need to sit back and say "General Purpose Programming Languages don't need to do everything".


I like the intentions, but as Keith H. points out, there may be ways to accomplish the same things within the bounds of the existing language and still be pretty safe. I'm sure everyone here will agree that more lines of code is not the same as better code. In the same manner, adding language constructs is not the same as a better language.

Re: The race is on... by Clinton Begin

C# is not complicated at all. It's feature-rich, but consistent. There are a few things in C# that I do tend to ignore, but they're not as horrid as anything Java 5 exposes. Everything in C# works as expected in my opinion. And I'm a Java programmer of 10 years, C# for about 2 years and Ruby for 1 year... I find Java more complicated, inconsistent and generally crappy than the others. Sad. It was so unecessary.

Re: Java has become the breadboard of programming languages... by Rai Singh

+1
Just take a look at IBM WebSphere...it's still 1.4. Imagine the migration path with WebSphere App Server or Portal applications. With that said, going to Java 5 just doesn't make a whole lot of sense if these type of language features are going to increase complexity. What race is the JCP and Sun running? I like the idea of scripting language support, but Groovy still compiles down to Java.

Re: Java has become the breadboard of programming languages... by Peter Maas

@Rai Singh:

Actually Groovy doesn't compile down to Java, it compiles to bytecode directly.

Re: Java has become the breadboard of programming languages... by Rai Singh

absolutely. my mistake :p)

not a good idea by serge boulay

this would be a bad idea. However, I would support the inclusion of closures in the java language.

Re: The race is on... by George Jiang

To start with, there is that "override vertual" in C# :-).

Of course, there are things better in C# than in Java such as generics collections or generics methods/functions. But the C# language is huge.

Re: Java has become the breadboard of programming languages... by George Jiang

WebSphere 6.1 (went into production about 2 years ago) is on Java 5. It is the J2EE version which is 1.4 :-)

Re: Java has become the breadboard of programming languages... by George Jiang

Should say "GAed 2 years ago".

Re: The race is on... by George Jiang

Sorry, I meant to say "to start with, there is that 'new and new virtual' for subclass methods in C#".

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

21 comments

Educational Content

General Feedback
Bugs
Advertising
Editorial
 InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy