Norman Richards on revision of history and J2EE

Discussions

News: Norman Richards on revision of history and J2EE

  1. Norman Richardson has posted "Java revisionism and the failed J2EE project," a blog post talking about how people tend to blame J2EE for project failures or clumsiness, and says that "Better technology cannot turn a failed project into a successful one." It's the people, not the technology.
    Yes, J2EE is bulky and awkward in comparison to EJB3 and other lighter technologies, but that doesn't mean that it was impossible to deliver functional systems on. It was quite easy to do, even with very average development teams. So, why then do we read time and time again about failed J2EE systems? Sure, many projects don't succeed, but in my experience it is rarely the technology chosen. I'd postulate that if you took a team with a failed J2EE project and swapped in another technology, that the team would most likely still produce a failed project. Better technology cannot turn a failed project into a successful one. At the same time, technology is important. I strongly believe that if you took a team that developed a successful J2EE project and gave them more modern technologies, that they would be equally successful. They would be able to do the same project faster than before, and they would be happier doing it. Clearly technology chosen is a big deal, and you want your team to be using the best tools possible. It will make a difference. Just don't expect those technologies to compensate for a bad process, bad management or (dare I say) bad programmers. As a final note, I'll concede that some technologies are so bad that I can't imagine any team being successful with them. My point isn't that all technologies are good, but simply that Java developers as a whole are all too eager to pretend like everything old is in that category and absolve ourselves from the guilt of past failures.

    Threaded Messages (25)

  2. I think that good technology is a necessary, but not sufficient, condition for a successful project.
  3. I agree to a certain extent. It is interesting to me that you have suggested that a team that failed with a J2EE project would probably fail will lighter technologies, and that a team that developed a successful J2EE project would probably be successful with lighter technologies but you haven't explored the more interesting question... would a team that delivered a successful project using lightweight technologies be significantly more likely to fail using J2EE? Of course the answer will depend on the members of the team, but J2EE raises the skills bar significantly in my opinion. There is simply much more to be aware of. Of course, it is easier, politically, to blame the technology. Most developers with any level of experience will understand that there is far more too success and failure than this. Often, the fate of the project is decided in the first few weeks (usually at the point the project managers and the client agree that a detailed specification isn't required... we are all friends here after all!?). J2EE make it difficult to deal with change and most projects are not managed well enough so that change is kept to a minimum. It is this mismatch that will kill projects. If a requirement hits my desk that requires a change in the concurrency model (have it done by the end of the day!) and the platform is based on something like Spring, I can probably make it happen. If it is a full J2EE stack... forget it.
  4. J2EE/JavaEE easier than Spring[ Go to top ]

    In my opinion it is not good to have a general opinion if J2EE or JavaEE is heavyweightier than Spring or vice versa. I would say that both technologies have their advantages and disadvantages. A good architect should be open to all technologies and should choose the best one to solve a certain problem! Another thing I'd like to mention is, that I've developed a lot of J2EE projects over the past years. All have been successful (in the end). Recently I started using the Spring framework and I must say that I found the learning curve quite high. It took me a lot of resources to understand the principles, basics and what is going on behind the scenes. I cannot say that Spring is more difficult or easier to learn compared to J2EE. Personally I feel very comfortable with JavaEE 5 and EJB3 and would prefer it over Spring where both technologies could be used.
  5. Re: J2EE/JavaEE easier than Spring[ Go to top ]

    In my opinion it is not good to have a general opinion if J2EE or JavaEE is heavyweightier than Spring or vice versa.
    Ugh... for the nth time, Spring is not a wholesale alternative or competitor to J2EE. Much of Spring is built on top of J2EE APIs. The main overlap between the two is that several years ago, Spring started offering a programming model different from the EJB2 programming model. But at the same time, the Spring folks pointed out that EJB2 provides features (failover, remoting, etc.) that Spring doesn't try to provide, and thus it's perfectly reasonable to use the two together.
  6. Re: J2EE/JavaEE easier than Spring[ Go to top ]

    In my opinion it is not good to have a general opinion if J2EE or JavaEE is heavyweightier than Spring or vice versa. I would say that both technologies have their advantages and disadvantages. A good architect should be open to all technologies and should choose the best one to solve a certain problem!
    Another thing I'd like to mention is, that I've developed a lot of J2EE projects over the past years. All have been successful (in the end).
    Recently I started using the Spring framework and I must say that I found the learning curve quite high. It took me a lot of resources to understand the principles, basics and what is going on behind the scenes. I cannot say that Spring is more difficult or easier to learn compared to J2EE. Personally I feel very comfortable with JavaEE 5 and EJB3 and would prefer it over Spring where both technologies could be used.
    My experience has been the opposite. We've had a lot of success getting fairly junior people ramped up on Spring because it was so non-intrusive. The difference in complexity between our Struts/Spring/Hibernate and Struts/EJB apps is significant. The people who've worked on both have commented as much. Everything is a pojo. That's it. That's Spring at is essence. When I first used it, it was with the intention to replace our custom factories. This was so easy, I looked at the AOP stuff. However, I'd already had my own Dynamic proxies in place. It took me 8 hours to port my dynamic proxies over to Spring's AOP support(which was far more powerful). However, I was already comformatable with the concepts *before* even trying Spring. But if one is not comfortable with the concepts, then any tool will be difficult.
  7. Re: J2EE/JavaEE easier than Spring[ Go to top ]

    My experience has been the opposite. We've had a lot of success getting fairly junior people ramped up on Spring because it was so non-intrusive.
    Absolutely. Also, the nice thing is that with Spring 'style' POJO coding it is far easier to a give a more junior team member a task without them needing to be an expert in the underlying technology. To write a session bean to perform a specific function the developer has to understand some fairly detailed information about the container contract. Not so with Spring. I find that working with pure J2EE is there is scaling up of skills, its basically all or nothing. If you can lower the skills bar then you can bring more developers onto the team so more man hours go into the project. Everything is loosly coupled so any buggy or obsolute components can be easily replaced without affecting the rest of the design and everyone gets to develop in a style that they are used to, where implementations declare their interfaces, data and logic belong together etc...
  8. Also, the nice thing is that with Spring 'style' POJO coding it is far easier to a give a more junior team member a task without them needing to be an expert in the underlying technology. To write a session bean to perform a specific function the developer has to understand some fairly detailed information about the container contract. Not so with Spring.
    I agree to some extent. First, if the system under development is not a trivial application, you'll need more experienced developers, no matter you're using Spring. Advanced transaction support, or instrumentation require the team to grasp the most important concepts, and Spring provides support for them mostly in the presence of the underlying J2EE API. Second, it's true the team doesn't have to understand the container contract, but instead have to understand the session factory contract, a simpler one I concede, but nevertheless another contract. What I'm trying to fight here is the notion prevalent in some teams that just by using Spring is possible: 1) to deliver solutions without having a fair command of the underlying technology, 2) to take a bunch of juniors and produce a complex solution, 3) it is not necessary to have someone in the team knowledgeable on J2EE. Javier
  9. Also, the nice thing is that with Spring 'style' POJO coding it is far easier to a give a more junior team member a task without them needing to be an expert in the underlying technology. To write a session bean to perform a specific function the developer has to understand some fairly detailed information about the container contract. Not so with Spring.


    I agree to some extent. First, if the system under development is not a trivial application, you'll need more experienced developers, no matter you're using Spring. Advanced transaction support, or instrumentation require the team to grasp the most important concepts, and Spring provides support for them mostly in the presence of the underlying J2EE API.

    Second, it's true the team doesn't have to understand the container contract, but instead have to understand the session factory contract, a simpler one I concede, but nevertheless another contract.

    What I'm trying to fight here is the notion prevalent in some teams that just by using Spring is possible: 1) to deliver solutions without having a fair command of the underlying technology, 2) to take a bunch of juniors and produce a complex solution, 3) it is not necessary to have someone in the team knowledgeable on J2EE.


    Javier
    I don't think anyone is saying that. However, with Spring, at least for us, we are able to get our guys doing some fairly complex and solid work beyond their years. Again, the solution is not for everyone, but we've had quite a bit of success. I told a friend about Spring when she was starting a new project. I suggested that she use Spring(they were also going to use Hibernate). She is very happy with the move. "Everytime we want to incorporate something, we do a google search for Spring integration and pow! There it is!" Her words.
  10. I agree. Not without a high load of irony, I show the J2EE and Spring javadocs to someone and then ask "What is the API that is supposed to be lightweight" ;-) Currently I'm pushing to develop a transactional application using J2EE but without the container, and I'm advocating to use the fine Spring provided libraries that wrap important J2EE APIs like JTA, JMS and JMX. The bulk load is still in J2EE, and Spring is a handy support library. Javier
  11. The bulk load is still in J2EE, and Spring is a handy support library.


    Javier
    Not necessarily. You can easily use non standard open source solutions instead of J2EE such as Hibernate, JDO for persistance, Burlan and Hessian for remote communication, ... Spring supports most of the major players out there in any fields and let you choose which one you want to use, not only the standard J2EE containers APIs.
  12. Not necessarily. You can easily use non standard open source solutions instead of J2EE such as Hibernate, JDO for persistance, Burlan and Hessian for remote communication, ... I see you point. Both Burlap and Hessian are very good alternatives to IIOP/SOAP, the protocols prescribed by J2EE. I'd just like to point out that Hibernate recommends the use of JTA for transaction management, unless you fallback to JDBC transactions, both part of the J2EE stack. So let me rephrase: it's not unusual that in several cases, the bulk load is still on the underlying J2EE APIs/services. To me that's not a bad thing, nor something in detriment of Spring. Besides I'm not aware of mature and proved alternatives to JMS, JTA or JMX, in part because I'm comfortable with them and the ability to use them from Spring, and don't plan to fight them just because they are "J2EE" ;-) Javier
  13. Not necessarily. You can easily use non standard open source solutions instead of J2EE such as Hibernate, JDO for persistance, Burlan and Hessian for remote communication, ...



    I see you point. Both Burlap and Hessian are very good alternatives to IIOP/SOAP, the protocols prescribed by J2EE.

    I'd just like to point out that Hibernate recommends the use of JTA for transaction management, unless you fallback to JDBC transactions, both part of the J2EE stack.

    So let me rephrase: it's not unusual that in several cases, the bulk load is still on the underlying J2EE APIs/services. To me that's not a bad thing, nor something in detriment of Spring.

    Besides I'm not aware of mature and proved alternatives to JMS, JTA or JMX, in part because I'm comfortable with them and the ability to use them from Spring, and don't plan to fight them just because they are "J2EE" ;-)



    Javier Ok now I agree with you. I just wanted to show that one of Spring main feature is integrating different technologies container based or not by offering the same programming model.
  14. I agree. Not without a high load of irony, I show the J2EE and Spring javadocs to someone and then ask "What is the API that is supposed to be lightweight"
    Well, the term "lightweight" gets thrown around to mean many different things, and I'd argue that you're using it in the wrong context. I believe the original intent of the term "lightweight" in conjunction with "container" was to imply that an object within the container did not have any explicit knowledge of the container. Thus, EJB2 was considered "heavyweight" because objects had explicit knowledge of container interfaces. So true, the entire Spring API would not be considered "lightweight" - but I don't believe this has ever been claimed (and nor would a product that tries to provide many features probably claim that its feature count is "lightweight").
  15. So true, the entire Spring API would not be considered "lightweight" - but I don't believe this has ever been claimed (and nor would a product that tries to provide many features probably claim that its feature count is "lightweight").
    What I've seen being claimed is that J2EE has an almost unsurmountable learning curve, and people pretending there is no such curve in Spring. Some APIs are complex because the kind of problems they try to solve are complex, and Spring makes them easier to use, but the application designer still has to be aware of the fundamentals, freeing perhaps the rest of the team for this task/knowledge. Cheers Javier
  16. So true, the entire Spring API would not be considered "lightweight" - but I don't believe this has ever been claimed (and nor would a product that tries to provide many features probably claim that its feature count is "lightweight").


    What I've seen being claimed is that J2EE has an almost unsurmountable learning curve, and people pretending there is no such curve in Spring.

    Some APIs are complex because the kind of problems they try to solve are complex, and Spring makes them easier to use, but the application designer still has to be aware of the fundamentals, freeing perhaps the rest of the team for this task/knowledge.

    Cheers

    Javier
    I think what people, certainly myself is saying is that the the Spring learning curve is shallow, at least for me. I had already written my own dynamic proxies so the AOP stuff seemed straighforward. Spring's AOP only took me a day to change over. I've got junior guys able to use Spring AOP, Spring Quartz integration, Spring Transaction support, and Spring OSCache support implement some interesting solutions that please our customers. The resulting code is modular, clean, and decoupled. Try having junior guys doing the same with EJB2 and straight J2EE APIs. The Spring approach, IMO, is validated by things like EJB3 and Guice. There is a reason, IMO, that things like Spring layer J2EE and not the reverse.
  17. I had already written my own dynamic proxies so the AOP stuff seemed straighforward. Spring's AOP only took me a day to change over.

    I've got junior guys able to use Spring AOP, Spring Quartz integration, Spring Transaction support, and Spring OSCache support implement some interesting solutions that please our customers.
    Hi, I'm not suggesting that developing with raw J2EE is as clean and simple as with Spring. What I'm saying is there is no case in blindly see J2EE as bad thing, as if J2EE == EJB (not that you suggested that). Currently I'm in the position to introduce JMS, JMX and JTA through Spring, in order to have a nice and consistent programming model for our next application, and trying to play the role you successfully played with your juniors. How much time will pass before people start bashing Spring as now J2EE and Struts are bashed? ;-) Cheers Javier
  18. In my opinion i don't think it's a problem with the J2EE technology stack. Projects shouldn't be governed by technology but by requirements and whether a piece of technology can furfill that requirement. To me the important factor of successful projects are developers and architects. A majority of J2EE projects fail because of architects and senior developers who think they know everything and aren't willing to admit to a wrong decision when it comes to application design. I have seen projects where architects have said "we shall do this and this is final" and result outcome...well you know the rest. I'm not saying lets get rid of architects and senior develpers (i'm hoping to become an architect one day!), but what i am saying is that these people need to understand that there are talented minds out there and they should listen to them and take on board their ideas. One thing i would also like to mention is that EJBs != the whole of J2EE. EJBs is a subset of the J2EE technology stack and there are some really cool features of the J2EE stack. So lets not start bashing J2EE or JavaEE. As for Spring vs JavaEE or EJBs...well we've pretty much had this discussion a thousand times. So i'll let someone else do that.
  19. I agree with Amin Mohammed-Coleman. As we are Java developer/architect, sometimes we sell wrong information. We say that Java does that, Java does this, we have J2EE that do that… but in the end simpler solution could have better result. I saw a lot of projects using JBoss and the latest J2EE technologies but in the end a simple Tomcat (Struts) with hibernate could fit in the project. Result: less hours of development, team with less acknowledgment(cheaper), less test hours, less integration/deploy hours would be used. I think there is a big lack in J2EE in the market. J2EE is not just an EJB deployed using Xdoclet and Ant.
  20. I had already written my own dynamic proxies so the AOP stuff seemed straighforward. Spring's AOP only took me a day to change over.

    I've got junior guys able to use Spring AOP, Spring Quartz integration, Spring Transaction support, and Spring OSCache support implement some interesting solutions that please our customers.


    Hi,

    I'm not suggesting that developing with raw J2EE is as clean and simple as with Spring. What I'm saying is there is no case in blindly see J2EE as bad thing, as if J2EE == EJB (not that you suggested that).

    Currently I'm in the position to introduce JMS, JMX and JTA through Spring, in order to have a nice and consistent programming model for our next application, and trying to play the role you successfully played with your juniors.

    How much time will pass before people start bashing Spring as now J2EE and Struts are bashed? ;-)


    Cheers


    Javier
    Agreed. We are all mercernaries loyal only to the next item that puts money in our pockets. I still have a soft spot for Struts and actually only this year are we making the transition off of it. I don't think people are bashing J2EE, though. After all, Spring just wraps most of those services and those services are awesome.
  21. would a team that delivered a successful project using lightweight technologies be significantly more likely to fail using J2EE?
    No, I don't think they would be more likely to fail if they had used J2EE instead. Certainly I can conceive of a team that is just talented enough to do one, but not to do the other, but I sincerely doubt this represents any significant percentage of teams.
  22. the shit especially hits the fan when J2ee is used in combination with certain "tools" of certain vendors that are opposed on developers by certain customers , working with that combo raises my blood pressure to levels formerly unknown to mankind, I seem to have recovered from it since the last time but when I even think of it my head starts to pulsate again.
  23. IMHO the issues facing J2EE projects is scale and responsiveness. More specifically J2EE projects require a larger infrastructure in terms of people and knowledge. Compared to competing technologies eg. .Net, Spring perhaps (POJO land) it is lumbering. This means that you need more people and the turnaround time for changes is much higher (try turning around the Titanic in a tight space). As a result time becomes a large factor and corners are cut (in good design and common sense) which ultimately cause trouble down the road. Furthermore by requiring more people you end up with the age old problem of communication. Almost as if by a natural law, the more people added the worse communication gets and the likelihood of success (measured by cost, quality and timeliness) is reduced.
  24. A positive J2EE experience[ Go to top ]

    In this article I relate a positive enterprise development experience using J2EE - but probably not quite along the lines that folks might be expecting: Building Effective Enterprise Distributed Software Systems
  25. EJBs were probably not ill conceived (though I gave them a wide berth) though they were conceived in a time before mature transparent persistence via ORM (JDO/Hibernate) was commonplace. I can imagine that a team of intelligent people would be totally demotivated these days if they were assigned an EJB2 project. It only takes one person on the team to know anything about JDO or Hibernate and the POJO revolution and the thought of doing things the EJB way would be so demoralizing to almost guarantee failure of the EJB project.
  26. EJBs were probably not ill conceived (though I gave them a wide berth) though they were conceived in a time before mature transparent persistence via ORM (JDO/Hibernate) was commonplace.
    The idea of an app server having containers providing access to common and imminently useful middle-tier services is not flawed. Both J2EE app servers and Spring do that. The difference is how they do it. J2EE does so through fully explicit API conventions for binding in EJBs. Spring does it via dependency injection and POJOs. Boils down to ultra tight coupling vs. very loose coupling approach. Is not surprising that the loose coupling of Spring emerges as the much superior way to go. (Of course am glossing over fact that Spring is not the full provider of these common middle-tier services, ala J2EE app servers - which by specification are required to provide all such services.)
    I can imagine that a team of intelligent people would be totally demotivated these days if they were assigned an EJB2 project. It only takes one person on the team to know anything about JDO or Hibernate and the POJO revolution and the thought of doing things the EJB way would be so demoralizing to almost guarantee failure of the EJB project.
    Yeah, I suppose the discussion of the merits of JEE should now be shifted to focus on EJB3/JEE5. Yet the old EJB2/J2EE app servers coupled to Spring/Hibernate/iBatis still can make for a potent combination. All those useful JEE services are there but can be utilized in a low-coupling manner. Admittedly I never made use of EJB2 entity beans or session beans. Yet the MDB has been entirely fine. These days we just derive them from Spring's abstract base class for MDBs and then implement them using POJOs. Good stuff - unit testing the POJOs being straightforward. My take is essentially that in distributed computing remoted interfaces of distributed objects (session beans) is a very bad concept to begin with. Distributed computing interactions should be via asynchronous messaging instead. So J2EE/Spring/Hibernate are doing the job adequately. The only thing I want to do now is dump XML as used for Spring config and use Groovy XML markup in its place.