Dopo circa tre anni di intense attività progettuali e complicate fasi realizzative, JBoss AS 5 è finalmente prossimo al rilascio: secondo un articolo di InfoQ, infatti, entro fine Giugno dovrebbe essere disponibile la RC1 del progetto.

Molto significative le parole di Dimitris Andreadis, il greco project leader di JBoss AS: "the sheer scope of AS5 was something that, in my opinion, nobody had realized when this effort started about 3 years ago. Creating from zero a completely new kernel, switching from MBeans to POJOs, integrating AOP to the lowest level, unifying metadata handling across subsystems, altering the classloading system, aspectizing the deployers, in other words changing the internal architecture and replacing the guts of the application server, while maintaining backwards compatibility with the majority of existing services, that was just too much work with big challenges in every step of the way"

Andreadis sottolinea inoltre alcune delle differenze architetturali che contraddistinguono JBoss dagli attuali concorrenti, con particolare riferimento a Spring Application Platform, e lo fa introducendo il concetto di pluggable components model. Un risultato che deve esser costato parecchia fatica a tutto lo staff di sviluppo: "After 3 years of R&D with JBoss 5 we've learned the hard way that switching kernels and component models can be a very painful process: it is plain wrong to tie in your server internals to any particular component model. Our competition will most likely suffer the same pain when for some reason OSGi goes out of fashion, or some cooler component model comes along. In one sense they look like JBoss 7 years ago"

Ma la parte che mi è sembrata più interessante è quella in cui si "osservano" le specifiche Java EE 6 dalla prospettiva JBoss AS: Personally I have mixed feelings over the proposal of profiles in Java EE 6. The primary purpose of having a Java EE specification is to provide the developers with a comprehensive tool set of EE technologies so that applications have a greater chance of being portable between compliant runtimes. By reducing this set of technologies to a very small subset (e.g. profile A) you are forcing the developers to add non-spec compliant extensions, thus decreasing the portability of EE applications...What is important is for the broader set of Java EE technologies to be comprehensive, generally useful and current. The introduction of EJB3, JPA, JAX-WS were huge boost to the platform. The pruning process is also a step to the right direction. There are parts of the Java EE spec that are really edge cases (e.g. CSIv2), or obsoleted (e.g. CMP) and they should be retired from the platform. However, when discussing whether a basic profile should offer JSP vs. JSF that's just silly; there are good uses of both technologies out there.