Hi,
a user called ai109478 sent a response for my blog post feedback here:
http://weblogs.java.net/blog/kgh/archive/2006/02/raving_about_ja.html
And asked me to send further details to this list, I assume the user
name is a form of Sun ID (my company does quite a bit of contracting
work for Sun and I am sa112012 or shai.almog_at_sun.com). So anyway
hopefully this E-Mail is not being wasted.
First, I blogged about this and about the problems I had with Spring
quite a while back (I think I even sent feedback to the alias but I
don't recall). You can see my old posts on my old blog here from May
23rd 2005:
http://jroller.com/comments/vprise?anchor=why_j2ee_5_is_still
And this one from June 7th about Spring (which I eventually dumped):
http://jroller.com/comments/vprise?anchor=eclipse_fud_about_the_apple
I want to get one thing strait:
I think the annotations work is great and its a huge step in the right
direction!
However, I don't think simplicity is greater with annotations it can be
argued that just groking (visually as a programmer) the source code
littered with annotations is harder than going over several "plain"
source files and an XML file.
There are two separate problems we can discuss that relate to making the
Java EE experience simple:
1. Perceived simplicity.
2. Actual simplicity.
The first is the approach taken by Spring and the Java EE 5, by using
some buzzwords (IoC, AOP, Annotations etc...) as a sort of pixie dust
coupled with the "POJO" lie we supposedly "simplified". We can even
present a checklist to the customers where we outline the exact features
that were added to produce simplicity i.e. "You just write a standard
Java object add one annotation and voila"...
Why is this a lie?
Repeat after me: "There is no such a thing as a POJO within a container!"
This is true for Hibernate (which is a great product on its own, but
doesn't do any magic) and this is true for all other technologies
supposedly based on POJO's. The closest thing we have for POJO's in Java
is serialization and even that isn't fool proof. The problem is that a
container has a contract with the component within it, there are rules
and there is a sequence of initialization (of fields and dependency
injection) so a POJO for container A (such as Spring) will not move to
container B (such as JBoss with EJB 3 implementation) worse I'd even bet
there are quite a few "cracks" where a POJO for one EJB container won't
move easily to another EJB container!
The problem is that every container MUST offer POJO's today otherwise
customers will complain about the "Perceived simplicity" regardless of
the fact that they will NEVER EVER move to a different application
server, they would also be right since this is something that was
offered by all other servers for quite some time.
Whats the solution?
Stop pretending! POJO's are fine but ignoring the fact that there is a
contract and order related to POJO handling will just produce code that
won't be portable. Define everything and force everyone to work in
"portability mode" by default, define errors (and error messages) and
define checks for every single API. There shouldn't be race conditions
to dependency injected attributes there should be a well defined uniform
sequence of field initialization.
The validator that exists is worthless, it breaks on the simplest
applications. A validator must force itself on the user (such as the XML
validator or the strictness of Java itself) otherwise people will not
follow its guidelines (how many C programmers ever run lint and its like).
On a positive note I think many features in Java EE 5 can simplify
things in the long term such as the ability to "detach" entities and
serialize them, this will reduce real world redundancy in code. There
are many such gems in the spec, but it seems like the spec focused on
cramming many features asked by the users and sadly users just don't
know whats good for them ;-)
You need to push in the celery with the carrot (or carrot cake,
analogies aren't my strong suite) give the users the features they are
asking for while slipping in the features that they need such as strict
validation and clearly defined limitations.
So the steps I am proposing:
1. Define deployment - for once and for all just say exactly what the
hell happens there!
So you will break an application server, who cares. The 90% portability
that was "great" for the EJB 1.0 era is no longer acceptable today when
people are moving to Spring.
2. Define failure - The problem is that application servers choose to go
on running even if you do some clearly incorrect operations. The thing
is that they will fail later with a message that you just can't
understand. Define within the spec the points of failure (by clearly
defining developer interaction with the container) allow for developer
move/runtime mode in case of a potential performance cost but make sure
this is minimal (bugs that only happen in production are just the worst
kind).
3. Standardize the abstract - From class loading behavior, field
initialization sequences, invoking API's when servers aren't fully
loaded and connecting the various pieces that are Java EE. The Java EE
spec is RIDICULOUSLY thin! Its as if the committee took a look at the
other specs (EJB, Servlets etc...) and declared "they already did all
the work". The problem is that those guys did NOTHING, they defined a
small API and didn't define anything about integration.
4. Have default implementations - Simple things such as preexisting
login modules for JAAS that can be defined within the standard Java EE
deployment descriptor go a long way.
5. Build REAL applications as a part of the spec - not blueprints or
other "theories". By having a set references application server vendors
can tune their products, customers can "borrow" source code and you will
see that there is no standard way to "logoff" users that I could find in
Java EE. A TCK is usually too "low level" to truly define portability, a
real set of applications that can run unmodified on all application
servers and provide a decent starting point for your own application
will simplify everyones lives (this is a part of the spec since the TCK
is a part of the spec and the TCK isn't enough).
I could go on further but I think thats enough for now ;)
I'm not on the list so make sure to reply to this address.
Thanks for reading so far.
Shai Almog
vPrise Consulting.