Just a quick news. For those of you who have followed the entire debate between JCDI (Java Context & Dependency Injection, aka Web Beans) and @Inject, you will be pleased (or not) to know that there is a brand new JSR : JSR 330 Dependency Injection for Java. I hope we are not starting a new battle like the one between Java Module (JSR 277), Modularity Support (JSR 294) and OSGi. Future will tell.
This year I‘ve talked a lot about opening up the JCP. I first did a round table at QCon with Rod Johnson and Patrick Curran (chair of the JCP) back in February. Then at Java One (with the same folks) and in May Patrick Curran came to the Paris JUG … and now a BOF at Devoxx with Corina Ulescu about this sensible topic. The questions are always the same : should the JCP be more open, and how ? To the first question, I think that most of the people agree. Yes, the JCP should be a more transparent organization. But to which extent should we open it ? And if we find a solution, do we have to formalize it and impose it (that means changing the JCP process). Basically, a spec lead can decide of the tools he/she wants to use. If he/she wants a public mailing list, that‘s fine, if not, that‘s fine too. The JCP does not impose a spec lead a way of communicating. So, at the moment, there‘s a bit of everything : closed JSRs (no wiki, no public mailing list…), opened ones (open source reference implementation, open mailing list…), and anything in between. But which model to choose ? I have to say, I‘m between two waters here. I‘m expert member on JSR-316 (Java EE 6), JSR-317 (JPA 2.0) and JSR-318 (EJB 3.1), that‘s a lot of work. Every day I receive […]
