Next Presso (CDI, Java EE and friends)

Forward CDI 2.0

Posted by Antoine Sabot-Durand on Mar 15, 2014 | Comments

back to the future CDI is probably one of most overlooked specification in Java EE, yet when version 1.0 was released 4 years ago it was presented as “Java EE extension point”. Technically it’s the case, but for all kind of reason some JSR didn’t adopt CDI totally to provide a more consistent experience in Java EE. Today the IT world is moving fast and after long years of heavy memory and process solution we’re going back to resource optimization with mobile or embedded platform. As CDI can leave outside Java EE, it could play an interesting role in this new approach. But before that it should evolve to be ready for this new challenge (and continue to pursue its growing role in Java EE as well) In this post I’ll try to share my ideas on how CDI should evolve to meet it future rendez-vous. So I’ll start by exposing the new feature I’d like to see in CDI before exploring a more modular architecture for the spec to make it scalable from Raspberry Pi to Huge cluster solutions.

Disclaimer : Since I’ll be leading CDI 2.0 specification (with Pete Muir) it’s important to stress that this post is not an official announcement about the content of the CDI 2.0 specification. It’s only my thought and doesn’t engage CDI Expert Group or Red Hat.

New features I’d like to have

Some of these features are already in the Expert Group pipeline, some were deferred during CDI 1.1 for CDI 2.0, some are standardisation of third party development (mainly Apache Deltaspike) and some are totally new. Anyway, most of these point are important to help third party project or JSR to get the best of CDI.

Java SE Bootstrapping

I don’t need to insist on this point. Today each implementation provide a way to bootstrap CDI in Java SE or in a poor server (Servlet only) environnement. Apache Deltaspike has a generic solution to do it. So it’s time that the CDI spec integrates this to be officially available in Java SE.

Container hot swap

Strong typed injection is great, but CDI is too strict on this in my opinion. To support dynamic JVM language, we should be able to trigger a BeanManager restart with runtime added bean. this could be done for instance by providing API for bootstrapping a new CDI container with augmented content. If the boot went well have more step to duplicate status and existing instance in the new container and garbage the old one. In case of error we could keep the existing BeanManager. A costly but very useful feature for advanced tools or app that could provide specific enhancement system (CMS, e-commerce platform, etc…).

CDI lite

As said in my introduction, there’s a shared wish to bring CDI to embedded devices like Raspberry pi, Arduino, Lego Mindstorms or Android. Today the massive uses of proxies in implementations prevent us to go in that direction.

Java Proxies were very useful in the 2000’s, but now they begin to be old fashioned and brings a lot of problem (huge stack trace, JVM optimization, High resource consumption, etc…). Right now CDI spec take for granted that proxies will be used in implementations.

For this reason, it could be a good solution to provide a subset of CDI specification with less magic and less weight. Let’s call it “CDI Lite” (like EJB Lite that were introduced in Java EE 6). This CDI subset would keep all the DI stuff but would probably get rid of all the Context part as well as Interceptor and Decorator.

But there are others tracks that could be explored to make CDI lighter without removing some of its features.

Bye bye Proxy, hello Annotation Processing and InvokeDynamic

This other way is to find solution to replace proxies by something else in CDI implementations. Right now we have two candidates :

  • Annotation Processing : process Annotation at compile time to produce the “magic” injection/injected/decorated code in a static way like it’s done in Dagger.

  • InvokeDynamic : Runtime linking could provide a proxy-like behavior with less drawbacks and probably more performances. Regarding this second approach I started to do some researches and hope provide a proof of concept soon.

XML config file

It’s time to provide this feature in the spec. There use to be extensions out there that provide this feature, but this is a core feature allowing bean registering and annotation overloading at deploy time and it should be in the spec. If CDI could become more and more present in the other spec, it could also be the beginning of a universal Java EE config file format !

Today, some framework like Apache Camel cannot use CDI because there is no config solution. Providing a solution on that point would ease CDI adoption.

