Comment Re:Java EE is *different* from AJAX, and vice-vers (Score 2, Interesting) 236
My beef is with this concept right here:
Maybe I am in the minority but I have spent a lot of time reading the Java EE specs and trying to implement them. After implementing them for a couple of years I realized that Java EE is a solution looking for a problem. After writing applications for small web startup to a top financial institution, my reflection is that EE breaks KISS. The spec tries to be everything for everyone and thus is overly complex for most business applications and for all the benifits it is supposed to offer it creates as many problems.
Example if you look at the Entity Bean OR mapper locking specs you will see that if you have any kind of load (Assuming one of the E stands for enterprise that is generally true) well you get locked up if more than one thread is trying to access that object at a time and your concurrency breaks down and if you are using a good provider it start spouting out Deadlock Exceptions. After I tweaked the provider to turn some of the "EE features" off, made a lot of work arounds and wrote a lot of scripts to generate all kinds of code I finally had something useful.
BEGIN RANT
Now I do not claim to be some super coder. My experience is that all the things EE spec was supposed to do it didn't. Unlike the servlet spec we still have vendor lock down, we have more code (XML, umpteen million interface files, lots of wrappers code that needs script generators or xdocletization) all so we can move data in and out of a database and on to a web page or GUI.
END RANT
Feels good to get that off my chest.
I am disheartened by reading the comments... people, PLEASE for once in life go and read Java EE specs and see what it is intended to do. Java EE is a framework to write business applications, for any kind of business, from issue trackers to ERP, the "business" in it doesn't mean "$$$ business" literally.
Maybe I am in the minority but I have spent a lot of time reading the Java EE specs and trying to implement them. After implementing them for a couple of years I realized that Java EE is a solution looking for a problem. After writing applications for small web startup to a top financial institution, my reflection is that EE breaks KISS. The spec tries to be everything for everyone and thus is overly complex for most business applications and for all the benifits it is supposed to offer it creates as many problems.
Example if you look at the Entity Bean OR mapper locking specs you will see that if you have any kind of load (Assuming one of the E stands for enterprise that is generally true) well you get locked up if more than one thread is trying to access that object at a time and your concurrency breaks down and if you are using a good provider it start spouting out Deadlock Exceptions. After I tweaked the provider to turn some of the "EE features" off, made a lot of work arounds and wrote a lot of scripts to generate all kinds of code I finally had something useful.
BEGIN RANT
Now I do not claim to be some super coder. My experience is that all the things EE spec was supposed to do it didn't. Unlike the servlet spec we still have vendor lock down, we have more code (XML, umpteen million interface files, lots of wrappers code that needs script generators or xdocletization) all so we can move data in and out of a database and on to a web page or GUI.
END RANT
Feels good to get that off my chest.
