How do you follow the fantastic news of the week with the Java EE6 platform and CDI getting final approval ? How about a JBoss AS release that includes support for three key EE6 features: CDI, Bean Validation, and JSF 2?

Done!

For those that aren't familiar with these technologies, each offers significant improvements to EE application development.

CDI (or Contexts and Dependency Injection) brings real context management and DI to the EE platform, and simplifies the integration of EE services with your application. Not only does it have innovative features that make life easier, but everything it does is completely type-safe, and easily extensible. Check out Gavin's interview with DZone for more information. Also check out the Weld page (our implementation and also the RI for CDI).

Bean Validation solves one of the biggest problems developers face daily, ensuring their data model is validated consistently and correctly as it progresses through each layer of an application. Instead of the common current cut-and-paste practice that is difficult to maintain and error prone, Bean Validation allows you to put all of your validation rules where they belong, the data model itself. Since JSF 2 and JPA 2 integrate with Bean Validation, all layers of your application will enforce those rules. This reduces errors, simplifies development, and saves time (and your C and V keys). For more information see Emmanuel's blog on Hibernate Validator 4 (our implementation of Bean Validation). Stay tuned for more info on how to integrate Bean Validation in your EE applications.

For those of you running in high availability environments, we have also included a brand new intelligent load balancing module called mod_cluster. You can read all about that in Brian's blog.

Note that in this release we are switching to a milestone based versioning scheme. The primary reason for this change is to provide a way to get completed features to the community as soon as they are ready. This is quite a bit different from a normal Alpha/Beta scheme which typically results in many incomplete capabilities in raw fashion, that slowly become complete towards the end of the release lifespan. The milestone model instead focuses on time constrained releases that each provide a small set of completed features. As an example, the M1 release actually includes Weld 1.0.0, which is a stable final release of Weld. If you are thinking of targeting your application on AS 6.0.0, you will be able to start with M1, and progress to future milestones as we add features and improvements.

You can find the full release notes for the release here, and the official download location is here.

As always, have a great open source day!

I am happy to announce the 5.1.0.CR1 release of the JBoss Application Server! This is the first AS release to include Embedded JOPR, our new web-based administration console. We are hoping to get as much feedback as possible before releasing the final 5.1.0, so please try it out and tell us what you think.

Also included in this release is the new 1.0.0.PREVIEW release of Web Beans, a key technology that greatly simplifies EE web development. This release is the first feature complete implementation of the public draft. Check out Pete's blog for more info.

For those that were missing the farming clustering service, it is now back as of this release. See the wiki page on the relevant changes.

As always, many other updates too numerous to mention were made. To see the full list, check out the detailed release notes.

Download 5.1.0.CR1 here, and have a great open source day!

Out of need, I recently contributed a data-flow analysis framework to javassist. The framework allows an application to determine, by inference, the type-state of the local variable table and stack frame at the start of every bytecode instruction. For those unfamiliar with the java bytecode format, a lot of information is lost once a java program is compiled, since it is not really needed when the program is executed, and leaving it out helps keep class files small.

To illustrate this loss, take a look at the following simple Java method:

public static class Base {}
public static class A extends Base{}
public static class B extends Base{}
public static class C extends B{}

private void foo(int x) {
   Base b;
   if (x > 4) {
       b = new A();
   } else {
       b = new C();
   }

   b.toString();
}

While it is quite clear in the Java code that b is of type Base, this information is missing from the output of a compiler:

private void foo(int);
  Code:
   Stack=2, Locals=3, Args_size=2
   0:   iload_1
   1:   iconst_4
   2:   if_icmple       16
   5:   new     #68; //class example/Example$A
   8:   dup
   9:   invokespecial   #70; //Method example/Example$A."<init>":()V
   12:  astore_2
   13:  goto    24
   16:  new     #71; //class example/Example$C
   19:  dup
   20:  invokespecial   #73; //Method example/Example$C."<init>":()V
   23:  astore_2
   24:  aload_2
   25:  invokevirtual   #74; //Method java/lang/Object.toString:()Ljava/lang/String;
   28:  pop
   29:  return

Since toString() is declared by Object, all that line 25 tells us is that the type is an Object, which is obviously not very specific. If the class was compiled with debugging, you would be able to learn that local #2 was of type Base, but even if you did have this information, you would not necessarily know that the object invoked on by invokevirtual is the value stored in local variable 2. The only way to determine that is to know the state of the stack frame immediately before the instruction executes.

The analysis framework provides this by modeling the effect of every instruction, until it can eventually infer the type information. This process does not use any debugging information, since there is no guarantee it is available. Instead, it extrapolates it by tracking all possible type states, as every branch is evaluated, until the type information is reduced to the most specific type state available.