Asynchronous event / action

At the vert.x and node.js era we definitely should support asynchronous treatment (and let’s dream : call back). This could be done By using concurrency spec. We would provide a way to support asynchronous call without using EJB and asynchronous event by adding a boolean asynchronous field in @Observes and, optionally, a handle on a callback

Support of @Startup

An easy feature to add : provide a way to have a CDI bean automatically instantiated after the initialization phase like we already have in EJB.

It’s a very common request by developers and it’s not very hard to provide.

Portable Extension SPI promotion / usage simplification

CDI Lifecycle
CDI 1.1 container initialization and Lifecycle

Portable Extension is, in my opinion, the best feature in CDI. Off course IoC, events or context management are great but they weren’t new when introduced in CDI 1.0.

Portable extension is a complete CDI innovation, that added to Java EE DNA the possibility to be naturally extended without using proprietary tricks.

In my opinion it’s a pity that Portable Extension were not more promoted (CDI acronym doesn’t include any idea of their existence for instance) and were placed at the end of our specification document since a lot of projects or other specification could benefit from it.

My analyze is that this lack of communication is linked to the bunch of more or less complexe concepts (like the container initialization events shown in the right side schema) to understand before being able to deep dive into extension development. We should probably provide a higher simplified layer to get started with basic task on extension. Don’t misunderstand me, the existing mechanism is great and should be kept (with probably some enhancement) but we should provide helpers to ease extension creation. These helper could be :

  • Standardization of Deltaspike AnnotatedTypeBuilder and BeanBuilder to ease new Beans creation

  • Helpers on introspection tools regarding types or annotation manipulation

  • Easier way to create new scopes or extend existing ones. We encourage other spec to extend lifecycle of existing scopes (like @RequestScoped for Websocket) but it’s nearly impossible to do it without going at the implementation level.

We should also bring a special attention to the first events (until AfterTypeDiscovery) in this initialization process, since they are CDI agnostic dealing only with type and annotation metadata modification. These could become part of a future Java EE configuration system.

Ordering event execution

So in CDI 1.1 decorator and interceptor are ordered thanks to @Priority. What about ordering events ? Using @Priority on @Observes doesn’t seem a good idea since this annotation comes from the interceptor package, but we could add an int priority field in @Observes.

No more segregation for Producers and Custom beans

Why produced bean or custom bean should be CDI second class citizen? I want to be able to decorate or use interceptor on my produced beans or at least have APIs that allow me to add this features to my produced beans.

Event scoping from package to server wide

Having the CDI event bus at a higher level in Java EE would allow scoping our event. Soone could decide if the event should stay in the current application, be restricted to the current module (in an EAR) even the current package or on the other side be broadcasted to all app listening to it.

Transient injection

When injecting dependent bean in a longer living bean, this injection is done once when the longer bean is instantiated. There are use cases (I’ve got one in Agorava) where I want my dependent bean to be re-injected each times it’s accessed. Today I have to write :

@Inject Instance<MyBean> myBeanInstances;
public Mybean getMyBean() { return myBeanInstances.get(); }

Tomorrow I’d like to write this :

@Inject @Transient MyBean myBean;

It’s mainly syntaxic sugar but make the code more easy to write and readable. We probably could find other example here of code simplification.

Have a more fluent programmatic lookup

The Instance<T> interface and the programmatic lookup are incredibly useful, but it could be very cumbersome to use especially when we have to deal with Qualifiers.

This could be eased by providing tools to generate qualifier literals with Java 8 Type Annotations for instance. And why not a query DSL ?

myBeanInstance.restrictedTo(BeanImp.class).withQualifier(new @MyQualifier("Binding") AnnotationLiteral<>(), new @MyOtherQualifier AnnotationLiteral<>()).select();

Wouldn’t it be more user friendly ?

Monitoring facility

Remember the great debug page in Seam 2 ? I’d like to have the same things or tools to easily build the same feature to monitor my beans and my scope. CDI does a lot of Magic and it could be nice to have tools to see all its trick and the cost of beans, context and other interceptor we deployed

