EJB 3.1 embeddable container and end of life for spring framework.

Just amazing what can be found in borring JCP document. All this story started once I decided to do some research regarding EJB 3.1 specification.

I will print only a few sentences from JSR-318 and will add some thought and comments about only one tiny part of it, just what is related with Embedded EJB container.

Enterprise JavaBeansTM 3.1 and what is said about Embedded Container.

Embeddable usage allows client code and its corresponding EJB 3.1 to run within the same JVM and class loader. This provides better support for testing, offline processing (e.g. batch), and the use of the EJB programming model in desktop applications.

The client uses a spec-defined bootstrapping API to start the container and identify the set of enterprise bean components for execution. The embeddable EJB container provides a managed environment with support for the same basic services that exist within a Java EE runtime : injection, access to a component environment, container-managed transactions, etc. In general, enterprise bean components are unaware of the kind of managed environment in which they are running. This allows maximum reusability of enterprise components across a wide range of testing and deployment scenarios without significant rework.

My comments and thoughts.

What makes me happy, this is an ability to have an EJB in desktop applications or regular java web application packaged as war and running in tomcat or other servlet container. Idea of having an EJB in tomcat is not absolutely new, OpenEJB does exactly that, but to be used in desktop application, for me it's a mind blowing idea. I like it very much.
Most of the people are using spring for their desktop applications and it helps a lot. Everyone knows that there are more frameworks following dependency injection pattern such as google-guice, pico container and others. Some of them have better performance, others are easier to use, but all, all of them without exceptions makes you dependent on them, you can not throw them out or replace by something more suitable later, or remove from runtime. Yes application is always dependent on execution environment and in this case dependent on spring or some other DI or EJB container. The point is an EJB container is a specification and it can be replaced by another more suitable for current task or environment, but spring can be replaced only by a newer version of spring.

What is most amazing, even full blown EJB containers such as Glassfish already are close to or almost at the same level of performance as spring framework and is easier to write and configure. Feel shocked, trust me or read these blog posts.

And here are some other interesting blog posts, for example I will list a few of them with some comments:
* Simplest possible EJB 3.1 shows what effort it takes to write an EJB 3.1 compliant bean, no xml, no interfaces, nothing what you ever could call boilerplate code.
* Some interesting thoughts about EJB vs POJO.
* EJB vs POJO performance
* EJB3 memory consumption.


And now the last thoughts. Everyone knows that spring framework is going to become application server, scary, yeah that's right a Java EE Application Server. Don't you think that spring has no option anymore, EJB's already becoming more effective in some cases and it's not a vendor lock in. Only option for spring is to become another option in list of options. What irony I see, is that spring lost his enemy, spring always was an opposition to EE, and now it becomes an EE by himself. That automatically makes it less appealing choice for new projects.

Have fun feature are bright

Regards Remigijus Bauzys