Discussions

News: Debu Panda: "Is Java EE 5.0 really simplifying development?"

  1. Debu Panda, in "Is Java EE 5.0 really simplifying development?," says that while EJB 3.0 has made great strides in simplifying development, client use of EJBs and of web services are lagging behind.
    While migrating the Java Adventure Builder to use EJB 3.0 and WS Metadata, I realized that invoking and using web services in J2EE applications is very complex and error prone and needs to be simplified. I could not find anything being done in that area at least looking at the Java EE 5.0 draft specification. There are even metadata annotations missing for the service-ref element to inject dependency on web services. To make SOA story compelling with the Java EE platform, use of services should be made simpler from Java EE clients.

    What do you think?

    Threaded Messages (39)

  2. There are many things in j2ee5 (yeah, I know, Java EE 5.0) that will make development easier.

    One of the compelling features that is still, imho, a bit immature from the community support perspective is JSF. Finally, J2EE will have a standardized UI framework that I hope will take off and get massive community support. The changes to EJB 3.0 sound like they are for the most part, a copy 'n' paste job from the excellent work of the Hibernate team.

    In the projects I am working on, we are making excellent use of Apache AXIS (fantastic WS implementation) for both clients and servers. For the RDBMS DAO layers, we are finding Hibernate to be great.

    Your complaints seem to be that EJB 3.0 isn't up to spec. When was EJB ever up to spec? Seriously - WS has been a far better distributed RMI / message mechanism than EJB 3.0 ever was (misused as such, but that's how many .coms used it).
  3. "The changes to EJB 3.0 sound like they are for the most part, a copy 'n' paste job from the excellent work of the Hibernate team."

    >> That's not true. I think most members of EJB 3.0 expert group will be offended if you state EJB 3.0 to be a cut 'n' paste of Hibernate. I think you have seen this blog http://www.jroller.com/comments/mkeith/Weblog/the_ejb_3_0_hibernate.

    "Your complaints seem to be that EJB 3.0 isn't up to spec. When was EJB ever up to spec?"

    Nope, my complaint is not EJB 3.0 spec but propagating the good work done by EJB 3.0 spec to other areas of J2EE i.e. making use of EJBs and Resources easier in the web tier.
  4. "That's not true. I think most members of EJB 3.0 expert group will be offended if you state EJB 3.0 to be a cut 'n' paste of Hibernate. I think you have seen this blog http://www.jroller.com/comments/mkeith/Weblog/the_ejb_3_0_hibernate."

    Yeah that is a nice little blog/flame war between Toplink and Hibernate. If you think about it though, your blog really just points out that EJB 3.0 is more like an inferior copy of Hibernate (or Toplink, though certainly not the first version of JDO!), since it doesn't bring the benfits of Hibernate-like coding to web clients.

    I think the truth in all this is that two open-source projects, Hibernate and Spring, showed a better way to do many of the same things being done in J2EE 1.x. Sun has tried to incorporate some of these things (POJO based persistence mechanisms, dependency injection) but it has fallen short. J2EE is likely to always be behind the curve of open source projects that can be more focused and move rapidly. The JCP/JSR process may do a good job of borrowing ideas from these projects, but it is too democratic to ever keep up with them.
  5. Yeah that is a nice little blog/flame war between Toplink and Hibernate. If you think about it though, your blog really just points out that EJB 3.0 is more like an inferior copy of Hibernate

    No, the blog was absolutely NOT a flame war between persistence vendors. In fact, it was an attempt to enlighten the ignorant people that the spec was the combined effort of all of the persistence products. It seems some people didn't see any light, though, implying that maybe their heads are somewhere they shouldn't be.
    (or Toplink, though certainly not the first version of JDO!)

    I have no idea what you were trying to say with this statement. Maybe you could rephrase it.
    I think the truth in all this is that two open-source projects, Hibernate and Spring, showed a better way to do many of the same things being done in J2EE 1.x. Sun has tried to incorporate some of these things (POJO based persistence mechanisms, dependency injection) but it has fallen short. J2EE is likely to always be behind the curve of open source projects that can be more focused and move rapidly. The JCP/JSR process may do a good job of borrowing ideas from these projects, but it is too democratic to ever keep up with them.

    You seem to be cranky about the fact that specifications are following commonly used patterns and practices. Perhaps you prefer the old ivory tower approach that J2EE used to take to develop specs? If you were expecting the standards to swoop down and suck up every feature in Spring then you will be dissappointed your whole life, though. It would be a sorry standard indeed if it adopted a single product/vendor strategy. Nor can it or should it try to keep up with open source products and technologies. That is not what the IT businesses of the world want, which by the way is the primary audience and consumers of standards. You may be happy to fly by the seat of whichever open source pants you happen to be wearing at the time, but corporations want to ensure that they are programming to standards and have reduced their IT risks.

    -Mike
  6. No, the blog was absolutely NOT a flame war between persistence vendors. In fact, it was an attempt to enlighten the ignorant people that the spec was the combined effort of all of the persistence products.
    Hey maybe that's what it was supposed to be, but if you look at some of the comments, you clearly see the flames. I'm not trying to blame anybody for that, just stating the obvious.
    I have no idea what you were trying to say with this statement. Maybe you could rephrase it.
    What I'm saying is that EJB 3.0 is in some ways inferior to the products that inspired it (Hibernate, Toplink, etc.) because, as the author pointed out, it can still be cumbersome for non-EJBs to call EJBs. So while most people like to say that "EJB 3.0 is ${O/R Tech}" that one could argue that "EJB 3.0 is < ${O/R Tech}".
    You seem to be cranky about the fact that specifications are following commonly used patterns and practices. Perhaps you prefer the old ivory tower approach that J2EE used to take to develop specs? If you were expecting the standards to swoop down and suck up every feature in Spring then you will be dissappointed your whole life, though.
    I'm not cranky or disappointed about this, in fact I'm not passing judgement at all. I'm just pointing out that it can't keep up open-source for many of the exact reasons that you point out. I'm not saying it should. We should expect open-source to innovate at a far faster rate than Sun, or Microsoft, or Sun+JCP/JSR can.
    Nor can it or should it try to keep up with open source products and technologies. That is not what the IT businesses of the world want, which by the way is the primary audience and consumers of standards.
    I beg to differ. Please take a look at the primary goal of JavaEE 5: "Ease of development will be a core focus of J2EE 1.5" is what Sun said a year ago at JavaOne. Clearly they had developers in mind with this statement, and developers always want to do things better. That's why Hibernate and Spring have gained such popularity. Developers want better tools. Their employers want shorter development time and less buggy code, i.e. cheaper software. Those are the things that inspire open-source projects like Hibernate, which in turn motivates the evolution of Java.
  7. We should expect open-source to innovate at a far faster rate than Sun, or Microsoft, or Sun+JCP/JSR can.

    Not exactly. Unlike Microsoft, Java EE 5.0 is quickly becoming another CORBA.

    Time will tell open source Java technologies on top of the old, proven J2EE is the real answer to the marching of .NET 2.0.
  8. I beg to differ. Please take a look at the primary goal of JavaEE 5: "Ease of development will be a core focus of J2EE 1.5" is what Sun said a year ago at JavaOne. Clearly they had developers in mind with this statement, and developers always want to do things better. That's why Hibernate and Spring have gained such popularity. Developers want better tools. Their employers want shorter development time and less buggy code, i.e. cheaper software. Those are the things that inspire open-source projects like Hibernate, which in turn motivates the evolution of Java.

    Sure. I agree with these points and thought they were obvious. The issue is that the standard will never include ALL of the features of a particular product, but will always be a subset of most of the implementations. Products innovate, and when the features that they introduce become mainstream enough as to be useful to the general population then they get added. Calling a standard an inferior copy of any product is not at all a fair statement to make. The goal is standardization of the most useful features, not to try to cram in every feature of every product.

    -Mike
  9. specifications are following commonly used patterns and practices

    Yeah and it takes 1-2 years for export groups to standardize them! And in these 1-2 years the customer has to either use the ancient old standard and curse the whole world, or use a non-standard open source framework (like Spring or Hibernate).

    Admitedly many organizations are happy with the first choice, but it's changing. More and more people use open source frameworks. The popularity of Spring or Hibernate shows this.

    And finally after those 1-2 years of hard work when the spec is ready people aren't happy with it, because it's yet another 1-2 years away from what the open source frameowkrs already offer!

    Specs must have a shorter feedback cycle, just like open source....

    Ara.
  10. J2EE is likely to always be behind the curve of open source projects that can be more focused and move rapidly. The JCP/JSR process may do a good job of borrowing ideas from these projects, but it is too democratic to ever keep up with them.

    I look at the democratic element of the JCP/JSR process as more of a benefit then a detriment. Businesses who leverage J2EE technologies (or any technology for that matter) do not always have the luxury nor can they justify the risk of changing every release of their systems to take advantage of the latest and greatest stuff coming out of the open source world at that moment in time.

    Having a standards body that not only defines the standards but also throttles new design adoption into the standard is a good thing.
  11. Businesses who leverage J2EE technologies (or any technology for that matter) do not always have the luxury nor can they justify the risk of changing every release of their systems to take advantage of the latest and greatest stuff coming out of the open source world at that moment in time.

    Businesses do not always have the luxury nor can they justify the risk of changing every release of their systems to take advantage of the latest and greatest stuff coming out of the latest spec either? So what is the fuss?
  12. Businesses do not always have the luxury nor can they justify the risk of changing every release of their systems to take advantage of the latest and greatest stuff coming out of the latest spec either? So what is the fuss?

    No fuss here. Just pointing out why I think having specs and standards are important especially in the enterprise space.

    Another angle on this topic is backward compatibility. With a non-spec based open or closed sourced projects, even minor changes in design can impact backwards compatibility. Having a specs at each fork in the road help to ensure the product being leveraged by businesses will still be functional for code and designs that leveraged the previous "latest and greatest" features.
  13. Only in ideal world[ Go to top ]

    I look at the democratic element of the JCP/JSR process as more of a benefit then a detriment. Businesses who leverage J2EE technologies (or any technology for that matter) do not always have the luxury nor can they justify the risk of changing every release of their systems to take advantage of the latest and greatest stuff coming out of the open source world at that moment in time.Having a standards body that not only defines the standards but also throttles new design adoption into the standard is a good thing.

    This is true in ideal world, but not when vendors with vested interests are always trying to stretch the specifications in different directions to serve their own interests, the common interests of developer get lost somewhere.Democracy is not ideal in all situations.
  14. Only in ideal world[ Go to top ]

    This is true in ideal world, but not when vendors with vested interests are always trying to stretch the specifications in different directions to serve their own interests, the common interests of developer get lost somewhere.Democracy is not ideal in all situations.

    True, however, this is another reason that having the spec process is important. You can easily tell what vendor implementations are apart of the spec and which are not. If you didn't have this spec baseline, then you as a developer would have a much harder time of knowing when you are using standard/portable functionality versus a specific vendors potentially unportable functionality.

    I also don't see it as a problem for various vendors to be lobbying for their functionality to be included in the spec. I think that is perhaps one of the main reasons for having the JCP/JSR process in the first place. I think it is a great thing for a vendors to be involved in pushing the specs forward in a democratic fashion and wanting to share and implement their innovations in a standards body.

    The stark converse of this is the vendor has no interest in standards and sharing innovations and simply offers the functionality to clients in their own implementations which in turn locks the client into that vendor's solution.

    If not a democratic process, which would you advocate? If you are just concerned about having more developers versus vendors influencing the direction of the specs, then get involved. More developer influence instead of vendor influence doesn't mean getting rid of the democratic setup of the process.
  15. Only in ideal world[ Go to top ]

    <blockquoteThis is true in ideal world, but not when vendors with vested interests are always trying to stretch the specifications in different directions to serve their own interests, the common interests of developer get lost somewhere.Democracy is not ideal in all situations.
    Democracy is only good with a true standard body such as ISO, ECMA etc or even W3 in that matter. It is not a good thing with a fake standard body such as proprietary controled JCP.
  16. Only in ideal world[ Go to top ]

    Any standard body is proprietary controled, it must do compromises with money source to get money.
  17. Innovation in specifications[ Go to top ]

    I think the truth in all this is that two open-source projects, Hibernate and Spring, showed a better way to do many of the same things being done in J2EE 1.x. Sun has tried to incorporate some of these things (POJO based persistence mechanisms, dependency injection) but it has fallen short. J2EE is likely to always be behind the curve of open source projects that can be more focused and move rapidly. The JCP/JSR process may do a good job of borrowing ideas from these projects, but it is too democratic to ever keep up with them.

    This is reiterating a little what Mike Keith said, but specifications should not be a place to do innovations, they should be a place to standardize existing innovations. The JCP/JSR process *should* be borrowing ideas from commercial and OSS products. Some of these innovating OSS projects should start contributing back to specifications like EJB instead of pushing their own agenda. The reason why specifications are so popular in the industry is because companies do not want to put all their eggs in one basket and depend on one single product/project/vendor.

    Bill
  18. The new name just does not stick![ Go to top ]

    The changes to EJB 3.0 sound like they are for the most part, a copy 'n' paste job from the excellent work of the Hibernate team.

    The new name "Java Persistence API 1.0" just does not stick. I think Sun has a problem here.

    It is better to call the stuff "EJB3 1.0", so in Java EE 6.0 we will have "EJB3 2.0". All right?
  19. The new name just does not stick![ Go to top ]

    The changes to EJB 3.0 sound like they are for the most part, a copy 'n' paste job from the excellent work of the Hibernate team.
    The new name "Java Persistence API 1.0" just does not stick. I think Sun has a problem here.It is better to call the stuff "EJB3 1.0", so in Java EE 6.0 we will have "EJB3 2.0". All right?

    Or even much better, Java Object Persistence API 1.0 (JOP 1.0).
  20. I can't say Java EE 5.0 is really making developers life simpler, and the simplification story will be half baked!

    When even the vendors are admitting this, you know that EJB3 has a problem.

    The spec committee worked hard on this, but as an end user I look at the current state of EJB3 and it simply looks like an incomplete product. The committee dipped their toes into the POJO pool, but were unwilling to jump in.

    Dependency injection is supported only for narrowly defined use cases. No generalized DI is available.

    As Debu notes, there is no simplification of client invocations for EJB and Web Services.

    These are all issues that have been addressed in Spring, a shipping product. JEE 5 with EJB3 is scheduled for release in 1/2006, and it is already behind the curve. The earliest opportunity to catch up with today's technology would be EJB4 circa 2008.

    EJB3 feels alien and irrelevant to me, the slow cousin in the JEE 5 family that was dropped on his head when he was young. It's one of those technologies that I will only use when required by a client, and even then I will attempt to avoid when possible.
  21. "When even the vendors are admitting this, you know that EJB3 has a problem."

    Don't put your language in to my mouth. EJB3 has greatly simplified use of EJBs and Resources from EJBs. What I'm saying that the same simplification needs to be propagated to other containers i.e. to web clients
  22. When even the vendors are admitting this, you know that EJB3 has a problem.
    Don't put your language in to my mouth.

    I didn't. I quoted you.
  23. The committee dipped their toes into the POJO pool, but were unwilling to jump in.Dependency injection is supported only for narrowly defined use cases. No generalized DI is available.

    By generalized DI you mean XML externalization of Java beans, correct? Yes, I totally agree. If you cared, and I don't think you do, please lobby ejb3-feedback at sun dot com. JBoss at least will be providing a portable way of injecting beans created by DI containers like Spring.
    As Debu notes, there is no simplification of client invocations for EJB and Web Services.

    I don't know:

    @WebService
    public interface MyEndpoint {...}

    @Stateless
    public class MyBean implements MyEndpoint {...}

    Seems pretty simple to me as far as writing. Now for injecting a service-ref, I also could not find it in the specifications as well. But, seems a little tweeking to the @WebService annotation would suffice (making it METHOD and FIELD instead of just a target of TYPE).

    Then:

    @Stateless
    public class AnotherBean ... {

       @WebService MyEndpoint injected;

    }

    Should suffice.

    Bill
  24. As Debu notes, there is no simplification of client invocations for EJB and Web Services.
    I don't know:@WebServicepublic interface MyEndpoint {...}@Statelesspublic class MyBean implements MyEndpoint {...}Seems pretty simple to me as far as writing.
    What does that have to do with the quoted statement? Note what he said(emphasis added):
    As Debu notes, there is no simplification of client invocations for EJB and Web Services.
  25. As Debu notes, there is no simplification of client invocations for EJB and Web Services.
    I don't know:@WebServicepublic interface MyEndpoint {...}@Statelesspublic class MyBean implements MyEndpoint {...}Seems pretty simple to me as far as writing.
    What does that have to do with the quoted statement? Note what he said(emphasis added):
    As Debu notes, there is no simplification of client invocations for EJB and Web Services.

    Just found out that there will be a @WebserviceRef annotation available in the next release of Jax-WS. This makes it REALLY easy for EJBs and Servlets (which are clients Rickard...) to get a reference to a web service.

    I don't know if there are any simplifications for remote clients.

    As far as the Spring JAX-RPC client integration goes, really doesn't look any easier than JEE's. YOu still have to define all the WSDL, port, etc.. junk in XML. Granted, you have to use the Client's JNDI ENC to do lookups, but I agreed with Corby that EJB 3 and JEE 5 for that matter dropped the ball on DI. DI containers compliment JEE and EJB and this is another way they could.

    Like Debu, I think it is extremly simple to define and deploy services in EJB3.

    Bill
  26. If you cared, and I don't think you do, please lobby ejb3-feedback at sun dot com.

    Done. I do care, and I am always eager to use the best technology available for solving enterprise development problems. I would like EJB3 to be it (being the standard and all), I am just (unfairly?) pessimistic that it is going to get there before final spec release.
  27. "As Debu notes, there is no simplification of client invocations for EJB and Web Services"

    >> You can easily invoke an EJB from another using DI as follows

    @EJB CartEJB cart;
    public void addItems() {
      cart.addItem("Item1");
    }


     and what I'm suggesting is to pass the same simplification features to web containers and also for using web services intead of doing complex JNDI lookup

    -Debu
  28. What I'm suggesting is to pass the same simplification features to web containers and also for using web services intead of doing complex JNDI lookup-Debu

    That's what I'm saying, too. Hence the prefix, "As Debu notes..."

    I am also suggesting that invocation could be significantly simplified from clients that operate outside of the JEE5 app server. See Spring remoting framework for an example.
  29. Hmmm. I guess I always viewed the definition of the @EJB injection (and other similar ones) to be part of the overall Java EE 5.0 spec level, not an attribute of any particular API spec within Java EE 5.0. Hence, even though the servlet APIs may not have changed in Java EE 5.0, the fact that EJB 3.0 is part of Java EE 5.0 means (I assert) that it is entirely OK to place

    @EJB CartEJB cart;

    as a line of code in a servlet that's targeted to run on a Java EE 5.0-certified appserver. In fact, I would expect that the CTS tests for Java EE 5.0 would include exactly this type of test.

    There is historical precedent for this, by the way. In J2EE 1.4, the WebService 1.0 spec introduced the new concept of WebService refs. The webservice-ref element was not mentioned specifically in the EJB 2.1 spec, yet J2EE 1.4 (EJB 2.1)-compliant EJB containers had to be able to process webservice-ref elements placed in an EJB deployment descriptor. Supporting @EJB and @Webservice injection directives in all the various Java EE 5.0 containers is really no different.
  30. Hi Randy,
    If these are not available in the web container for sure then I've no complaints and I would state that "Java EE will really simplify developement.

    "as a line of code in a servlet that's targeted to run on a Java EE 5.0-certified appserver. In fact, I would expect that the CTS tests for Java EE 5.0 would include exactly this type of test"


    yes, I would expect that. but as an example if XML support for injection is supported, wouldn't the schema for web.xml needs to be updated or Servlet spec needs to be updated.

    "There is historical precedent for this, by the way. In J2EE 1.4, the WebService 1.0 spec introduced the new concept of WebService refs. The webservice-ref element was not mentioned specifically in the EJB 2.1 spec, yet J2EE 1.4 (EJB 2.1)-compliant EJB containers had to be able to process webservice-ref elements placed in an EJB deployment descriptor."

    Actually service-ref is defined the the EJB 2.1 spec ( section 20.4.1.2 - page 451)

    -Debu
  31. An errata in my last posting. there is a "NOT" that is not required. It should read:

    If these features are available in the web container for sure then I've no complaints and I would state that "Java EE will really simplify development.

    -Debu
  32. What are the advantages of Generics ???

    Avoid casts? I don't think this is a strong argument in favor of Generics.

    Generics has poluted JavaDocs and can polute your code too.

    I may be missing something deeper here, but I see no reason why someone should use generics. What is the pratical advantage of using Generics ??? Avoid casts ??? Create a String-only collection ??? Who needs this type of things ??? And what the price are we paying for this ???

    IMHO, the price for Generics is very, very high for what we are getting for.
  33. Generics[ Go to top ]

    What are the advantages of Generics ???Avoid casts? I don't think this is a strong argument in favor of Generics.Generics has poluted JavaDocs and can polute your code too.I may be missing something deeper here, but I see no reason why someone should use generics. What is the pratical advantage of using Generics ??? Avoid casts ??? Create a String-only collection ??? Who needs this type of things ??? And what the price are we paying for this ???IMHO, the price for Generics is very, very high for what we are getting for.

    Well I think that Generics brings up great value. It's about TYPE-SAFE code. The ability to determine at compile time (through compile time errors or unchecked warnings) the risks of getting ClassCastExceptions. For large projects this is really nice. Beside, you can just choose not to use them.
  34. Generics[ Go to top ]

    Well I think that Generics brings up great value. It's about TYPE-SAFE code.

    I couldn't agree more! While almost everyone would agree that the Collections API has been a integral part of the growth of Java over these years, it did create a large type safety loophole. Now with Generics we are allowed to write safe and TESTABLE methods and classes. No more methods returning Object and the like.

    The costs of fixing compile time errors versus run-time error is so compelling of an argument, I cannot think of a reason why not to use them and refactor all of my previous libraries to implement them.

    Java 5.0 is a seminal moment for Java developers. Those who do not or cannot move forward to take advantage of Generics, Annotations and the like will be left behind in the wake of those who do.

    John Murray
    Sobetech
  35. sorry saps we are...[ Go to top ]

    ...who just barely convinced our bosses to make the big leap to 1.4.

    Being stuck with the IBM JDK which tends to lag doesn't help, either.
  36. sorry saps we are...[ Go to top ]

    ...who just barely convinced our bosses to make the big leap to 1.4.Being stuck with the IBM JDK which tends to lag doesn't help, either.

    I feel your pain. I have been in those situations before. I am not an advocate for bleeding edge implemenation, but not going to 1.4 is frightening.

    I hope you can get back into the game soon.

    John Murray
    Sobetech
  37. ... And what the price are we paying for this ???

    Isn't that for you to explain?
    IMHO, the price for Generics is very, very high for what we are getting for.

    Please elaborate.

    <signature>
    --
    jon martin solaas
    </signature>
  38. Ok, this is just my opinion right now. I am open to change my mind later, if new arguments arise.

    The price of Generics is complexity for the Java language and documentation.

    I can understand Generics, but a rookie will probably not understand what is going on. The Java syntax and documentation is now poluted by Generics. :-(

    I understand that Generics make java more type-safe, by checking for type-safety at compile time.

    But I don´t see this as advantages in the projects I have done so far. ClassCastExceptions is rare. It has happened to me once when I was doing refactoring. Lost 4 seconds to fix it.

    So for me it looks like Sun spent too much time working on Generics to solve a problem I have never had.

    As I said, I hope I can change my mind later and realize that Generics is good. But until this moment that´s my opinion.
  39. Debu, you are right, dependency injection is something that should be higly valuable for Java EE. But you might be wrong also, this is not in the scope of EJB 3.

    I believe that there are 2 competitors in this Java Enterprise landscape: Spring and Java EE.

    I think some people thinks Java EE is better than Spring because of clustering and dynamic configuration and deployment. On the other side, Spring uniquely combines state of the art techniques like DI, AOP and remoting.

    I think that we need a JSR to include Spring-like capabilities into Java EE. Ideally, Rod Johnson himself would lead it or at least would be a key contributor in the expert group.

    I have seen threads here comparing EJB3 and Spring. I think the only competitor for Spring will be Java EE in the future. But Java EE today lacks key Spring features.
  40. I believe that there are 2 competitors in this Java Enterprise landscape: Spring and Java EE.I think some people thinks Java EE is better than Spring because of clustering and dynamic configuration and deployment. On the other side....etc etc

    I think you need to do some more reading up on both Spring and J2EE.