Give me more modularity : a new architecture for CDI (and Java EE ?)

CDI Next Architecture

A lot of JSR complained that CDI spec is too monolithic and that implementations are too heavy comparing to theirs (they don’t want to depend on something bigger). This and the lack of standard Java SE bootstrapping, are probably the 2 mains objection to go for a deep CDI integration in some spec. So we should provide a more modular approach while keeping the possibility to gather all the modules and have a consistent stack that we could use outside Java EE. In my ideal world the different JSR / Modules would be :

Container

This module store all the beans defined in the application. Providing as a standalone module brings the following features :

  • Provides a minimum api/impl for a client app that rely on JNDI to get Beans

  • Provides the possibility to add plugins to the container to support new kind of components (Servlet, JPA Entity, Guice or Spring beans for instance)

  • Prepare the CDI container to be the future universal Java EE container that we’re waiting for

Event bus

Events and observer pattern are great features of CDI spec. But they would be more useful if spec could use them without having to depend on all CDI.

We could imagine a new Java EE specification or a CDI module based on CDI event API to provide Java EE wide eventing model. We could imagine an API only relying on half a dozen classes (more if we add asynchronous treatment, ordering and event scoping) hat would do the Job.

Component Scanning & Extension engine

Today each specification does class scanning at boot time. In general the app server provides a way to group this scanning process in a proprietary way. By standardizing the scanning phase events and the meta-data manipulated during this scanning phase we could provide a consistent experience and a standard way to extend Java EE. CDI already provides most of this feature with its initialization mechanism which allow to “observe” all wished existing classes in deployment and modify meta-data of these classes (i.e. annotations) .

Imagine what you could do if the ProcessAnnotatedType event could be catch at the server level and allow you to put a “veto” on a given servlet or on a group of JPA entities? This feature lead us on the single container and the single configuration file path. A feature dreamt by a lot of developers.

Basic DI

This module would include all API related to simple injection (only pseudo-scope). So all @Inject, @Qualifier, Instance<T>, @Producer, InjectionPoint and other Reflection stuff will be gathered in a light API. Probably what I called “CDI lite” in my previous part.

Context Management

Context is a nice feature of CDI but as everybody don’t need it, it should be put in a optional API package. This part will deal with all the normal scope context and complex life cycles.

Interceptor & Decorator

Today interceptors already have their own JSR. Adding decorator to the JSR would complete the interceptor JSR.

Conclusion : CDI needs you!

