Closure Campaign 2008

After many discussion, it is election time (year) for closure.
I voted for the readable, easy to grasp, and "almost" complete implementation of closure: FCM.
The posts of Stephen on the differences are very instructive:

1. Closures - Comparing the core of BGGA, CICE and FCM


2. Closures - Comparing control structures of BGGA, ARM and JCA


3. Closures - Comparing closure type inference

I hope this vote will have an influence on the JCP...

Is JSF following EJB road?

First I have to be clear: I don't like JSF!

But, I did not like EJB 1.0 when it came out. And still, I did bet on it's success.

When EJB 1.0 came out I just finished my personal implementation of a CORBA Application Server, so this new Specification was "way below" my stuff. I was young, but still you cannot stop the machine coming from Sun, BEA and after quite some time IBM.
EJB came in a world were crazy techies (like me) thought they can build great servers which can handle enormous load. So, this specification really calm down crazy development and provided a good base for containers (usage and implementation).
But, it was flawed, right from the beginning.
All the API, interfaces and design concentrated on showing off the "great" power of the Application Server. Look how I can passivate/activate, look I can do security and transaction, and look I even save in DB for you. And for every "look" as a poor developer you needed to answer (implement, declare) something.
There was no escape, your code was full of unwanted pollution.
EJB 2.0 did not solve the problem and actually added more "look" at my beautiful AS: Messaging and CMP.

We had to wait for JBoss guys to take over EJB specification for 3.0, to finally end the developer nightmare.

And now, the funny trick. Please replace in the above EJB with JSF...
Amazing, it fits.

JSF came when Web UI was a total mess (All Struts usage override most configuration and basic classes) and everyone had his own "best/better" implementation.
So, JSF did some clean up in Web UI design and implementation.
But, JSF is really "showing off": Look my nice lifecycle in 42 steps, Look my nice big list of jsp tags/attributes, Look my nice EL, Look my nice XML configuration, and so on.
By "showing off" I mean that you need to fill all this with a lot of unreadable and incomprehensible repetition. And the worst of it you need to master all this in order to:
- debug correctly,
- integrate external stuff (Ajax4JSF and so on),
- create just one JSF UI component (Does someone sells T-shirt with: I wrote my JSF component! without breaking the lifecycle?),
- write stupid HTML pages.

A really good description of all JSF flaws are listed in Gavin blog: EE6 Wichlist
In this blog entries, the first one on EJB the second on JSF, looking quickly at the code examples you understand the gap. EJB is full of nice Annotations and Meta Annotations (the future for sure), and JSF full of ugly XML and Expression Language (scheduled to die).

The biggest conceptual flaw of JSF is the usage of EL.
EL is breaking encapsulation, in term of IoC: it's on the wrong side of the road. Ophir pointed me to a nice essay from Terence Parr "Enforcing Strict Model-View Separation in Template Engines ", that really nicely proves my point.
A UI definition (Web page, Swing panel, ...) should not know about the object graph. If I am a UI designer, I'm not a business modeler.
The answer is in architecture like Wicket and JSR-295 (The EL in this Beans Binding is due to the lack of property support).
In these good architecture: The UI components have an ID related to the page/panel, and the Java developers bind data to these components and receive events from these components. This is the good way to do UI, integrate UI design and manage UI logic. From experience, it works great.

All the other flaws are due to the age of JSF and the fact that it was written for ugly request/response Web UI behavior.

So JSF is today at the stage of EJB 1.0, I can see JSF 2.0 pushing more in the wrong direction, and so having finally a JSF 3.0 were developers will stop having nervous shake when they hear: JSF!

Web Beans and Modules!

After some good work, the JSR-299 group released an early draft, first published on Gavin King's blog, and now on the JCP site.

The spirit of Web Beans is really good, and the way the annotations came out is very promising. I have nothing to say but compliment the Component Types, Component Bindings, Scopes, Injection, and Interceptors. The Event has the good approach (Event type filter), but looks young at the moment.

Web Beans is really the state of the art "Educational Framework". The technical base is already explored (Guice, Spring, Seam) and is not so complex, but the impact on the developer thinking is really significant. Like every good "Educational Framework" (Struts, Spring, Seam), it makes it harder to do the "bad thing" (hacking, ugly coupling) than the right one (framework driven injection and loose coupling).
I know that if developers start to use these Annotations their code will get cleaner, more readable and manageable.

