{"id":1088,"date":"2010-10-19T21:56:27","date_gmt":"2010-10-19T16:26:27","guid":{"rendered":"http:\/\/naveenbalani.com\/?p=1088"},"modified":"2016-09-17T09:59:28","modified_gmt":"2016-09-17T04:29:28","slug":"do-you-need-to-move-from-spring-to-java-ee-6","status":"publish","type":"post","link":"https:\/\/navveenbalani.dev\/index.php\/articles\/do-you-need-to-move-from-spring-to-java-ee-6\/","title":{"rendered":"Do you need to move from Spring to Java EE 6"},"content":{"rendered":"

I recently read an interesting post on TSS- \u201cMoving from Spring to Java EE 6: The Age of Frameworks is Over<\/a>\u201d.\u00a0 I am sure, everyone would have its perspective on the above blog and here are my views on this.<\/p>\n

But before that, let\u2019s step back and look and why frameworks like Spring was invented in the first place. In my view, primarily it was created as an alternative to J2EE stack, to keep it simplified, POJO centric and testable without the need for a container. Then came in support for various abstractions layers \u2013 JDBC, Transactions, ORM, JMS which can be applied POJO in a consistent manner and support for plugging in any web framework , all backed by principle of dependency injection. What it offered was a choice to programmers (and that\u2019s very important) and didn\u2019t restrict it usage to any specific API directly.\u00a0 Using Spring, one could create modular components which could be run against a J2SE environment(derby and local transaction manager for your local test environment) and then promoted to use capabilities offered by J2EE Applications servers like JNDI, JTA and so on.<\/p>\n

Over the years, J2EE tried to catch on, tried to create specifications and standardizations which were well adopted and tested by the framework like Spring or ORM providers like Hibernate. Specifications are good, but lot of time goes in creating specifications and it takes even lot more to get these specifications incorporated into the release of J2EE servers and stacks. Though specifications were created, you would still see vendor specific extensions required to run a particular feature. I mean, can you still take an Enterprise application (running on latest J2EE spec), which has couple of EJBs (3.0 or 3.x), uses transaction and JMS services and run it on a server which supports the same J2EE specs. Probably No, Yes, May be with the latest specification, may be with vendor specific extensions (?).\u00a0 Let\u2019s look at the latest release features to find more of this information.<\/p>\n

The latest release of J2EE has support for Dependency injection (JSR-299 contexts and Dependency Injection for the Java EE platform specification), which is same as offered by Spring, Bean Validation (standard Bean validation offered by Apache projects, but now using standard annotations), streamlined development (through the use of POJO, JPA for persistence and revised EJB approach) and extensibility to add in vendor specific extensions in a consistent way. If you look at these goals, these matches with principles which I had listed earlier on why Spring was invented, only thing it took J2EE probably too long (probably 6-7 years assuming Spring starting gaining widely adopted in 2003) to arrive at this specification.\u00a0 Even though J2EE has the principles now, it still restricts its usage to that of a container, for instance I can run spring in a standalone environment (J2SE environment with local database and transaction support) as well as promote it to full fledged J2EE application, running on multiple application servers.Also there are no approaches provided on how to test individual components (in and outside the container) using a pure J2EE stack. I seriously feel, there should be specification around testing of components.
\nTo conclude with some thoughts –<\/p>\n