Don’t bother me, I’m diving.

Having methods in a Java object that you will never invoke is a pretty
obvious Design Smell.  It’s already hard to keep the complexity of your
objects in check when you limit yourself to strict business logic, so why would
you add these useless methods on top of it?

Well, it’s actually quite common in Java programming.  So common that
you probably add such methods every day to your classes without even realizing
it.

Some examples:  HttlServlet.doPost(), JMSListener.onMessage(),
EntityBean.passivate(), etc…

Dependency injection is also a big offender in this area:  setter
injection forces you to implement setters you will never invoke, and constructor
injection makes you modify the signature of your constructors (which is even
more intrusive in my opinion).

Alright, at this point you are probably rolling your eyes and dozens of
objections are coming to your mind.  Fair enough, I agree that most of
these methods actually provide important connection points between the container
and your object.  When these methods are invoked, you are given a chance to
execute some logic that can be very important to your application.

As a matter of fact, all the methods I have just mentioned enable this. 
All of them except…  setter injection.

Setter injection is a way for the container to hand you some objects so you
can store them and reuse them later.  The problem is, it’s not the setter
you are interested in, but the getter.  The typical implementations of an
injected setter is to store the value in a field for later use.  You don’t
get more boiler-plate than this.

There are three ways to look at this problem:

1. It’s only a one-line method, it’s not a big deal.
2. Since the setter is useless, have the container perform field injection
   (possibly tagged by an @ContainerProvided annotation).
3. Let the container implement the getter.

I wish there were one simple answer, but unfortunately, these three
approaches all have pros and cons.  The one-line method can be seen as
needlessly polluting your POJO class.  Field injection is a little less
invasive but I’m not sure I like the idea that the container is messing with
private parts of my object.  Finally, solution 3 sounds like the ideal
solution (no pollution, no messing with private fields) but it requires either
abstract methods or objects whose bytecode has been tweaked by the container,
both of which make testability harder.

James Strachan likes the idea of using AOP to introduce annotations in your
code:

This will let us use our own conventions (naming conventions such as Java
Beans default conventions) and let AOP weave in all the annotations

Well, it’s not very often, but I strongly disagree with this.

Using pointcuts to specify where the annotations are going to be inserted
is a huge step backward that brings us back to XML hell.

The reason why we are moving away from XML as a metadata description language
is that it introduces redundancy:  in order to define where the metadata
is going to be introduced, you need to specify the Java element it applies to: 
class name or method name, parameter types, exceptions thrown, etc…  This
redundancy makes your code extremely fragile and even the most advanced IDE’s of
today don’t cover  the case of refactoring this kind of metadata.  If
you rename your method and forget to adjust your pointcut, you application will
break.  If you define your pointcut poorly, it might start introducing
annotations in unexpected parts of your application with similar disastrous
results.

JSR 175 annotations have two very strong points.  They are:

• Close to your source code. 
• Part of your Java type system.

These two points are already important separately, but taken together, they
take Java programming to a whole new level of expressiveness.

Besides, what is exactly the problem, James?  Are you afraid that the
Java syntax is becoming encumbered?  If so, then you need not worry: 
code folding and other IDE assistance will make it very easy for you to
completely ignore the annotations if you so desire.

In a similar vein, Rickard posted the following comment:

Yeah, the way we solved this (the annotation
nightmare) is to allow AOP pointcuts to introduce annotations. And then use
those annotations in pointcuts for aspects. E.g. instead of setting an
annotation "setter" on all set* methods and apply a "StoreToDb" aspect on those
methods, I can create a pointcut that says "apply attribute ‘setter’ on all set*
methods" and then have the "StoreToDb" trigger on the "setter" attribute. Just
as you mention, with this approach I only have to mark the special cases with
annotations; everything else is automatic. It works great, and is a big help.

I have to confess my skepticism about this approach as well.  It seems
to me that this method only adds a level of indirection for no obvious benefit. 
In effect, you are still defining a pointcut on "set*", calling it "StoreToDb"
and invoking an aspect on it.  Why the extra step?

All that being said, James original point is valid:  are we going to see
an abuse of annotations in the next couple of years?  Most likely. 
But I think it’s a little too early to worry about that right now.  As the
use of annotations percolates through our Java habits, good and bad practices
will emerge and we can rely on book authors and fellow bloggers to spot those as
they come.  And on Hani to keep these people in check.

