Yesterday, I visited the one-day conference “DOAG SIG Java”, because I presented about applicability and limits of Java Server Faces 2.0 (JSF 2.0). The main subject was the Java Enterprise Edition 6 (JEE 6). I wrote a report about it in another blog entry: One-Day Conference “DOAG SIG Java 2010” about Java Enterprise Edition (JEE) 6.
The final track included a live demo of Adam Bien, a well-known JEE expert, author and speaker (also involved in the JEE specs). A very nice “live show” of the JEE 6 features!
The participants (including me) asked a lot of questions crititcally, Adam Bien always had very good answers and explanations because of his excessive experiences with Java technologies for several years.
While answering our questions, Adam Bien claimed some very interesting statements, which I want do list and discuss in the following (I agree with most of them)…
Statement 1: Tomcat is not as lightweight as it appears first!
Tomcat is a very lightwight web container, that is true. But where is the benefit, if the size of many deployed applications is larger than the container itself? You have to add all required libraries to your lib folder, because Tomcat does not offer them. On the other side, application servers already contain implementations for the JEE specs.
Statement 2: Use the full JEE 6 stack instead of the Web Profile for development whenever possible!
The new JEE 6 Profiles (such as the Web Profile) limit the environment because they prohibit some features such as Remote EJBs, MDBs, Timer and so on. But why should you use e.g. the Web Profile for development? The size of the full JEE stack contains only 30 Mb more. Maybe the performance differs slightly, but the developer does not notice this barely measurable difference in practice.
We discussed another intention of these profiles earlier that day: The profiles shall help other vendors to build JEE conform containers. They do not have do implement every (rarely used) specification, so it should be a lot easier for smaller companies to build a product.
Statement 3: Use EJBs instead of POJOs!
Why should you still use EJBs instead of POJOs in many projects? You get transactions, threads and JMX-integration for no additional effort.
Statement 4: JEE 6 and Spring 3 are very similar!
The current versions of JEE (version 6) and Spring (version 3) are very similiar. The decision is a question of faith: JEE uses conventions over configuration, Spring forces the developer explicitly to add configuration (e.g. for transactions). So choose what you prefer, or if one of it is already used in a project, then continue using it.
I agree. By the way: Personally, I prefer JEE 6.
Statement 5: Two annotations should be enough above one Java class!
Do annotations make the source code more confusing? No. If you use more than two annotations above a class declaration, then the class contains too much functionality.
I slightly disagree. I really like Annotations. But there is a threat, that many people use them everywhere. And probably, many APIs will be created that require much more than two annotations. For instance, JPA 2.0 is very borderline! Sometimes, you (have to) use more annotations than other lines of code.But I still think that Annotations are much better than XML configuration for these tasks.
Statement 6: Use interfaces only if you need them!
Use interfaces only if you need them (e.g. using the strategy pattern)! You also no more need interfaces for mock-tests since two years.
I agree. In our current project, we use a class (without “impl” or other naming conventions). If you need an interface in the future, just make a simple refactoring!
Statement 7: Use REST instead of SOAP!
If possible, use REST instead of SOAP!
Another well-know german IT expert, Stefan Tilkov (innoQ), contributes many reasons, why REST is almost always better than SOAP in a very nice (german) podcast: Podcast about REST and SOAP web services. And here you can find a great introduction to REST.
Statement 8: Flash has no future because iPhone and iPad do not support it!
Adam Bien does not use Flash or Flex in his projects since two years. The reason: No iPhone and no iPad support (these devices do not support the Adobe Flash Player). Many customers do not know this fact, before Adam Bien explains it to them. The decision of Apple “killed” Flash as alternative for future applications.
I agree, that this decision of Apple is very tough for Adobe and that the integration of multimedia (especially videos) in HTML 5 will make the Adobe Flash Player unneccesary in the future. But this will take some more years of course…
Statement 9: Do not mix JEE and Spring in future projects!
Mixing JEE and Spring in future projects is very risky, because you have to buy two different support licenses. Unfortunatelly, Spring and some JEE containers (namely e.g. Glassfish) do not offer updates / patches for an older major version after a newer major version has released. So, companies have a higher risk, when using both technology stacks.
Overall, I agree. But I think that you can use e.g. the Spring Templates (such as JDBC or JMS Templates) in JEE applications with very low risk, nevertheless…
(if you like these Spring Templates – personally, I do not like them. For instance, if I do not want to use plain JDBC, I usually use the very lightweight persistence framework myBatis (former iBatis) instead.
Statement 10: Convention over Configuration is great for developers!
In many cases, a JEE 6 Developer is not required to know many details about the JEE specs to build good applications. For instance, you often do not need to know about the JSF life cylce, but you can nevertheless write web applications.
I agree. Convention over configuration increases ease of development a lot. It is much easier to start with JEE 6 than some time ago where you had to learn JEE 5 or even worse JEE 1.4.
So, some very interesting statements are discussed… I think that JEE 6 is a great improvement. So let’s hope that some more stable certified JEE 6 application servers will release soon!
Best regards, Kai Wähner (Twitter: @KaiWaehner)