The following code, which uses the framework, is able to tell us that the type invoked on line 25 is in fact Base:

Analyzer a = new Analyzer();
CtClass clazz = ClassPool.getDefault().get("example.Example");
Frame[] frames = a.analyze(clazz.getDeclaredMethod("foo"));
System.out.println(frames[25].peek()); // Prints "example.Example$Base"

There is also a nice little tool I added, called framedump, that dumps the entire state at every instruction in human readable format, and yes I know that's debatable :)

$ framedump example.Example
private void foo(int);
0: iload_1
     stack []
     locals [example.Example, int, empty]

... snipped for brevity ...

24: aload_2
     stack []
     locals [example.Example, int, example.Example$Base]
25: invokevirtual #85 = Method java.lang.Object.toString(()Ljava/lang/String;)
     stack [example.Example$Base]
     locals [example.Example, int, example.Example$Base]
28: pop
     stack [java.lang.String]
     locals [example.Example, int, example.Example$Base]
29: return
     stack []
     locals [example.Example, int, example.Example$Base]

Some of you are probably thinking:

That sounds nice and all, but why in the world would I ever need to use this?

It is definitely not something useful to everyone, however it is very useful for certain applications:

• Bytecode Enhancers
• Verifiers
• Optimizers
• Debugging/Profiling Tools
• Decompilers

To expand on the enhancer example, for security reasons, the JVM actually does its own data-flow analysis to verify that a class does not violate type rules before it can be ran. This poses an interesting challenge to any application that manipulates bytecode, since any change that affects the possible type-state can lead to a verify error and the JVM throwing out the class. Frameworks such as this can be used to prevent this problem, since they reveal the same (in the javassist analyzer case, actually more detailed) information available to the JVM's verifier.

If you want to play with this new feature, download the recently released 3.8.0 here.

The javadoc is here.

Note, I should also mention that the ASM project has had a similar framework for quite some time, however, it wasn't usable in my case since I needed the ability to handle reduction of multi-interface and array types. Also, I was already using javassist and switching just wasn't possible, mainly due to other features I rely on.

Enjoy!

Recently the EE6 co-lead, Roberto Chinnici, blogged about the state of profiles in EE6, and requested feedback on which direction the group should take. This was also posted to InfoQ and TSS. Essentially we have a choice between two options:

1. Rubberstamp Tomcat
2. Provide a complete framework for web development.

The first option offers nothing new that doesn't already exist today. Right now you can download Tomcat and, unless you are still developing with just Servlets and JSPs, install the many different frameworks you need to build a modern web application. You are then left to discover the magic version combination that doesn't have dependency conflicts or integration issues.

What we really need is a standardized solution which addresses the three most common needs of modern web applications:

• A data persistence framework
• A component framework
• A rich presentation framework

The full Java EE platform has good solutions for all of these aspects today, and more work is being done to improve them (e.g Web Beans, ability to deploy EJBs in a war, etc). However, the full EE platform also contains many other standards, most of which are focused towards EIS (like CORBA, RMI, JMS, JCA, etc). EIS is, of course, not necessary for a significant portion of web applications. So, the central idea behind option 2, is to deliver a version of the platform that is truly focused towards web development.

Not only can we omit specifications that don't serve the above goals, we can also improve the ones that do to better meet our new-found focus. A good example of this, is EJB-Lite, which only requires support for local session components and JPA.

Taking all of this into account we end up with what I view is the ideal combination, which I have strongly advocated on the EG:

Data Persistence

• JPA 2.0
• JTA 1.1

Component Framework

• EJB Lite 3.1
• Web Beans 1.0

Rich Presentation

• JSF 2.0
• Servlet 3.0 (and friends, jsp, el, jstl etc)

I should also mention that non-standard frameworks would of course still be usable on this profile. As an example, Web Beans will offer an SPI so that any web framework can take advantage of the improved/simplified component integration layer, should it choose to.

However, I think the goal should be to provide a good out-of-the-box solution for web development, and a tomcat profile definitely falls short.

I stumbled upon an interesting post by David J. DeWitt and Michael Stonebraker entitled MapReduce: A major step backwards.

For those not familiar with MapReduce, it is a programming model developed by Google for distributed computing on extremely large sets of data. You can read Google's original paper outlining the technique here.

The authors of this post make some excellent points, most of which are centered upon the importance of a well defined structure and abstraction to data. While I certainly agree to a number of them, it's hard to ignore the simplicity and effectiveness of MapReduce. After all, it is currently being used to process 20 petabytes of data a day.