The early examples I've seen of EJB 3 looked cool compared to previous
versions (though a little heavier than lightweight container services).
Though the feeling immediately hit me of unnecessary annotations. (Note
I made up a couple more annotations on this example)...
@Session
class PizzaMaker {
private Cheese cheese;
@Inject
public void setCheese(Cheese cheese) {
this.cheese = cheese;
}
@Transactional @WebService @RetryTimes(3)
public Pizzer makePizza() { ... }
}
Incidentally my first reaction was - why not just use a constructor;
why the need for an @Inject annotation? Or why not assume that
all public setters are injectors unless explicitly stated that they are
not injectors.
When JavaBeans component model came along it was a bit of a revelation.
Before then component models were heavy complex things like COM, CORBA,
OpenDoc. The neatest thing JavaBeans it did was create a component
model with properties, actions and events which didn't require
countless extra metadata to be codeded. There were naming conventions
you could use for the introspector to figure things out using sensible
rules - and a way to customise things if the introspector didn't do
what you needed.
i.e. most of what people needed happened automagically for you by
following a few simple rules without having to do extra work at all.
I can't help think that sometimes we need to follow the same kind of
logic with annotations to avoid littering our code with
annotations which become a maintenance nightmare.
e.g. if you're making a bunch of session beans; you might put them in a
single package. Ditto for webservices. Ditto for entity beans / JDO
thingies / persistent POJOs - same with MBeans etc. Then your IDE/build
could figure out what to do itself. Or we could use naming conventions
(MBean, SBean, Entity postfixes on class names).
I can imagine AOP being used to fill in most of the annotation details
for us. e.g. create an aspect to apply the session bean annotations -
where for a project all your session beans are container managed
transactions & all public methods are remotable & available as
web services etc, then create a pointcut to find your session beans in
your code base & which methods to make transactional (all by
default use all non-property methods, say, unless I say not to via a
special annoation).
Then rather than having to type lots of annotations per source file; we
can define aspects and conventions, on a per project bases, of the
kinds of things we're working with - then only revert to annotations
when we absolutely have to - to overload the default rules of a
project. i.e. annotations should be the exceptions, not the rule; we
should try capture the rules outside of the code via pointcuts/aspects.
Who knows - one day our IDEs may be clever enough to hide most of this
from us and letting the IDE basically do this for us - letting us setup
conventions of class, package & method naming & organisations
& letting the IDE maintain all the annotations for us, as we
refactor & add properties/methods etc.
Though until the IDEs catch up - AOP could well save us from annotation hell.
10:18:18 AM 
|
|