A very cool new site:  javadocs.org.  It contains all the Sun
JavaDocs and also allows you to search directly from the URL.

I created the following bookmark with FireFox:

Location: http://javadocs.org/%s
Keyword: jd

This way, I can type "jd url" in the FireFox address bar and I get
the documentation for java.net.URL right away. 

Even though I use an IDE, I still find myself browsing the HTML Javadocs with
a browser fairly often, and even sometimes resorting to "javap|grep" to quickly
find a method in a class.  The good thing about the javadocs Web site is
not that it provides javadocs online, obviously (I already have those in my
toolbar) but the simple text search that it enables.

I only have two complaints:

• It doesn’t contain the 1.5 Javadocs
• If your search yields several hits, only the first one is displayed (I’d
  like to get a list of all the hits so I can drill down further).

Cool idea nevertheless.

I updated the TestNG distribution to contain the missing source files, let me know if I forgot any other.

I have just uploaded a new version of
TestNG, the annotation-based test framework.  A lot has gone into this
new release:

• Revamped documentation
• Transparent support for JUnit tests.
• HTML reports covering the entire test run.
• Groups can now be specified as regexps.
• Support for tests and suites.

Extensible API allowing you to generate your own reports or even your own
testing methods (two are supported right now:  annotations and JUnit).

The HTML reports are still fairly basic but they convey the results of the
entire test run pretty well.  You can see an example
here or just go
directly to the main documentation page.

I am getting tired of hearing "lightweight" tagged to the description of
every piece of software that comes out.  "Lightweight" has to be the most
underrated buzzword of the year.  Well, not any more.  I hereby
nominate "Lightweight" (and its evil sibling, "lightweight container") as a
buzzword.  Consequently, it should be reserved to PR releases and be banned
from the vocabulary of anybody who claims to possess a minimum amount of
technical knowledge.

Lightweight containers are all over the place these days, and you won’t get
the attention of the community if your framework weighs more than a certain
number of pounds.

What cracks me up is that most of these frameworks have been in the making
for quite a while and they stopped being lightweight a long time ago, but since
the concept is totally undefined (hence its qualification as a buzzword), nobody
will ever contradict you if you say your framework is lightweight.

I don’t know about you, but I can’t wait to be using an IDE that asks me if I
want to create a "Lightweight / Mediumweight / Fatass project".  Then it
would monitor the number of classes/methods/keys that I type and if I pass a
certain limit, it would show up a dialog box saying "Sorry, you selected a
Lightweight project and the variable you just declared is turning your project
into a Mediumweight one.  Please delete all your files, close this project
and create the right kind, this time.  Moron."

Gavin just posted an interesting article summarizing his views on EJB3 and JDO.

Linda de Michiel, EJB 3 spec lead, just finished her presentation of
the EJB 3 work at TheServerSide symposium.  The Experts Group has
been very busy these past nine months and considering the enthusiastic
response of the audience, it’s been time well spent.  Here are the
salient points of the new specification.

The focus of EJB 3 is ease of development.  Session and
Message-Driven Beans will also benefit from this simplification, but I
think the most interesting developments are for Entity CMP beans. 
EJB3 has learned a lot from the previous version and is taking ideas
introduced in Hibernate and other persistence framework to come up with
a brand new programming model featuring:

• POJO-based (no more abstract methods, support of new)
• Simplification of the design (now optional:  homes,
  component interfaces, lifecycle methods, no more EJBLocalObject, etc…)
• Use of injection to make it easier to test outside the container
• Use JSR 175 annotations instead of deployment descriptors
• Support for disconnected access
• Many EJB QL enhancements (bulk updates, etc…) as well as
  support for native SQL
• A standard O-R mapping

I am positively thrilled by the direction EJB3 is headed.  The
Experts Group has been extraordinarily active these past nine months
and the activity on the phone calls and on the mailing-list is a
testament to the commitment of the 20+ members to this task.  Of
course, there are still quite a few undecided issues, but the major
items are pretty much agreed upon at this time.

I think EJB3 has the potential to solve the problem of persisting Java
objects to relational databases once and for all.  It took a while
and a lot of errors, but we are finally getting there.

The EJB 3.0 BOF session tomorrow night will be a great opportunity for
us to hear more feedback from the community.