Kirill Grouchnikov's Blog

POJO - Complex New Perl Classes

• The P stands for plain. A java class with annotations is quite far from being plain. The annotations can be quite complex (take a look at the JAXB 2.0 generated classes).
• The O stands for old. Apart from the obvious (that the annotations are only part of JDK 5.0), i don't see many examples of new JSRs that propose to work with classes that aren't annotated at all.
• The J stands for java. More on this later in the entry, but annotations make a class to be non-standard Java (in my view).
• The O stands for object. The annotations are on classes, and not on a single instance, but this may be more suitable for BileBlog incoherent blabbering.

• The configuration XML file is now spread all over our class model. Furthermore, once you compiled your classes, you can't configure annotations (correct me if i'm wrong).
• The bean getters and setters are gone, but instead the corresponding fields are marked with a predefined annotation. You say potato, and i say @potato.
• The marker interfaces are gone, but instead the corresponding classes are marked with a predefined annotation. You say tomato, and i say @tomato.
• Everybody is welcome to create his own annotations. Everybody can finally feel like a king and create his own kingdom. Everybody can finally create his own flavour of Java. Everybody does. Sun realizes that and tries to come up with common annotations. The community happily ignores the JSR. It becomes impossible to read the code because each field and class has more than 10 annotations attached to them. Java becomes Perl.

Comments

• i'm glad you've brought up the issue of configuring annotations. if annotations are to replace xml configuration files, they're going to have to be writable.

  Posted by: eitan on April 04, 2005 at 06:36 AM

• On my weblog I posted some of the same concerns as you, albeit with a more restricted focus. It's nice to know someone else is concerned this annotation mania may not be allways benefical:

  weblogs.java.net/blog/flozano/archive/2005/03/ejb_30_two_step.html

  Configuraton data should be outside class sources, so they are easy to change without recompiling everything. And I wonder, after we all got used to the reflection API to deduce what an object is capable from its methods and interfaces, now do we have to change a lot of code to deal with annotations -- at least run-time ones?

  I have another comparision to make: Java code with lots of annotations may become as unreadable as "portable C code" with all #defs and #ifdefs. Sure this will generate a lot of flames, but I guess C/C++ were used far beyond their real scope and this generated lots of bad software that makes IT today expensive and insecure.
  

  Posted by: flozano on April 04, 2005 at 08:01 AM

• Both annotations and XML configuration files open up the possibility for wide misuse. I think that our objective should be to develop more readable and maintainable code, but it seems like both techniques are being used/abused to make over-engineered solutions look (at first glance) simpler then they are.

  Posted by: johnreynolds on April 04, 2005 at 08:30 AM

• Kirill (and Fernando), IMHO, I think you need to listen to one of the many talks the EJB 3.0 spec lead has been giving over the past several months. You can find them archived on theserverside.com or javalobby.org.

  She has been saying publicly and definitively for months now that configurations files will continue to be supported, and noted specifically that they could be used to override configurations set through annotation, at least where this would be appropriate. (N.B. - AFAIK, there have been no promises that said config files will not be substantially altered to accommodate the new model.)

  Now, I realise that this represents the way configuration will be handled for only one (albeit very important) API, not annotations in general. However, I think the EJB approach points to an obvious and simple ‘pattern’—if you will—for how these two approaches can co-exist:

  1. Provide standardised annotations for all configuration options to simplify coding for the developer.

  2. Provide ‘intelligent defaults’ for all configuration options so that developers only have to use annotations for the exceptional cases, further simplifying development and allowing the programmer to concentrate on business logic.

  3. Also allow for XML-based configuration files that allow setting configuration values at deployment time, overriding any defaulted/annotated values. Restrict said XML so that it can only set/override values that should be settable/override-able at deployment time.

  Thoughts?
  

  Posted by: rodmac on April 04, 2005 at 08:36 PM

• I am no J2EE expert, but IMHO your conclusions have it completely backwards. Speaking from a general J2SE perspective: The configuration is exactly where it belongs. Maybe in huge systems it is a bonus to work with separate configuration files, but in general I don't think it is. It's maintainance nightmare. Remember that no one prohibits you from using them still, if you want to. Who says that the getter/setter idiom is gone? It's a question of good software design. Java becomes Perl? Excuse me. Annotations give you the ability to define a special context, in which a class operates. I think that's a huge step in the right direction. With every technology you gain the possibility of misuse, that's true, but that doesn't mean the technology itself is bad. In the case of misuse it means that the programmer at hand sees nails everywhere because he holds a hammer. It's a case of a good tool used for the wrong purpose.

  Posted by: norb on April 04, 2005 at 11:00 PM

This work is licensed under a Creative Commons License.