So, here’s my personal CDI wish list. You probably have yours (we collected your 3 CDI 2 wishes in december / january, and we intend to use them. If you didn’t send them, feel free to add them in comment of this article). I don’t know if all these point are good ideas (just read the comment to make your opinion). I don’t know if they are all doable (probably not). What I know is that we’ll need all help we can have to work on the future CDI 2.0. So if you want to be part of this adventure, stay tuned on CDI official website, @cdispec twitter account (or mine) and this blog and give us your feedback on CDI ML or CDI IRC channel (#jsr346 on freenode). The coming months will be decisive regarding CDI (and Java EE) future.

Please JBoss don’t let CDI become the « Betamax » of Java by destroying Seam 3

Posted by Antoine Sabot-Durand on Sep 30, 2011 | Comments
betamax

Following the in.relation.to blog post of last tuesday,as a tech lead on one Seam Module (Seam Social),I wrote this open Letter to Red Hat employees in charge of Seam project and community. I find useful to share my point of view with the community on this matter. You also might find interesting to read the blog post of Hannelita on the same subject.

Here is my letter:

This email is a tentative to gather and synthesize all my thought following the yesterday announce on in.relation.to about Seam 3 reorganization. I want it to be seen as a positive feedback. I don’t pretend to have all the answers but being someone external to Red Hat and having worked with other frameworks / technologies give me (I think) a better « big picture »view and a more objective perception of the matter.

Who’s talking ?

I’m not going to tell you all my life here. But it can help for my legitimacy to know that I graduated from a famous IT School in 1995 (yes I’m 40) and had been working in IT since then. I started with C / C++ and then Lotus Domino (talking about mistakes). I started looking into Java in 1997 as a hobby and more seriously for work in 2001. I worked with a lot of Java frameworks:pure servlet and JSP,Struts 1.X,iBatis,Spring,JSF,Hibernate,EJB3,Seam 2 (I started with 2 beta in 2007) to finally adopt Java EE 6.

I’d been working alone for 10 years then after that as a CTO in a small Web Agency (where I learnt some web marketing) and I’ve bee working since 2009 as a consultant in an IT Consulting company specialized on Java. My Job is to audit applications,design new application as an architect and doing support to other developer on a bunch of technologies.

History (knowing our « opponent »)

Again,I’m not going to write a novel here but I think it’s better to put things in perspective.

JCP had clearly a bad start. Most of specification in J2EE before Java EE 5 were full of flaws (especially EJB 1.X and 2.X). That’s mainly the reason why Spring was created and has been so successful:it was a pragmatic and rather clean way to address Java Enterprise needs. From a lightweight solution spring grown to a heavy but quite consistent eco-system and today it has a big market share in the Java Industry. Meanwhile spring was getting bigger,the JCP somehow took notice of its past errors and worked to change things and provide nice specification for the new Java EE edition. But we had to wait for Java EE 6 to get an official standard that was able to compete with Spring (the de Facto Standard) thanks to CDI and the tremendous work that JBoss guys put in it.

So today we are in a paradoxical situation where the official Java EE stack is the challenger of the de facto standard:Spring. To be honest,Java EE is better than core Spring but not way better. Also Spring has a lot of popular modules that help developers in their daily work (a big eco-system). A lot of company have invested on Spring (training,support,etc…) and they have no obvious reason to switch to Java EE 6. If we want to bring them to this switch we have to build something better and something bigger

What should be Red Hat goals ?

The main goal for Red Hat is to sell licenses and support. I don’t know your exact income on JBoss activity but with a real big Java EE adoption,those incomes should rise very clearly. Right now most of the JBoss EAP server I see at my customer run Spring application and most of these server could be switched to Tomcat or Jetty tomorrow without any big trouble (the same for most WAS or Weblogic).

A secondary goal (that interest me more) is philosophical. The Java EE 6 stack is a community creation,its blue print doesn’t belong to a single shop and tomorrow if someone want to propose something new he could contribute to this community. Ok,it’s not perfect but for me it’s far way better than having VMWare deciding what’s good and wrong for me. I often say to Spring Fanboys that if they want to have one editor to decide for them they’d better switch to .Net:Microsoft does a better Job than VMWare and C# is better than Java :-) . The advantage of Java eco-system is the community. So the Goal is to use the force of this community and bring open solutions to them.

Creating a big and good CDI eco-system will create value,bring real competition to the Java stack and create more business for Red Hat (AS license or support on main CDI components)

Why CDI is so special

CDI is not a spec among others. It’s the long awaited cement in Java EE stack. It could have been an extension of EJB spec but it was clever to create it as a separate spec and allow it to deal with EJBs. CDI is the first Java EE spec that contains in its DNA a natural extension mechanism. And last but not least CDI is probably the first Java EE spec to be usable in its V 1.0 (perhaps with Jax-RS).

A common critic to Java EE is that it has a very long cycle between each iteration and that it delivers outdated specs. Another common critic is that it provides a bunch of specs that doesn’t work well together.

This second critic was addressed by Seam 2. Seam was a big help to make Java EE 5 easy to use,but as you know it was proprietary.

CDI address both critics:it has the potential to provide the same services than Seam 2 and it is a good way to extend Java EE between two versions.

To sum up CDI is a central spec for Java EE (it’s its spine):

  1. CDI is the cement between main Java EE spec

  2. CDI the « melting pot »engine for adding new spec in Java EE. First in a proprietary approach and then by standardization in next EE version.

  3. For extension that can’t be integrated in Java EE (like Seam social) it’s an elegant and seamless way to enhance the stack. Past and present Errors

Error 1: A bad name

The first error in my opinion was to call it « Seam 3 ». This bad choice triggered these pb:

giving the impression that Seam 3 was an evolution of Seam 2. Which it is not. creating the obligation to build a compatibility module from Seam 2 to Seam 3. This module is costing a lot of energy to the community and will only produce deception Hiding the CDI nature of these extensions by calling them after the name of an « old »JBoss proprietary framework What is done is done,Seam 3 is now among us,but the legacy is heavy…

Error 2: pretending Spring doesn’t exist

Ignore existing market is a big mistake. Spring is well implanted and doing as if it wasn’t there is wrong. I think a better way would be to adopt the following philosophy:« We know that you had to use this proprietary framework because there was nothing else but now we will show you something new,better,but that can use your Spring eco-system ». Yes the Spring bridge is not an option,It’s a priority. You have to help people switching by giving them a way to use their Spring components so they don’t feel lost and can use Spring module until Seam has the equivalent functionality.

Spring team is totally ignoring Java EE. Their ref doc is full of J2EE,EJB 2.1 and nothing about CDI or EJB 3. We have to show the Java community that we’re more open than them and care about people using Spring to come,see and perhaps adopt the standard. The idea is to behave at the opposite of the locking VMWare strategy by being opened and avoiding trolls and misinformation like they do.

Error 3: eating our own dog food with Seam university.

Don’t get me wrong: the idea of Seam University website is great. What is not so great is to use our tool to create the site. We don’t have time to build something neat,so it’ll be crappy and we’ll lost time on it. Result:bad impression and time wasted. Other Framework don’t use themselves to create their website,they use standard tools. We should do the same for the Seam website. People are waiting for simple demo and example not a big steam machine like the Seam Wiki is today.

Error 4: mix internal functioning with facade functioning of the project

Having Seam module created near their mother project (Hibernate,Resteasy…) is not a bad idea. The bad idea is to make them disappear from the Seam stack. You can have CDI-persistence (note I didn’t wrote CDI-Hibernate) driven by Hibernate project ,but it should be visible in both Seam stack and hibernate. Because One can discover it while using Hibernate or while looking for a persistent CDI extension.

Error 5: giving the impression that those modules will have adherence to Jboss implementation

Calling the module Hibernate-CDI or RestEasy-CDI is a big step back (even if you keep portability). Tomorrow developers on WAS or Glassfish won’t choose them because it doesn’t support JPA but hibernate (it’s in the name). A non sense after all the effort that Jboss has injected in working on standard.

It’s important that Seam appear as collection of CDI extension that allow to leverage standard Java EE. Having them under one umbrella allow Red Hat to sell optional support for them if people want to use them on WAS,Glassfish,Tomcat or Resin.

What should Seam 3 be (according to me)

Seam should be turned to the community. I don’t know if Red Hat would be ok to do that but the core project should be outside of JBoss and community driven. It would be the best solution to gather our effort with those of CDI Source,Codi,Caucho and others.

Seam 3 should run on all CDI implementation. That’s a priority (today,Solder doesn’t work on Candi,I didn’t tested on Open WebBeans but I guess there are issues).

Seam should provide light modules with good documentation and example. I mention that because i have he impression that Solder is becoming a kind of trash can. It’s not good. On the other way the split between persistence and transaction was a good move in my opinion

Seam should have a clear roadmap and timeline. We have to communicate,communicate and communicate. Don’t forget that we have to convince people using an equivalent solution. We must show why we are better and that we have a clear Goal.

Thanks for your time reading my long mail. I hope it’ll be useful and I’m ready to contribute to these orientation.

regards,

Antoine

UPDATE: Shane Bryzak project leader on Seam 3 posted an update this morning,to explain there is something in preparation around Seam.