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:
- From my personal technical glossary, "Web Beans" has nothing to do with Web, and Beans are not UI JavaBeans.
- Gavin did it again.
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 ;-)
- 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 ;-)