Java developers don’t want Java annotations?
One of the important new features introduced in J2SE 5 was that of Java Annotations. With annotations, developers could now add their own attributes to Java code and provide data about data (metadata). This data in the annotations was meant to be used for code documentation, code generation, enhanced security or special business logic.
However now that annotations have been in use for some time, more views and opinions have started to come in about the utility of annotations. In a recent article Robin Sharp says “Annotations are a major kludge on the landscape. They don’t fit and we don’t need them; but you just know that they’ll be picked up by framework junkies and abused horribly.”
In his case against annotations, he says that annotations are not metaData but just decorative data. Annotations are hard coded configurations that cannot replace XML. He feels that Java annotations were just meant as a response to .NET and not something that Java developers want.
However in a recent interview with IndicThreads, Andrey Grebnev says that Java annotations is the future. Jesper Joergensen of BEA told us that “Apache Beehive stores the wiring metadata and other metadata as JDK 5 annotations in the code”
Anil Saldhana of JBoss says that “Combined with JDK 1.5 Annotations, aspects (AOP) also is a great way to expand the Java language in a clean pluggable way rather than using annotations solely for code generation. JBoss AOP is not only a framework, but also a prepackaged set of aspects that are applied via annotations, pointcut expressions, or dynamically at runtime.”
So annotations sure are being used.
What has been your experience with Java annotations? Did you find annotations useful or is it just another passing fad?
Reference:
>> Annotations: Don’t Mess with Java
Related:
>> What’s new in J2SE 5.0? Part 3: MetaData / Annotations and Enums
My opinion:
Annotations are horrible to work with.
It obfuscates the code, relying on a precompiler to insert code (that you can’t see) that often makes calls to a black box that you can’t see either. It makes training and debugging a nightmare because there is no link between cause and effect (ie readable code).
I have seen minor productivity gains by using @EJB and @Test, but I have also seen horribly mangled code where it is literally impossible to figure out what is going on without learning the annotations language – and yes I say “language” because the keywords, usage and consequences of using an annotation give me exactly the same ball ache as learning a new language. And I know a few.
The only justification I have heard for annotations is “it reduced LOC”.
Well, woop de doo. One developer gets to go snowboarding an hour earlier while every guy for the next 10 years to has to maintain the code is left to puzzle about what the hell it was supposed to do in the first place. If you need fewer LOC use Python. If you need legibility (and everyone should) either use the boilerplate, or use generated (and overridable) code.
Boilerplate code is a necessary evil with non-dynamic languages like Java.
Annotations (and their poor relations taglibs) are an attempt to make Java look like Python by hiding”dynamic-looking” behaviour behind complicated libs.
The end result is frankly a shambles.
That’s not a solution, it’s a workaround for a broken OOP feature.
Java Designed 1: \Hey, we have a problem. Since our objects don’t really execute their destructors when they exit scope, it leaves handles and resources tied up. Why don’t we make the code of the destructor execute immediately, and let the garbage collector clean up the memory at its leisure?\
Java Designer 2: \No way, I have a better idea, let’s just add a \finally\ block to our exception handling, then, in all the hundreds of places an object is used, the programmer can enjoy the tedious exercise of reading the code of the object to figure out what needs to be done to clean it up, and then write code to do that in all those hundreds of places!\
Java Designer 1: \Holy Crap! You’re a genius!\
Ideally, a class knows what must be done to destruct itself. You can clean up whatever you want from the outside but you’re breaking encapsulation or adding a kludge \destroy()\ function instead of just making the object properly destruct. I’m aghast that Java programmers accept the fact that destruction really isn’t destruction, it’s just a death sentence to be executed later. Whoever designed the Java destruction model seemed to think that \releasing memory\ was the only thing done at destruction time. If that’s all you think it is, it severely limits the possible uses of a class. Uses where deterministic destruction is important, irrespective of memory freeing:
1) Timing a block of code where a timing object is created, and then its destructor gives the elapsed time.
2) Making sure resources like file handles, socket connections and database connections are closed immediately when a scope is exited.
3) Unlocking mutexes or transactions when the locking object goes out of scope.
4) Freeing up an object, when a \handle\ type object holding that object is destroyed.
In my opinion, the single greatest feature of Object Oriented Programming is the magic of destructors. Having hobbled destructors is no way for a language to go through life.
That’s not a solution, it’s a workaround for a broken OOP feature.
Java Designed 1: Hey, we have a problem. Since our objects don’t really execute their destructors when they exit scope, it leaves handles and resources tied up. Why don’t we make the code of the destructor execute immediately, and let the garbage collector clean up the memory at its leisure?
Java Designer 2: No way, I have a better idea, let’s just add a finally block to our exception handling, then, in all the hundreds of places an object is used, the programmer can enjoy the tedious exercise of reading the code of the object to figure out what needs to be done to clean it up, and then write code to do that in all those hundreds of places!
Java Designer 1: Holy Crap! You’re a genius!
Ideally, a class knows what must be done to destruct itself. You can clean up whatever you want from the outside but you’re breaking encapsulation or adding a kludge destroy() function instead of just making the object properly destruct. I’m aghast that Java programmers accept the fact that destruction really isn’t destruction, it’s just a death sentence to be executed later. Whoever designed the Java destruction model seemed to think that releasing memory was the only thing done at destruction time. If that’s all you think it is, it severely limits the possible uses of a class. Uses where deterministic destruction is important, irrespective of memory freeing:
1) Timing a block of code where a timing object is created, and then its destructor gives the elapsed time.
2) Making sure resources like file handles, socket connections and database connections are closed immediately when a scope is exited.
3) Unlocking mutexes or transactions when the locking object goes out of scope.
4) Freeing up an object, when a handle type object holding that object is destroyed.
In my opinion, the single greatest feature of Object Oriented Programming is the magic of destructors. Having hobbled destructors is no way for a language to go through life.
People seem to have completely forgotten some important basics like “interfaces”. For example we have a hibernate application where callbacks are flagged with annotations. When your bean is processed by our engine it looks for a function tagged with an annotation:
@callback public void myFunctionNamedAnything() {} etc.
This is lame in many ways. First of all, it doesn’t enforce an interface. The function should be based on an interface to that developers don’t make mistakes so it should always have the same name and the code shouldn’t compile if you leave out the function by accident. As it is now, we have all sorts of errors that occur at runtime and are hard to debug.
Second, this doesn’t enforce a particular function signature so even if you code it right, someone else could change the calling code, compile, and never know he just scrambled the product.
I don’t have a beef with annotations. Just because something could be misused doesn’t mean it shouldn’t be in a language. Exceptions and namespaces are terribly misused in C++ for example. The java exception model is broken anyway since the non-deterministic nature of destructors means throwing an exception doesn’t necessarily destroy an instance such as a database connection, a file connection, a window or whatever.
The java exception model is broken anyway since the non-deterministic nature of destructors means throwing an exception doesn’t necessarily destroy an instance such as a database connection, a file connection, a window or whatever.
you are ignorant about the JLS … if you want determinism you call a cleanup method in the finally block ….
please learn about the language befoer speaking
That’s not a solution, it’s a workaround for a broken OOP feature. Ideally, a class knows what must be done to destruct itself. You can clean up whatever you want from the outside but you’re breaking encapsulation or adding a kludge “destroy()” function instead of just making the object properly destruct. I’m aghast that Java programmers accept the fact that destruction really isn’t destruction, it’s just a death sentence to be executed later. Whoever designed the Java destruction model seemed to think that “releasing memory” was the only thing done at destruction time. If that’s all you think it is, it severely limits the possible uses of a class. Uses where deterministic destruction is important, irrespective of memory freeing:
1) Timing a block of code where a timing object is created, and then its destructor gives the elapsed time.
2) Making sure resources like file handles, socket connections and database connections are closed immediately when a scope is exited.
3) Unlocking mutexes or transactions when the locking object goes out of scope.
4) Freeing up an object, when a “handle” type object holding that object is destroyed.
In my opinion, the single greatest feature of Object Oriented Programming is the magic of destructors. Having hobbled destructors is no way for a language to go through life.
People seem to have completely forgotten some important basics like “interfaces”. For example we have a hibernate application where callbacks are flagged with annotations. When your bean is processed by our engine it looks for a function tagged with an annotation:
@callback public void myFunctionNamedAnything() {} etc.
This is lame in many ways. First of all, it doesn’t enforce an interface. The function should be based on an interface to that developers don’t make mistakes so it should always have the same name and the code shouldn’t compile if you leave out the function by accident. As it is now, we have all sorts of errors that occur at runtime and are hard to debug.
Second, this doesn’t enforce a particular function signature so even if you code it right, someone else could change the calling code, compile, and never know he just scrambled the product.
I don’t have a beef with annotations. Just because something could be misused doesn’t mean it shouldn’t be in a language. Exceptions and namespaces are terribly misused in C++ for example. The java exception model is broken anyway since the non-deterministic nature of destructors means throwing an exception doesn’t necessarily destroy an instance such as a database connection, a file connection, a window or whatever.
The java exception model is broken anyway since the non-deterministic nature of destructors means throwing an exception doesn’t necessarily destroy an instance such as a database connection, a file connection, a window or whatever.
you are ignorant about the JLS … if you want determinism you call a cleanup method in the finally block ….
please learn about the language befoer speaking
That’s not a solution, it’s a workaround for a broken OOP feature. Ideally, a class knows what must be done to destruct itself. You can clean up whatever you want from the outside but you’re breaking encapsulation or adding a kludge “destroy()” function instead of just making the object properly destruct. I’m aghast that Java programmers accept the fact that destruction really isn’t destruction, it’s just a death sentence to be executed later. Whoever designed the Java destruction model seemed to think that “releasing memory” was the only thing done at destruction time. If that’s all you think it is, it severely limits the possible uses of a class. Uses where deterministic destruction is important, irrespective of memory freeing:
1) Timing a block of code where a timing object is created, and then its destructor gives the elapsed time.
2) Making sure resources like file handles, socket connections and database connections are closed immediately when a scope is exited.
3) Unlocking mutexes or transactions when the locking object goes out of scope.
4) Freeing up an object, when a “handle” type object holding that object is destroyed.
In my opinion, the single greatest feature of Object Oriented Programming is the magic of destructors. Having hobbled destructors is no way for a language to go through life.
how icn reve a installed program in my phone
how icn reve a installed program in my phone
I agree that annotations are not good for ‘config data’, anything that your going to want to change frequently (or even infrequently for that matter), doesn’t belong in annotations. But annotations that describe functionality do. I like Hibernate Annotations for better than I like the XML descriptors because the same place I write my logic is where I describe how to use it. In Tapestry defining inject services with annotations is quicker than have to deal with defining it in the page file AND in Java.
I agree that annotations are not good for ‘config data’, anything that your going to want to change frequently (or even infrequently for that matter), doesn’t belong in annotations. But annotations that describe functionality do. I like Hibernate Annotations for better than I like the XML descriptors because the same place I write my logic is where I describe how to use it. In Tapestry defining inject services with annotations is quicker than have to deal with defining it in the page file AND in Java.
I have been working on java 1.4 with a ad-hoc annotation system to
help me map my classes to RDF. Annotations are going to come in very handy in this area: see my initial proposal at:
http://blogs.sun.com/roller/page/bblfish/20050825
I have been working on java 1.4 with a ad-hoc annotation system to
help me map my classes to RDF. Annotations are going to come in very handy in this area: see my initial proposal at:
http://blogs.sun.com/roller/page/bblfish/20050825
I think annotations are going to be really useful in working with
the Semantic Web. I have written out a first idea of how this is going to work here:
http://blogs.sun.com/roller/page/bblfish/20050825
I think annotations are going to be really useful in working with
the Semantic Web. I have written out a first idea of how this is going to work here:
http://blogs.sun.com/roller/page/bblfish/20050825
The article mentions that it will be picked up by ‘framework junkies.’
What’s so wrong with a framework using annotations? Compare TestNG and JUnit, for example. Is forcing a naming convention better than an annotation? How do classify when a test is run a la TestNG without annotations, or its associated JavaDoc hack?
I don’t see what’s wrong with giving frameworks another tool, one more elegant than the associated XML files in many cases.
There’s nothing wrong with annotations where they don’t make things worse. My example, what I thought was bad, was exporting an interface by annotations, i.e. “Your bean must have a function annotated with @callback and the service will call that function” is nuts. The developer can annotate his function with @callback, but if he doesn’t use the proper function name and argument list, it’s going to blow up at runtime where it takes 100 times longer to track down and fix instead of just failing to compile which would happen if the API required matching function signatures.
The article mentions that it will be picked up by ‘framework junkies.’
What’s so wrong with a framework using annotations? Compare TestNG and JUnit, for example. Is forcing a naming convention better than an annotation? How do classify when a test is run a la TestNG without annotations, or its associated JavaDoc hack?
I don’t see what’s wrong with giving frameworks another tool, one more elegant than the associated XML files in many cases.
There’s nothing wrong with annotations where they don’t make things worse. My example, what I thought was bad, was exporting an interface by annotations, i.e. “Your bean must have a function annotated with @callback and the service will call that function” is nuts. The developer can annotate his function with @callback, but if he doesn’t use the proper function name and argument list, it’s going to blow up at runtime where it takes 100 times longer to track down and fix instead of just failing to compile which would happen if the API required matching function signatures.
solution is giving an apparatus that could force correct usage of annotations. the condition for usage would be written formally, and in compile time the tool would check whether all constraints are met and if not, throw a warnign, or better an error..
…I don’t like them, I like to separate my code from ‘config’ informations.
That’s why I like spring so much, every thing is in POJOs and the spring file add infrastructure stuff around.
If for maintenance, testing…etc reasons I have to change my ‘settings’ I only modify my XML context files and not my code.
But I know future and smarter people often prove me wrong.
paskos
…I don’t like them, I like to separate my code from ‘config’ informations.
That’s why I like spring so much, every thing is in POJOs and the spring file add infrastructure stuff around.
If for maintenance, testing…etc reasons I have to change my ‘settings’ I only modify my XML context files and not my code.
But I know future and smarter people often prove me wrong.
paskos
I must admit @remote makes me crazy…
@public
@static
@void
@main
I must admit @remote makes me crazy…
@public
@static
@void
@main
Annotations can be useful as shown by XDoclet. But they need to be used judiciously for them to be useful.
Annotations can eventually litter our code.
Annotations can be useful as shown by XDoclet. But they need to be used judiciously for them to be useful.
Annotations can eventually litter our code.
There was a time when we were all told by the experts that Depolyment descriptors were the best thing about EJB. Now everybody tells us that deployment descriptors are the worst part of EJBs and EJB 3 will fix that with annotations.
A few years down the line we will see something new that might not be better than annotations but will be termed as a solution to annotations and the problems that annotations create.
Keep changing things – who cares if it’s better or not. Only then does everybody keep their jobs, think they are working on the coolest technology and even get paid. Why complain? 🙂
There was a time when we were all told by the experts that Depolyment descriptors were the best thing about EJB. Now everybody tells us that deployment descriptors are the worst part of EJBs and EJB 3 will fix that with annotations.
A few years down the line we will see something new that might not be better than annotations but will be termed as a solution to annotations and the problems that annotations create.
Keep changing things – who cares if it’s better or not. Only then does everybody keep their jobs, think they are working on the coolest technology and even get paid. Why complain? 🙂