I am currently the lead of the JBoss Application Server project. I am also a member of the JCP, and represent Red Hat on the future Java EE6 specification. During my tenure at JBoss, I have worked in many areas including the application server, clustering, web services, AOP, and security. My interests include concurrency, distributed computing, hardware and programming language design.

Location: Madison, WI
Occupation: Principal Software Engineer at JBoss, a division of Red Hat
10. May 2010, 21:25 CET, by Jason Greene

Last week we released the third milestone for AS6. One major improvement this release brings is a completely new high performance messaging implementation. HornetQ is available out of the box, all you have to do is setup your queues/topics and deploy any EE app using JMS. You can read more about this on Clebert's blog .

Another major feature this release includes is support for EJB 3.1 singleton beans, and container managed concurrency. For those that aren't familiar with singleton beans, they are essentially a stateless bean that can be used similar to the "servlet" model, where you can have multiple concurrent requests on the same instance. Traditional stateless session beans can never allow multiple threads to execute on the same instance. This means the container must pool a collection of instances to be ready to process your request load. The obvious advantage this brings is that it simplifies the bean implementation; however, for some applications the pooling, especially when left untuned, can be counter-productive. Singletons are a way to achieve greater control by allowing the application to implement any concurrency/locking model of its choosing.

If you have an application that that follows a common read/write locking pattern, then a singleton can optionally use container managed concurrency by annotating methods with the @Lock(READ) and @Lock(Write) annotations. This gives you the additional control but takes some of the burden of lock management away.

Another notable addition to the M3 release, is a new OSGI profile that can be triggered using the -c option:

./ -c osgi

This will start a number of OSGi services, as well as the ability to directly deploy bundles. You can find out more on how to use this new profile by checking out the JBoss OSGI project docs.

There are of course many other improvements too numerous to mention. To get the complete list of features, changes, and fixes that made this release, take a look at the full release notes, available here.

As always, you can download all AS releases on the AS download page.

17. Feb 2010, 06:13 CET, by Jason Greene

JBoss AS 6.0.0.M2 has just been released. A major highlight is that this release delivers three more key EE6 capabilities:

  • JPA 2
  • Servlet 3
  • JAX-RS (RESTful services).

You can read all about it in Brian's official announcement here.

Get it now!

03. Dec 2009, 01:56 CET, by Jason Greene

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?


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();


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);
   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.


Showing 6 to 10 of 13 blog entries