Home

News: Why J2EE is so complex

  1. Why J2EE is so complex (53 messages)

    Debu Panda of Oracle has written about Why J2EE is so complex!. He discusses "Portability vs. Productivity" and complexity for Administrators. He then goes on to mention J2EE 1.5, and the push for "Ease of Development and Administration".

    Article Conclusion
    J2EE is no way simple and it is complex by virtue of it's openness and due to the fact the community is always try to run on the rule of the book and no body cares of what a hapless developer wants! How ever the reality is simple "For J2EE to survive - we have to make it simple to build, deploy and manage"
    Read Debu Panda in Why J2EE is so complex!

    Threaded Messages (53)

  2. Bulls Eye[ Go to top ]

    Good article. But...in .Net platform assembling, deploying AND migrating can be nightmare too if you get a bunch inexperienced developers.

    J2EE is a great specification but the implementation of it is horrible. Microsoft targets 'corporate developers' where ROI and productivity is paramount. Whereas J2EE vendors are targeting just 'developers'.

    - bibin
  3. J2EE Deployment.[ Go to top ]

    Good article. But...in .Net platform assembling, deploying AND migrating can be nightmare too if you get a bunch inexperienced developers. .... - bibin
    Yes and in J2EE assembling, deploying and migrating is a nightmare even with *experienced* developers
    Cheers
    Ravi
  4. Nightmare?[ Go to top ]

    Yes and in J2EE assembling, deploying and migrating is a nightmare even with *experienced* developersCheersRavi
    I don't know what your definition of a nightmare is, but on every J2EE project I've worked on, I've either setup the tool (WSAD) or written an ant script to handle the assembling of the application. So the assemble, deploy, migrate cycle is pretty much:

    1. Execute ant script or export EAR from tool
    2. Deploy ear to app server (usually either dropping right on top of the existing ear on the file system or using a GUI wizard, depending on the app server)

    That's it. I don't really see what the nightmare is all about. (Environment specific properties and stuff are always just part of the automated build scripts and they go right into the EAR file to be deployed and/or the EAR is configured with an environment identifier to connect to a central properties repository to get any remaining configuration info.)
  5. I broadly agree with the issues raised but then things can always be made better / faster / easier. As with most bloggs this article is just opinion - does anyone have any evidence (even anecdotal) that developer and administration complexity in J2EE has hindered adoption ? This isn't a rhetorical question, I;m actually interested.

    OK, so what if we arrive at a conclusion that complexity is a real problem that must be solved - can it be solved by changing the spec. only - does it just require more mature products or a is it a combination of both ? Maybe it isn't even a problem with the products, maybe it's the lack of support for J2EE by Enterprise Management vendors. It's easy to take an app server-centric view of the world - an app server is just a part of a system and it is the system as a whole that needs managing holistically.

    The blogger trivialized / mis-understands 'management' - it's not just about assembling and deploying applications (in fact I would argue that it is specifically not about assembling applications). Management is about provisioning , monitoring, fault diagnosis, maintaining QOS and availability, managing application lifecycle, security, policy, etc. etc. - most of these things span multiple tiers and technologies (not just the app server) so you can't address these things in the spec. or even in an app server product - not unless you want a 4,000 page spec.

    - Rich
  6. Re: Bulls Eye[ Go to top ]

    Cool, But as far I know and based on feedbacks from my fellow J2EE peers (experienced and Inexperienced), the deployment of J2EE application could be a nightmare espcially working with different app servers. If the same J2EE App needs to be deployed across multiple app servers, the hell taps your front door right there.

    Microsoft, somehow made thier deployment made simple, but still we can see some glitches over there. Since the deployment of .NET is more based on Windows Installer and Visual Stuido .NET, sometime the developer could get the same feeling of j2ee dev scenario.
  7. J2EE Sucks[ Go to top ]

    where ROI and productivity is paramount. Whereas J2EE vendors are targeting just 'developers'. - bibin
    What development shop has anyone been a part of where ROI and productivity is NOT paramount? Geeze...

    The problems J2EE tries to solve are definately the right focus, but the spec and implementation of the spec sucks ass. Microsoft has SUN beat hands down... end of story.

    Thanks to SUNs like of shining on java, I see .NET development in my future. So this is what happens when acedemic nerds are let loose to manage the feature set and marketing of a project. How sad.
  8. .NET Kool-Aid[ Go to top ]

    Let me be the first then to give you some advice when you enter the "working world" of enterprise software development... helping to make the transition from Visio diagramming to "Real World" implementation.

    First, look within your personal network, and see if you know anyone at Intel, because you will need to drink that Kool-Aid, if you haven't already. Make sure that the term, "WinTel" is a part of your vernacular. Reference that term in meetings, it will make you look real smart!!!

    Secondly... make friends with your CFO or Controller, because you will have to account for the costs associated with "Under Delivering" and being "Over Budget". Remember, in the world of Academia it's all about the business case, so budget a lot of time and capital expenditure. The licensing model is completely fair... a blended range of 25K - 50K, and that's just the licensing and "Certification" costs... and it can, and will change as soon as they can figure out a way to put you to the "wall"...

    In closing, good luck with your job search... rest assured that Microsoft Developers have a long shelf life. Once organizations make the investment, you will no doubt become a "piece" of "office furniture".

    And... Hey... Maybe you can answer me this one question that I cannot seem find a straight answer for in my 10+ years of experience... Is Microsoft a marketing company that sells software, or the reverse?

    Good Luck... "Dude" and hey, post back when you land a job, and update me... because I won't be calling on that organization. Thanks!!!!
  9. When it comes to production quality, highly scalable and flexible web applications, J2EE can not be beat! Our .Net folks work on smallish systems for our smaller customers and are on the bench much more often than our J2EE developers, who we can't get enough of! Our J2EE systems are enterprise intranet systems that require reliability, I just don't know that many companies that want to bet the farm on Microsoft based infrastructures.

    We have to literally turn some work away because we can't hire enough J2EE staff. Even our .Net developers are learning J2EE because the .Net work just isn't there.

    I don't know what real world you are a part of, but it is not the planet Earth I live on!

    Perhaps your supposed bad experience with J2EE overruns, and delays says more about your developers abilities than it does about J2EE itself.

    When it comes to security, I trust Sun and J2EE infinitely more than Microsoft...how about you?
  10. J2EE complexity VS cost[ Go to top ]

    Should have had more specific details such as open-source VS limited-access-development of microsoft,

    Balaji .T
  11. I fully agree[ Go to top ]

    I think Sun should begin with getting rid of Entity beans. Hibernate is great but they want to create stupid JDO (are they digging their own grave - and spending lots of money at that too).

    JSP and Servlets are easy and clean. Now JSF is very easy (and Powerful) as well.

    Stateless session beans can be useful but stateful beans (is there a practical real life application?)

    JMS is useful and clean.

    The packaging and deployment parts need to be simplified as well.

    I think Sun is coming up with new things as they need to do something. However they should focus on simplifying the APIs now.
  12. EJB[ Go to top ]

    BMP - EntityBean is fine, but it is applicable in less than 1% cases, the real problem problem is in CMP spec and broad (and failed) attempt to use CPM as persistence implementation.

    There is a desperate need for RDBMS specific OR mappers ( Hibernate etc. ). They should use RDBMS abilities to the fullest extent and not to be handicapped by too much generalization (JDO).
  13. i'm sorry but use entity beans, it's not complicated and so bad... the performance are fine and it's evry easy to manage them.

    So i really have no idea how you can say that... Or your 1% cases is 99% of my company's work :)
  14. Let me clarify: I do not have issues with EntityBeans and tried to say that in 99% cases it is much easier to use good OR mapper like Hibernate than EB.

    For truly distributed applications EJB (well, a predictable life cycle/behavior) is necessary but such application are in minority.
  15. i'm sorry but use entity beans, it's not complicated and so bad... the performance are fine and it's evry easy to manage them.So i really have no idea how you can say that... Or your 1% cases is 99% of my company's work :)
    Hibernate is much easier to learn and to use, much faster and more scalable than Entity Beans, especially if you do a lot of Business Object persistance and queries.
    I don't care that Hibernate is no "standard" as long as it is great, open source, has a great support and as long it is free. Like I and nearly noone else don't care that log4j is no standard. Someone who does not dare, does not win! Such standards like Entity Beans and JDO don't dare much (too generic and limiting solutions) and so that in many cases there is not much to win compared to plain SQL with JDBC. It mostly replaces one complexity with another complexity.

    Bill Burke:
    I don't have hope that a solution in two years (J2EE 1.5) will be better than Hibernate in two years. In two years Hibernate or JDO will be a defacto standard and noone will bother to learn Entity Beans 3.0 which surelely will not be as good as Hibernate and JDO in 2 years.

    And it is really stupid of Sun to put two persistance specifications into the world and maintaining both, keeping them alive: Entity Beans AND JDO. One of them should be deprecated. It is not productive to keep them both.
  16. What you have with ENtity ????[ Go to top ]

    Hibernate is much easier to learn and to use, much faster and more scalable than Entity Beans, especially if you do a lot of Business Object persistance and queries...
    Yes it has flexibility from the optimization point of view. CMP's are working quite well for OLTP scenarios, but for OLAP and queries, Hibernate can probably give better options.

    There are no caching in hibernate arent there? There are also no support for the clustered environments. So, in some cases CMP's will perform better and with less efford. Even so Hibernate is easier to learn, CMP's should be good option in some cases.
  17. There is caching and clustering in Hibernate, of course.

    It would be great if you guys would actually know what OLTP and OLAP before posting comments.
  18. There is caching and clustering in Hibernate, of course.
    Is it actually "and"? The only option I know about is distributed Tangosol cashe on top of Hibernate, but it seems for me that pretty much the same results you can get for regular CMP's running on commercial J2EE container such as Weblogic or Websphere. It will be good exercise to compare performance of some benchmark application built with Hibernate and with CMP's.
    It would be great if you guys would actually know what OLTP and OLAP before posting comments.
    The major difference I meant about changing data (OLAP is red only). So, it is important to have some data for recent transactions in memory and across the cluster.
  19. Eugene: The only option I know about is distributed Tangosol cashe on top of Hibernate, but it seems for me that pretty much the same results you can get for regular CMP's running on commercial J2EE container such as Weblogic or Websphere. It will be good exercise to compare performance of some benchmark application built with Hibernate and with CMP's.

    With Weblogic and WebSphere (and BAS and JBoss and ..), caching is a per-VM thing, with various options to invalidate other VM's caches. The caching is non-transactional, the caches are not shared or otherwise even coordinated.

    Coherence actually uses the entire cluster as a live, coherent, and transactionally coordinated data store, with no single points of failure and no data loss or application interruption when servers fail. For example, a 10-server Coherence cluster can cache 5x the data that a 2-server cluster can cache, so as the cluster grows, the tendency to overload the database will actually diminish, which is the opposite effect as what you see with typical application server approaches. Regarding performance, while I can't name names, Coherence was over 13x as fast as the most recent caching product that we perf-tested against. Regarding scalability, Coherence can scale -- almost linearly -- well into the hundreds of servers. The largest application server clusters that I'm aware of all use Coherence for that very reason.

    Regarding the Hibernate specific questions, Gavin did the initial Coherence integration in about a total of 20 minutes, because the caching plug-in was very basic. Since then, however, he's been extremely busy on some advanced caching options, so I'm sorely out-of-date on my knowledge of what is capable with Hibernate and caching. Hopefully he will chime in on that.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  20. What with entity next :)[ Go to top ]

    First of all.... programming with EJB with XDoclet is as easy as programming with hibernate, so i don't see why shift...

    About the persistance options, i don't really care, i just want to make my Java class and i want something to handle the persistance..

    For me, EJB is easy so use hibernate or JDO to manage ejb entity persistance, i don't really care :) i use entity just because i don't really care about how persistance is done as long as it's easy and it suits with the performance needs i have.

    Besides i hard that entity are always slow.. it's wrong, it depends on server implementation. Not all are good, not all are bad
  21. Partially agree[ Go to top ]

    I think the first Big step to mature the whole J2EE model will involve retiring the existing Servlet request/response model.
    Servlets in a sense act only as an HTTP Adaptor to the whole J2EE technology.It is time we started thinking of some generic model to objectify HTTP Requests that could be easily extendable to Wireless,client-server and other protocols.
    I am surprised that they could not come up with a generic model so far.
  22. Some Complexity is OK[ Go to top ]

    I think some complexity is inevitable (and perhaps welcome) in J2EE as it tries to address inherently complex domain of enterprise applications. Such applications generally tend to orchestrate systems and devices as disparate as Mainframes and ERP systems to simple self-service applications delivered on desktops and pervasive handhelds and all these interlaced with convoluted needs of security, scalability, transactions, fail-over and so on.
    IMHO then, J2EE is quite simple in abstracting such behaviors compared to CORBA/OMG or any such competing platforms. Remember, little complexity also helps developers like me, interested and involved in it and probably justify his/her worth J
  23. Some Complexity is OK[ Go to top ]

    Good article !

    Complexity is good for high paid developers and consultants like us and why worry
  24. Why J2EE is so complex[ Go to top ]

    J2EE is no way simple and it is complex by virtue of it's openness and due to the fact the community is always try to run on the rule of the book and no body cares of what a hapless developer wants! How ever the reality is simple "For J2EE to survive - we have to make it simple to build, deploy and manage"
    Are these the right things to blame ?

    I agree J2EE is indeed complex and we need to make it simple to build, deploy and manage. But I cannot see why "openness or lack of proprietariness" or "portability" are being blamed for it. Yes - the ease of use needs to be improved indeed.

    Community based evolution

    J2EE does indeed attempt to solve a lot of problems at once and also ends up having a lot of toolsets to solve the same or similar problems in different ways (eg. a plethora of OR Mapping or MVC frameworks). Thats simply the nature of the game when a corporate attempts to guide a controlled specification vs a community attempting to guide the growth of a platform based on independent vested interests. I really dont think thats going to change. Community based evolution is indeed a double edged sword - but there indeed are a lot of benefits to it which one shouldnt miss out.

    Eclipse Plugins : A possible solution ?

    I think the best hope is when developers start demanding usability rather than just APIs or RIs. The trend I see is that most new features are likely to be soon supported by usability capabilities such as eclipse based plugins. If we as developers start saying - I shall use hibernate (just as a example) only if accompanied by a good eclipse plugin, I am sure the usability issues will start getting resolved. This I believe is likely to be the best hope (and something I believe has already started happening) which will continue to support a degree of diversity and evolution along with easy usability. That way we can continue to retain the "openness" and "portability" and "diversity" (which the author pans as the reasons for the high complexity) and yet solve the problem (which is easy usability). I am of course sure that this mechanism of evolutionary selection and survival is more wasteful and a little slower than a planned and controlled evolution - but I think we are all better off at the end of the day because of it.

    Dhananjay
  25. I don't get it[ Go to top ]

    I don't get it. This must be the one millionth discussion on why J2EE is complex. It is because it is a lot of other specs some of which have proved useful - Servlets, JMS and some not - Entity Beans. But just because a spec is so complex doesn't mean we have to use each and everything in it. I am willing to bet that most applications could get by just fine with:

    1. Velocity for display _ Clean seperation of Model and View
    2. Struts or Spring etc for the MC in the MVC
    3. Some simple J2EE patterns such as DAO, Business delegate - No prizes for using as many as you can-just some sensible seperations
    4. Hibernate for ORM
    5. If you have a messaging component then use JMS and layer it with some messaging design patterns.

    That's it. Believe me I did more than once and with HA too.

    BTW let's read the Hibernate tutorial before we make comments on what is not available.
  26. Why J2EE is so complex[ Go to top ]

    We are on the EJB 3.0 committee and many of the spec contributors are working hard to get EJBs that are POJO based(all EJB types even Entities), support IoC, and have a rich tag library based on JSR-175. Those three things should simplify development greatly.

    We joined the committee a little late and personally I was impressed that EJB 3.0 truly has a mandate to simplify development. Having lived through the OMG/CORBA days where complexity after complexity was added to the CORBA spec, it was quite refreshing to see that EJB 3.0 was taking a "let's refactor and simplify" approach. It gave me knew hope for EJB.

    Bill
  27. EJB 3[ Go to top ]

    We are on the EJB 3.0 committee and many of the spec contributors are working hard to get EJBs that are POJO based(all EJB types even Entities), support IoC, and have a rich tag library based on JSR-175. Those three things should simplify development greatly.
    So does that mean Entity Beans will be ditched? And what happens to Session Beans, JNDI, EJBQL, ...? The EJB spec needs a complete rewrite. Will you do that? Or is it just some band-aids here and there? I mean, take EJBQL for example. Will you ditch it and produce something as powerful and as useful as HQL?

    On a related note, what happens to JDO? What is the fucking strategy for God's sake?! Is there anybody who actually architects this big J2EE spec? One group builds JDO, another group builds CMP! And heck, JBoss is on both expert groups too!! What's going on here guys?

    Ara.
  28. EJB 3[ Go to top ]

    I consider it completely pointless to produce an EJB 3 spec with POJO-based Entity Beans too. The only sensible thing to do in that respect is to adopt the JDO spec and drop Entity Beans completely. The J2EE world really doesn't need two competing object persistence specs, particularly given the fact that products like Hibernate play such a dominant role, leaving both specs behind in terms of adoption rate.

    Juergen
  29. CORBA got simpler too[ Go to top ]

    They just call it "ICE" ;-) (www.zeroc.com).
  30. Why J2EE is so complex[ Go to top ]

    Management of J2EE application server can now be compared to the mainframe >technologies as still requires manual file editing. Most of the vendors still >lack a good tool to administer application servers. I have not compared the >pages of Application Server Administrator manuals for most of the vendors but >certainly it look more voluminous than the Oracle DBA manual.

    I'd like to know which App servers have been looked at to arrive at the conclusion, and how recently they have been looked at.
  31. Why J2EE is so complex[ Go to top ]

    Now I read that article too.

    One problem I experience in my team are the "productivity-brakes" in many (often senior) developer's heads.

    If I say this or that is too complex, I may be regarded as being too stupid for the task. If I say this is too much work for a normally simple thing, then I may be regarded as being lazy. Often beginners are the first ones to notice the "code smell" of J2EE, which smells like "complexity" and sometimes causes disgust. They have not yet become blind. The ones in the team who are on higher hierarchy positions often defend their J2EE design, framework or tool decisions or the decisions of their bosses. It happens that such people don't like an idea if its not their own idea, sometimes even if it is a really good idea.

    There are some IT bosses who think that it does not matter which programming language, architecture, framework or tool set they order their employees to use. They think that a good programmer will be productive no matter how bad or complex a programming language, architecture, framework or tool set is. Its like a farm laborer is plowing with a horse instead with a tractor. The lord does not give him a tractor but sugar and a whip for the (dead) horse. The lord is the IT boss, the farm laborer is the developer and the dead horse is the programming language, architecture, framework or tool set.

    Maybe I exaggerated a little bit. But I tried to explain what I mean in an effective way.

    We all should be brave and fight against unproductivity. By this we eventually will succeed in getting more productive technologies, tools, development processes or whatever. And I think it will save us quite a bit from off-shoring our jobs.
  32. Why J2EE is so complex[ Go to top ]

    There might be a good reason for “complexity” and greenhorns are just not aware of those reasons and too lazy to investigate.
    About EJB – when I encountered EJB after working with CORBA for a while I was surprised by unnecessary complexity of dealing with EJB.

    Might be it is time to admit that CORBA has far superior architecture and start using it?
  33. Why J2EE is so complex[ Go to top ]

    Its like the discussion why all the evil exists in the world if there is a good god. How can he all let such cruel things happen? Why don't we live in paradise? So some people don't believe in god because of this contradiction (good god - bad world which he created). This is the theodizee problem. The philosopher Leibniz tried to solve it by claiming that god created the best of all possible worlds. Its up to you to believe that or not. I don't. And I don't believe that J2EE is the easiest architecture of all possible architectures in the problem domain. Its in my eyes by far not the easiest. I hate Microsoft. But in one point they are very good: They know how to make things very easy.
  34. Why J2EE is so complex[ Go to top ]

    I hate Microsoft. But in one point they are very good: They know how to make things very easy.

    Somebody said: MS does simple things simpler and complex things even more complex( next to impossible ).

    >> And I don't believe that J2EE is the easiest architecture of all possible architectures in the problem domain.

    Neither do I. But there are reasons behind J2EE APIs and complexities.
    Before dismissing any complex thing on the ground of its complexity alone I beg you to try to understand why it was done in such way.

    There might be several outcomes:
    - the same goal can be achieved simpler;
    - there is no need to achieve that goal, so another solution might be applied;
    - magically that complexity becomes simplicity;
    - someone realizes a need for a tool to deal with some issues;
  35. Why J2EE is so complex[ Go to top ]

    Thanks for all the feedback on the article. Most of us echo that there are too much complexity in J2EE and these needs to be addressed going forward. There is no doubt that J2EE is definitely a far better technology than .Net and that J2EE is portable and scalable. We have too much option for everything from platforms, frameworks, persistence options and options are definitely better than having just one .Net. I love all the great technology the J2EE vendors and open source community produce. Every technology has it's in its own domain. However this appears too much to a new developer and hopefully ease of development, assembly, etc. will be addressed by J2EE 1.5 and further ..
  36. Why J2EE is so complex[ Go to top ]

    Somebody said: MS does simple things simpler and complex things even more complex( next to impossible ).
    Interesting, what complex J2EE things get "next to impossible" with .NET? (aside from running in multiple OS's of course, that's an obvious +1 for Java)
  37. Why J2EE is so complex[ Go to top ]

    Somebody said: MS does simple things simpler and complex things even more complex( next to impossible ).
    Interesting, what complex J2EE things get "next to impossible" with .NET? (aside from running in multiple OS's of course, that's an obvious +1 for Java)
    I did not talk about .NET, but about MS ideology and technologies in general.

    Impossibility example: have you ever heard of a supercomputer cluster built on MS technologies?
  38. Yes Virginia,

    There is such a thing.

    Windows High Performance Computing"
  39. Why J2EE is so complex[ Go to top ]

    Impossibility example: have you ever heard of a supercomputer cluster built on MS technologies?
    TerraServer is a commercial supercluster based on Microsoft technologies. And it was built back in 1998.
  40. Why J2EE is so complex[ Go to top ]

    ...not the easiest. I hate Microsoft. But in ...
    Funny, I used to "hate" Microsoft having suffered their "personal productivity tools" for too many years; having dropped that burden I'm, a little more objective and now I'm just suspicious of everything they do or say.

    - Rich
  41. J2EE is indeed very complex,too many components/packages/ways/specs... in the
     system ,making the developer confuse and deal with too low level issues.

     As well the entire enviroment ,AppServer,IDE ... are lacking efficient tools
     making the developer life simpler.

     Personally , before my current j2ee\EJB job , i worked in developing a Java
     Server with xml sent between client and server , and i miss it: no AppServer
     on the head, no complex build,no complex deployment,no complex testing,no
     hard to test ... , and very simple and fast to develope!
  42. As well the entire enviroment ,AppServer,IDE ... are lacking efficient tools making the developer life simpler.

    Provided that a developer knows what he/she is trying to accomplish XDoclet provides greatest help possible.

    >> Java Server with xml sent between client and server , and i miss it:

    How is that simpler/better than RMI, Hessian or Burlap protocols?
  43. 1. CMR - Tools to auto identify foreign key relation ship relationships within the database, and generate CMR- entries for me. Including one-to-many , cascade rules etc.

    2. EJB-QL - Make it more like if not exact, to SQL. Especially the join syntax. As SQL is already portable between databases, why reinvent the wheel. Let the container provider convert the 'SELECT * FROM Tab where col1 = ?" to "SELECT OBJECT(p) from tab p where col1 = ?".

    3. Ability to link the stored procedures already implemented inside database for ejbFinders and ejbSelects, almost all databases allow returning result sets.

    4. Options to link the primary keys with the auto generated sequences inside the databases, so that we automatically get their values in ejbPostCreate().

    5. I could not find any examples in EJB books, about persisting newer data types within databases like CLOB, BLOB, XMLcolumn, XMLCollection etc, from CMP so far. These can also be built inside EJB 3.0.
  44. Why don't we try to simplify it?

    Methodologies, development approaches:
    If I recall correctly, a few methodologies and practices have been trying it for some time: eXtreme Programming, Agile Programming, design patterns.

    Application servers:
    I find Orion application server to be aimed precisely at simplification of needless complexity in the area of J2EE services. No heavy-weight admin GUIs, but rather a clean set of config files that are clearly documented and allow you to fully control the application server and deployment with ease.

    Development tools:
    I find two tools that really help to deal with increased complexity:
    (1) Ant - because it still does a good job;
    (2) Intellij IDEA really stands out from other IDEs because it makes java development so efficient with its extensive refactong support.

    Libraries:
    Difficult to suggest anything here because it depends on your project requirements. But if you have any JDBC code, please replace it with iBATIS and you will never regret it. However, deciding if and how the ORM frameworks, EJBs and other persistance solutions are applicable to your given scenario is still a challenge.

    YMMV
    Valeri
  45. Why J2EE is so Complex[ Go to top ]

    Hi all

       J2ee as i see is more of specifed by a party and implemented by a party and developers hang between the vendor and specifiers. where as in case of .NET everythings converges to one party i.e Microsoft.

       I mean infrastucture remains same and from one vendor in .NET. Where as J2EE tries very generic.

       At last i would see j2ee as simple as that when tools exists.
       and its time for those tools to popup as the specification has provided generic infrastructure Like JMX, XML based and other things.

       Mouse based programming is that people want while at the end developer wants to think more than doing things around IDE.
    suriyanarayanan
  46. J2EE and context[ Go to top ]

    IMHO, nobody can't speak about the so called "J2EE complexity" without taking into account the application context. What does "application context" mean ? In fact, before making any tool / technology choices, you have to answer such questions as :

    * is my app a strategic app ? or a more tactical one ?

    * is my app a simple app from an architectural point of view ?

    * is my app a "big one" involving many designers / developpers / testers ?

    Saying "J2EE is overly complex" is meaningless as long as you have no anwser to these questions.

    So, if your application is a simple, not-so-strategic one, yes, at the moment, Visual Studio and .Net could be a better answser than J2EE. This is the very reason why Java Server Faces is a key technology : with JSF, editors and open source team can build wysiwig, "Visual studio killer" ( ;-) ), tools, making very simple "simple app" development.

    But if your application is complex (e.g. it needs to access mainframe and ERP data, it needs to display result through a portal infrastructure, it needs to support B2B exchange via Web services, it needs i18n, logging, security, asynchronous messaging...), then J2EE could be seen as not so complex.

    That is not to say that J2EE is the holy grail of developper and architect. By the way, during 20 years or so, I saw so many "holy grails" : Ada, Lisp / Prolog / Rules engines, Smalltalk / C++ and object oriented architecture (MVC), Corba and distributed architecture, Meta Object Protocol, etc etc
    And now, SOAP/XML and Services Oriented Architecture, Aspect and Aspect Oriented Architecture...What's next ?

    To conclude : in 2004, for many applications (but not all), J2EE as a framework backbone fit the bill quite well. You can't expect programming mainframe-class applications with toys. And after all, the market has adopted J2EE.

    But the java community must improve the tool box : more wysiwig editors (when will Hibernate team release an Eclipse-based, graphical tool ???), more MDA-driven code generator, etc.
  47. Pascal: "So, if your application is a simple, not-so-strategic one, yes, at the moment, Visual Studio and .Net could be a better answser than J2EE. This is the very reason why Java Server Faces is a key technology: with JSF, editors and open source team can build wysiwig, "Visual studio killer" ( ;-) ), tools, making very simple "simple app" development."

    Why wait for "wysiwig" technology when Tomcat/Resin + Spring (with declarative transactions if you need), Webwork or Tapestry in a well though out MCV architecture + with Coherence for cluster/caching beats the hell out of anything that Microsoft has at this time? You even have "Hot Deploy" don’t you?

    So what is the problem? Please explain.

    Regards
    Rolf Tollerud
  48. Why J2EE is so complex[ Go to top ]

    Sometimes its like cooking a good meal. You can use the best ingredients and still the cooking result can be terrible. A little bit too much salt can ruin everything.

    Cola: tastes good. Ketchup: tastes good. Cola & Ketchup mixed: terrible! Or sugar and steak!

    Success and productivity in the IT world is a mixture of good and suitable "ingredients". If you need energy for jogging, eating a steak for that purpose is definitely no good idea. So if you don't really need J2EE for your application, don't use it!

    I think that often J2EE is used because the requirements are unclear. Its like a making a big buffet for few persons. Most of the meal is wasted then. Better ask how many will come before you make a big buffet. Realising the requirements is very important in the IT world. Or do you want a egg producing wool-milk-pig?

    Using J2EE can mean using a lot of different ingredients: application servers, IDEs, frameworks, libraries, ORMs, GUI-Layers, development processes, testing and quality ensuring tools and processes, training and qualification of programmers, team structure. Even if every single ingredient is good, the mixture can be bad, like mixing Cola and Ketchup.

    This is a very general statement, but I think it should be considered.

    So if you count wrong, it does not mean math is a bad thing. But this argument may not be used to stay blind in front of things which can be made easier.

    A good example how things can be made easy is the TableLayout. It is much easier to use and understand and yet it can do more than the GridBagLayout. Its no J2EE example. But I think that the same improvement can be achieved in some areas.

    In the J2EE world choosing a good mixture of ingredients is more important than in the Microsoft world, where you get a tool set which is foolproof.
  49. What is an application?[ Go to top ]

    I wonder if some of the complexities of J2EE application servers have to do with the very concept of "application". An application traditionally has been something that is written and compiled by developers, deployed by administrators or users, started, used and shut down. But is this the right model for server side functionality? I mean DBMSs, for example, don't have this concept. There is no deployment and no startup, it's just always there, up and running and you can make changes to it via SQL scripts. If you have certain units of deployment and testing and a formal process for doing all of this, it's because you decide to have it for your own particular organisational reasons, not because the technology actually forces you to do it like this. Imagine you'd have to put the code of a stored procedure into a carefully designed compile time directory structure, take the whole database down, compile everything so that it creates a carefully designed runtime directory structure (which is partly vendor specific) and start it up again.

    The concept of discrete applications becomes particularly absurd when you think about web sites. I wonder who had the idea of placing the documents that are published on a web site inside a .war file that can only be modified by taking the whole web site down. Of course we can use "exploded" directories instead of .wars but did you all know that this is not standardised at all? It is not part of J2EE and all appservers do it slightly differently.

    It's really amazing when you think about what you cannot do without taking the application down if you want to stay within the confines of the standard: You cannot add pages to a web site. You cannot add database connections, or JMS connections or any kind of resource connection for that matter. You cannot add references to EJBs. You cannot change any of the environment entries in the deployment descriptors. You cannot add or remove security roles or security constraints. Of course you cannot add any kind of code nor can you add libraries. Why do JSP pages dynamically pick up changes when they are supposed to be in a .war that cannot be changed dynamicall? If you use any kind of OR mapping, you cannot change your schema and make the changes available to the application.

    I find myself constantly working around everything that could be conveniently declared in deployment descriptors simply because I cannot take a server application down for each and every modification. And it's not just about modifications that are development tasks, it's also about administration and configuration tasks that are done by admins or even end users on a regular basis. I wonder what kind of development deployment cycle the creators of this architecture were thinking of.

    I want vendor independent APIs for everything that goes in the deployment descriptors today and I want to be able to modify everything at runtime. We were all complaining about having to restart Windows servers on every occasion, we ridiculed Microsoft for it claiming they didn't understand server side enterprise necessities. Now we have server side applications that behave like 1992 desktop applications.
  50. IMO, it must be the 3 very small but difficult to pronounce words:

    "I was wrong" (about J2EE)

    Regards
    Rolf Tollerud
  51. no wait, I found it out myself[ Go to top ]

    Rolf: "I was wrong" (about J2EE)

    Yes, we've been telling you that all along ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  52. who was it?[ Go to top ]

    who was it that said "I was wrong? about J2EE"

    Well, one thing is at absolutly certain, 100% percent secure,
    and cast in stone.

    It was not Cameron!

    :))

    Regards
    Rolf Tollerud
  53. Well... Yes, but No[ Go to top ]

    Although I agree that J2EE community could do better with tools that could make the life easier for us all. We all would also love to improve the APIs, get better in terms of performance, flexible designs, efficient development process, ... the list goes on.

    But Java/J2EE have evolved for a reason. If it was only the ease of development that was required VB/Oracle Dev2k would have been still the lords of the "ring".

    J2EE should improve and I hope it does. One thing for sure, articles like this keep should only help us get better but not lose the original objectives.
  54. Just throwing this out there since the topic is simplification. What if all those Application server Specific xml files were all the same across application servers. CS always loves another layer of abstraction, so
    why not let the Application server specific stuff stay with
    the application server and out of the ear file.

    1. I would be able to deploy my application to any J2EE server without re-assembling, and learning another IDE or assembly tool. I would'nt have to configure datasources,
    JMS, etc. on every App server with some very drastic differences in how this happens.

    So it would be write once, assemble once, run everywhere.

    I personally think J2EE is so complex because that it is presented that way. It takes you 3 years to learn that all
    you need is 3 or 4 patterns, a service layer and domain layer, some packaging that supports this, Ant, and you can have isolated enterprise business logic that supports many types of clients, not just http clients. In short, the vendor wars and hard economy have been a detriment to the
    unvieling of this simplicity.

    J2EE simplicity has a "scope" problem. Believe it or not some folks want a 3 tier J2EE architecture, and view it as modern solution to the earlier traditional 3 tier architectures. Yet forums on that topic are swamped and diluted with 2 tier special interest. I have trouble believing that no one wants threads/concurrency, transactions and persistence managed for them in a scalable,
    "simple", worry free programming environement. Yes, believe or not, it's the EJB container, which I now call Enterprise container because EJB spooks people