Comment Still missing the point... (Score 1) 236
People are still missing the point the article was trying to make (or haven't even read / understood it).
The situation is this:
* On one hand JEE describes a set of patterns and best practices Java web applications should be architected with
* Additionally, JEE also prescribes the implementation of these patterns JEE developers should use (Session Beans, Entity Beans, etc.)
The fact is that when developing JEE applications, on a technical level developers can choose to completely ignore some of these JCP technologies and implement the JEE patterns using perfectly fine, capable and even superior alternatives, such as Hibernate and Spring.
So the point the article's author was trying to make was that just as AJAX describes a set of patterns for developing web applications, while the developer chooses the implementation he prefers (JSON, DWR, frameworks such as Dojo, YUI, whatever...), JEE could benefit from "officially" allowing developers to freely choose whatever implementation of those patterns they saw fit (such as using Spring and Hibernate instead of the JCP-sanctioned Session Beans and Entity Beans respectively), instead of trying to force them to use the standard ones.
That's how he was comparing JEE and AJAX and how he was hoping things could be similar - nothing to do with comparing "apples and oranges".
Personally, I've been using Spring and Hibernate in my JEE projects instead of the official implementations for some time now, and seeing the advantages and innovations these have put on the table, I have agree with his point.
The situation is this:
* On one hand JEE describes a set of patterns and best practices Java web applications should be architected with
* Additionally, JEE also prescribes the implementation of these patterns JEE developers should use (Session Beans, Entity Beans, etc.)
The fact is that when developing JEE applications, on a technical level developers can choose to completely ignore some of these JCP technologies and implement the JEE patterns using perfectly fine, capable and even superior alternatives, such as Hibernate and Spring.
So the point the article's author was trying to make was that just as AJAX describes a set of patterns for developing web applications, while the developer chooses the implementation he prefers (JSON, DWR, frameworks such as Dojo, YUI, whatever...), JEE could benefit from "officially" allowing developers to freely choose whatever implementation of those patterns they saw fit (such as using Spring and Hibernate instead of the JCP-sanctioned Session Beans and Entity Beans respectively), instead of trying to force them to use the standard ones.
That's how he was comparing JEE and AJAX and how he was hoping things could be similar - nothing to do with comparing "apples and oranges".
Personally, I've been using Spring and Hibernate in my JEE projects instead of the official implementations for some time now, and seeing the advantages and innovations these have put on the table, I have agree with his point.