The Apache OpenWebBeans team has been quite busy with big refactorings. Big improvements have been made to the proxying mechanism, the Bean scanning and the AnnotatedType handling. We managed to improve the overall performance again and now deliver almost native Java like performance for our NormalScoping proxies.

Parts which are already implemented

Let's take a close look at a few details of the parts we already finished and explain them briefly.

Split between NormalScoping Proxies and Interceptor Proxies

In OpenWebBeans 1.0.x and 1.1.x a single Bean only had one single Proxy handling for all tasks - The NormalScopedBeanInterceptorHandler. This did handle all the stuff like Interceptors, Decorators provide subclassing for abstract Decorators but also did the NormalScope handling.

As result of this unified handling we only stored the native Contextual Instances in the Contexts (Session, Request map, Conversation map, etc). The negative side effect of this approach was that we had to introduce a quite hacky mechanism to regain access to the CreationalContext. Needless to say that this was not only complex but also error prone.

In OpenWebBeans-1.2.0 we now maintain 2 proxies. The first one solely handles NormalScoping, then 2nd one does all the Interceptor and Decorator stuff. The most important change is that we apply the DecoratorProxy directly 1:1 on the Contextual Instance and thus don't need to do any of those weird CreationalContext hacks anymore. Instead the already intercepted/decorated instance gets stored in the Context.

All NormalScope proxies now implement the Interface OwbNormalScopeProxy and have a name *$OwbNormalScopeProxy*.

All Interceptor and/or Decorator proxies implement the Interface OwbInterceptorProxy and have a name *$OwbInterceptProxy*.

Additionally to those 2 proxies we also introduced a new separate proxy kind for creating subclasses for abstract Decorators which now implement the marker interface OwbDecoratorProxy.

Creating our own proxy bytecode

For performance reasons we moved from using Javassist (where we fixed quite a few mem leaks in the past) to generating our own native Java ByteCode with ASM. We now only use reflection if really necessary. For standard NormalScoping of public methods we e.g. generate the following code. Consider a simple User class:

public class User {
   public String getGivenName() { return "Hans"; }
}

For this class the generated bytecode of an OwbNormalScopeProxy will look like the following:

public class User$OwbNormalScopeProxy0 extends User {
  private Provider owbContextualInstanceProvider;
 
  public String getGivenName() {
    return owbContextualInstanceProvider.get().getGivenName();
  }
}

There is no bells and whistle and especially no reflection - just pure plain Java bytecode which is blazingly fast!

Btw, we do very similar stuff for non-intercepted methods of intercepted/decorated classes. And we also improved the handling of intercepted methods and are now more than twice as fast as OWB-1.1.7 (which was already very fast). 

Cleaning up the Bean creation

In the past we had 2 ways to create beans. If an Extension used ProcessAnnotatedType to tweak the AnnotatedType of a class then we built the Bean from the modified AnnotatedType. For cases where the AnnotatedType did not get modified we took a completely different part and created the Bean from the Class reflection information. This part came from a time where there was no AnnotatedType in the spec yet.

In OWB-1.2.0 we now do all the Bean construction based on the AnnotatedType - regardless if it got provided by a CDI-Extension or remained unchanged. This made our codebase much easier to maintain! Arne also did a great job by introducing and cleaning up all the BeanBuilders and making the final Bean immutable.

Parts waiting to be done

More new things to come before the release:

  • Replace Scannotation by xbean-finder.
  • Create the initial AnnotatedTypes from the information already collected by xbean-finder instead of doing expensive Class reflection.

CDI-1.0 or CDI-1.1?

We initially targeted CDI-1.1 with this release. But during the development we figured that we do not yet need to. All the parts introduced so far are perfectly working with CDI-1.0 as well. Thus it looks like we gonna release OWB-1.2.0 as still being CDI-1.0. But we are well prepared to support the new features of CDI-1.1 very quickly as we already did all the preparations. Sometimes we internally already use CDI-1.1 mechanisms (like the BeanAttributs) and only have to add 'implements RandomCdi11FeatureInterface'. This will likely be shipped as OWB-2.0.0 though when the spec hits an almost final status and the TCK is available.

How to Test

That's a pretty easy thing. If you have the apache.snapshots maven repo in your build, then you can just reference owb 1.2.0-SNAPSHOT in your build and you're done!