Java Annotations(whyjavasucks.com)
whyjavasucks.com
Java Annotations
http://whyjavasucks.com/Blog/5/Java_By_Example/93/Java_Annotations
12 comments
This post was killed by user flags.
What is the point of this article? To vent about how much they dislike Java? It's clearly not to educate, as the least they could do is try researching how to do repeating annotations in JDK 8:
http://softwarecave.org/2014/05/20/repeating-annotations-in-...
And it's clear from reading the annotation documentation that null is not a valid value. It might be surprising to some developers, but it was a conscious decision made by the spec designers. It also shouldn't be a surprise to the author that Java is smart enough to forbid you to set a null value regardless of whether it was specified directly or they used a constant:
http://stackoverflow.com/questions/1178104/error-setting-a-d...
"I hate X" piece like this do nothing to advance the discussion on language features. They only add a bunch of noise and ramp up the flamewars on both sides.
http://softwarecave.org/2014/05/20/repeating-annotations-in-...
And it's clear from reading the annotation documentation that null is not a valid value. It might be surprising to some developers, but it was a conscious decision made by the spec designers. It also shouldn't be a surprise to the author that Java is smart enough to forbid you to set a null value regardless of whether it was specified directly or they used a constant:
http://stackoverflow.com/questions/1178104/error-setting-a-d...
"I hate X" piece like this do nothing to advance the discussion on language features. They only add a bunch of noise and ramp up the flamewars on both sides.
Agreed. I am impressed by OP's energy to even create such a site and go into so much detail, but put it to better use.
The article was published 5 days before the release of Java 8 - at least if my quick googling was correct. That might explain why it doesn't mention repeating annotations as a solution.
But the feature was in the pipeline for Java 8 since 2011[1], and there were multiple blog posts since then, like [2] and [3].
[1] http://openjdk.java.net/jeps/120
[2] http://blog.functr.com/2012/09/java-8-features-discover-repe...
[3] http://java.dzone.com/articles/subtle-changes-java-8
[1] http://openjdk.java.net/jeps/120
[2] http://blog.functr.com/2012/09/java-8-features-discover-repe...
[3] http://java.dzone.com/articles/subtle-changes-java-8
Comparing C# and Java is so last decade. I don't use Java because of the language, but because of its enormous toolset and awesome community.
If there is something I can't do well with Java, then I have Groovy. I will most likely waste time trying to implement the same thing with C#. In fact I would probably just use Python or C instead.
If there is something I can't do well with Java, then I have Groovy. I will most likely waste time trying to implement the same thing with C#. In fact I would probably just use Python or C instead.
This! I really don't know why those comparing languages fail to recognize that a language's success has got much to do with the "ecosystem" as well; tool-set, libraries and so on.
The main reason I don't use Java is because of the (de-facto) tooling - maven in particular is completely opaque to me and seems very resistant to experimenting to figure out how it works (though I am having to work with deeply nested poms and custom plugins).
I've used build/release management/dep management tools from/like go, python, ruby, node, erlang, make, autotools and cmake and I've never before had to read a manual to tweak an existing setup.
Go is probably my favourite ecosystem because everything is very simple. I suspect Rust will be good as well.
I've used build/release management/dep management tools from/like go, python, ruby, node, erlang, make, autotools and cmake and I've never before had to read a manual to tweak an existing setup.
Go is probably my favourite ecosystem because everything is very simple. I suspect Rust will be good as well.
maven is fine if you want to get started and get a deployment going. But I agree with you, if your requirements are even slightly off maven's defaults (e.g., different build directory) then you will be in loads of pain.
The first step to improvement is acknowledging your shortcomings. It's very easy to just accept things as they are and consider them set in stone, when your entire community adopts the mindset it leads to stagnation and cargo cult programming. Good ideas should be adopted no matter where they originated.
Fortunately not everyone in the Java community is happy with the way things are. Indeed, Java 8 fixes some of the issues mentioned here, like repeating an annotation. Obviously this wasn't some brilliant insight developed in a vacuum, people looked at C# and thought "Neat, I want that!", and now Java is a better language because of it.
As engineers we should not settle for the way things are. One day we'll hopefully have Reified Generics, maybe properties and other obviously good ideas, and no thanks to the people who are happy with Java as it is now. "People who say it cannot be done should not interrupt those who are doing it" comes to mind.
Fortunately not everyone in the Java community is happy with the way things are. Indeed, Java 8 fixes some of the issues mentioned here, like repeating an annotation. Obviously this wasn't some brilliant insight developed in a vacuum, people looked at C# and thought "Neat, I want that!", and now Java is a better language because of it.
As engineers we should not settle for the way things are. One day we'll hopefully have Reified Generics, maybe properties and other obviously good ideas, and no thanks to the people who are happy with Java as it is now. "People who say it cannot be done should not interrupt those who are doing it" comes to mind.
And C# can't (directly) run on anything not built by Microsoft. For those of us focused on shipping products to cross platform users, there are handfuls of languages better than C# in that regard. There are things every language does poorly and well, but you also don't see us making whycsharpsucks websites because we're probably too busy building things.
I just don't see the need for this kind of negativity. If a language wasn't designed for a certain way of using annotations (or any feature), maybe another method should be tried to get similar results. It may not be ideal and may not fit the paradigms of what you're used to, but it's a completely different language for heaven's sake.
It's like asking why a Honda Accord isn't faster than a Lamborghini... But at least the Accord holds 4 people and has useable trunk space. They're built for different needs, nobody expects an accord to race well, and nobody expects a lambo to be good for soccer moms and off-roading. So why the hate?
I just don't see the need for this kind of negativity. If a language wasn't designed for a certain way of using annotations (or any feature), maybe another method should be tried to get similar results. It may not be ideal and may not fit the paradigms of what you're used to, but it's a completely different language for heaven's sake.
It's like asking why a Honda Accord isn't faster than a Lamborghini... But at least the Accord holds 4 people and has useable trunk space. They're built for different needs, nobody expects an accord to race well, and nobody expects a lambo to be good for soccer moms and off-roading. So why the hate?
As of Java 8, repeated annotations are allowed (and are backwards compatible). Also, Java 8 annotations now serve as the basis for Java's pluggable type systems[1].
One of the available pluggable type systems adds physical units, something that, AFAICT, is certainly not trivial even in Haskell[2].
So the author may not like the decision not to allow null values in annotation arguments, but Java annotations have actually become a very powerful tool.
[1]: http://blog.paralleluniverse.co/2014/05/01/modern-java/#adva...
[2]: http://www.haskell.org/haskellwiki/Physical_units
One of the available pluggable type systems adds physical units, something that, AFAICT, is certainly not trivial even in Haskell[2].
So the author may not like the decision not to allow null values in annotation arguments, but Java annotations have actually become a very powerful tool.
[1]: http://blog.paralleluniverse.co/2014/05/01/modern-java/#adva...
[2]: http://www.haskell.org/haskellwiki/Physical_units
I'm not sure if annotations are designed for this kind of usage.
Most if this is just praising or criticizing syntactical sugar. And it's a weird and manipulative writing style to tell the reader "this is how you need to do it" followed by examples that don't even compile - simply to include some oh so bad compiler errors.
Why does the author seem surprised when his code doesn't compile after adding a non-optional parameter? It's arguable whether parameters should be optional by default or mandatory by default. Not really knowing much about c# I guess anything besides primitives will be `null`, which doesn't seem like you gain much.
I'm not sure I have ever seen annotation used like in this `whenType` example. Besides that the whole approach looks suspiciously complex (why not just create `@DefaultPriority` which you can add to your type?), annotations are supposed to be simple meta data and you shouldn't be trying to implement some kind of logic with them. Any logic like this should be done when processing the annotation in my opinion.
Java annotations sure are limited and it's does seem kind of weird that you can't use null as default value. But I never encountered any real problems that couldn't be handled by inspecting annotations using reflections or annotation processors.
Why does the author seem surprised when his code doesn't compile after adding a non-optional parameter? It's arguable whether parameters should be optional by default or mandatory by default. Not really knowing much about c# I guess anything besides primitives will be `null`, which doesn't seem like you gain much.
I'm not sure I have ever seen annotation used like in this `whenType` example. Besides that the whole approach looks suspiciously complex (why not just create `@DefaultPriority` which you can add to your type?), annotations are supposed to be simple meta data and you shouldn't be trying to implement some kind of logic with them. Any logic like this should be done when processing the annotation in my opinion.
Java annotations sure are limited and it's does seem kind of weird that you can't use null as default value. But I never encountered any real problems that couldn't be handled by inspecting annotations using reflections or annotation processors.
Like Roman Empire, Java will take a long time to become irrelevant despite continuing stream of hindsight rants.
Annotation in itself is not bad IMO. Used carefully as language-level extension mechanism like it is being used by Swift, it's useful.
What I disliked when annotation was first introduced is User-defined Annotation because the feature in-effect turns code into magic.
Annotation in itself is not bad IMO. Used carefully as language-level extension mechanism like it is being used by Swift, it's useful.
What I disliked when annotation was first introduced is User-defined Annotation because the feature in-effect turns code into magic.
Annotations in Java cannot inherit from other annotations. This has been known for a long time:
http://stackoverflow.com/questions/1624084/why-is-not-possib...
Not sure why it is a surprise to the author.
http://stackoverflow.com/questions/1624084/why-is-not-possib...
Not sure why it is a surprise to the author.
Could be worse...PHP uses comments for annotations..how do you like them apples?
I left Java around 2010 for a role that let me focus on data and PostgreSQL for a while, and I don't like the language anymore. I've probably been spoiled by Clojure and Python.
Comparing Java and .NET is unfair. Java was created in the 90's. .NET is way younger than that. .NET was created with Java in mind, and of course it's a better language.
Each language has its strengths.
Each language has its strengths.
It's only unfair if you consider Java as done and set in stone. But it doesn't have to be that way, and fortunately it isn't; Java is still improving by adopting ideas which have proven themselves to work in other programming languages. Java 8 is a better language today because of the obvious influence of C# (among others).
.NET was originally supposed to be an embrace... extend... extinguish strategy by Microsoft on Java wasn't it? I seem to remember when .NET first came out people saying that you could almost copy and paste C# and Java code back and forth.
I think J++ was Microsoft attempt at extending Java. According to wikipedia it was Microsoft's implementation of Java. After getting sued by Sun they moved on to .net where C# did look remarkably Java like initially but since it was incompatible with Java I wouldn't call .net a EEE strategy.