But, reading through the specs and especially, "4.4.2 Interceptors bindings" and "8. Packaging and configuration", I felt like something was wrong: Where are my Web Beans modules?
I don't want to get into the argument of OSGi or JSR-277, but I was expecting a more modular approach of Web Beans Injection.
What I mean, is that I would like to see a Web Beans "core" defining all the above Annotations for a pure J2SE environment. This would be the specification of how to use Dependency Injection Annotations. On top of that, another specification on how to provide "Components Provider/Injectors" for JEE, JSF, EJB, MDB and so on.
For example, I want to be able to do:

@Log
private Logger log;

just by adding log4j-web-beans.jar in my classpath. In this jar Log4J will provide the Web Beans Component for my class and my environment.
So, with this approach all the EJB, JSF & JEE stuff that really don't have to be there, can be specified separately as: jee5-web-beans.jar, ejb-web-beans.jar, mdb-web-beans.jar, etc.
I think it will make the specifications easier to read and a lot more flexible for all the great future components ;-)

Since I don't like people that complain without proposing something of their own, I tried to see how to do this with the current specification. And, basically it's not missing much.
Today in EJB3 environment, the first thing I do is creating an Interceptor that can inject components from Spring or other sources in my Session Beans. The injection is based on my project level Annotations and it bridges Spring and EJB3 nicely.
So a first solution (not good but...) is to use javax.interceptor.InvocationContext. If the Web Beans container is adding some entry in getContextData(), I can find out the Component Type, the Scope, and other information and decide how to populate all the @Log fields.

A nicer solution will be to have Annotations specified by JSR-299, that will allow me to write something like:

@ComponentProvider
public class Jee5ComponentProvider {

    @Provides(EJB.class)
    public Object getEJB(WebBeansContext wbc) {
        try {
            return new InitialContext().lookup(
                wbc.getDestinationField().getType().getName());
        } catch (NamingException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

Here I really did not investigate enough, but I know I'm missing @ComponentProvider and WebBeansContext in the current specification.
What do you think?

JSR-299 or Web Beans

After postponing for too long, I finally decided to look at Web Beans or JSR-299.

The story is that for our seminar JavaEdge 2007 we invited Gavin King. He accepted to come and to talk about his new JSR, and this was the first time I encountered "Web Beans".
And to tell the truth: The name gave me a cold shower ;-)
What? Gavin started as a backend guru for O/R Mapping, then decided to target the issue of Web development with Seam, and now is "may be" going even higher in the stack with some UI components spec!
It really sounded like Gavin was leading the new spec for some JSF UI widgets :-(

This name really put me off, and so I postponed reading about "Web Beans".
That was a mistake, and a really bad move.

When I saw in Gavin blog, that he was excited about exposing the work done in JSR-299 group, I decided to get into it.

And the conclusion is:

1. From my personal technical glossary, "Web Beans" has nothing to do with Web, and Beans are not UI JavaBeans.
2. Gavin did it again.

Before Hibernate the O/R Mapping tools concentrated more on showing off their feature list than helping developer having a persistent model. For Gavin what's important is how the user (poor developer) will communicate with the framework. Powerful features should not show off and complicate the API or the tool. Once the usage is clear, the framework follows.
So after Seam and easy @Conversation, he's leading this great JSR.

"Web Beans" is basically a good (meaning pushing forward) standardization of IoC and DI concepts using Annotations. The overview from Gavin slides of the Silicon Valley JUG, is a really good start to understand what JSR-299 is about.

"Web Beans" really uses the good Guice framework, removes the issue of static scopes in Seam, and helps you create your own meaningful project Annotations. And all this is done true to the Java spirit: in a readable way.
JSR-299 answers some of my needs I had in AADA and I hope it will help projects moving towards creation of more custom Annotations.

So, please, change the name...

• First, for once the JSR number is very easy to remember ( 300 - 1 easy to find an association).
• Second I always associated Beans with JavaBeans Swing UI or Struts, and I never felt it was connected with the concept of Components used in Spring, Guice, Seam or JSR-299. By the way, in "Web Beans" there is no @Bean but only @Component.
• Third, I found the term API (Application Programming Interface) does not match today's specification code and technique. EJB3, JAXWS and so on don't export a DLL API. They help you code. For example, In JPA (Java Persistence API) more than 90% of the code are Annotations not Interfaces. It should be Java Persistence Annotations, no? You can argue that Annotations are indeed interfaces in Java, and that it will not change the acronym ;-)

Anyway here are 2 possible names:
- Dependency Injection API (or Annotations)
- Components Injection API (or Java Components Injection Annotations ;-)

Finally, JSR-299 DIA also generalizes the concept of Injector injected by injection from the Dependency Injection framework, and I'm really happy about it ;-)