Fallacy 10: ...and JavaEE will die. :-)

I compare Java EE 5 with an operating system for serverside, business components. So, saying Java EE 5 will die is like saying an operating system will die, without mentioning the vendor.
Java EE 5 is "only" a bunch of vendor-neutral APIs which are implemented by different products. Java SE/EE APIs like JMS (Meessage Oriented Middleware), JNDI (LDAP, NDS and Active Directory), JDBC (database access), JCA (connector to EIS), JMX (management products). These APIs are an integral part of every application server. Of course there are some projects, which do not need every single API, but this is very natural. On the other hand, we have EJB 3/JPA, Servlets and JSF programming models. From my perspective EJB 3 is simple and powerful and greatly simplifies remoting, transactionality and QoS. JPA (Java Persistence API) is also great - and vendor neutral. Of course you could use alternative component models, but you should have to have good arguments for doing this (introducing new frameworks ==> deploying additional jar ==> increases complexity of development, deployment and dependency management ==> increases project risks ).
JSF is complex, so you need good tools (just try out VisualWeb Pack), but you could also use the alternatives. JPA is great as OR-Mapper, for data-set oriented persistence you could use JDBC 4.0 which is also lean and powerful.

So Java EE cannot die - you can of course replace some APIs in real world projects with alternatives, but this does not mean the death of Java EE - only a project-specific optimization.
We can of course argue "A small project do not need Java EE...", but in the practice there are no small projects. In case they are small, they are grow very fast :-).

Summary of the Java EE fallacy series of posts:

Introduction: "Common Java EE fallacies"
Fallacy 1 : J2EE/Java EE 5 consists only of EJBs.
Fallacy 2: EJBs are too complex, POJOs are easier
Fallacy 2.5: Concurrency, Persistence, Transactions and Java EE
Fallacy 3:We have only to consider ther development phase. The maintenance and production are not important.
Fallacy 4: Lean POJOs and transparent persistency are easier to understand for a beginner, than heavyweight EJBs.
Fallacy 5: JMS, JCA, JTA, JNDI, XA are too complex, too heavy and aren't needed at all.
Fallacy 7: Development over Monitoring, management and profiling
Fallacy 8: It is very easy to implement everything you want in a web container
Fallacy 9: It is sufficient to ensure the functionality of a distributed application with unit- and integration-tests.

This was the last post about the Java EE fallacies Your comments are, as always, appreciated.