JCP Annual Awards nominations out - what would you choose?

Discussions

News: JCP Annual Awards nominations out - what would you choose?

  1. The JCP has announced the nominations for the 2006 JCP Program Annual Awards. The award winners will be announced May 17 at the JavaOne 2006 conference in San Francisco, CA. Key nominations include the Java EE and EJB3 specifications, as well as the dynamically typed languages specification.

    The Executive Committee votes on who the winners are, which seems a little odd, given the possibility of a relatively small committee choosing its favourite JSRs - many of which the EC members are themselves on.

    While it's hard to argue against some of the nominations, which specifications would you have chosen for special notice? Which libraries or specifications would you have preferred to see in the JCP, if they're not there? Would such notice mean anything to you?

    Threaded Messages (31)

  2. While it's hard to argue against some of the nominations, which specifications would you have chosen for special notice? Which libraries or specifications would you have preferred to see in the JCP, if they're not there?
    Note: these views are my own and do not necessarily reflect those of my employer.
    It would have been nice to see JDO 2.0 listed, since it is, IMHO, such an excellent specification for transparent object persistence, relational or not. The specification has endured despite political pressures otherwise, and stands out on its technical merits. There are many high quality relational implementations of JDO out there, all of which can now easily implement the subset of features defined in EJB 3.0's JPA.

    Further, I would also have liked to see Craig Russell nominated for specification lead of the year, given the large piece of humble pie he was served during the EJB3/JDO2 persistence discussions. He has been, IMHO, an excellent specification lead that has always taken the high road while navigating the political landscape that Java calls home.

    --matthew
  3. Further, I would also have liked to see Craig Russell nominated for specification lead of the year, given the large piece of humble pie he was served during the EJB3/JDO2 persistence discussions. He has been, IMHO, an excellent specification lead that has always taken the high road while navigating the political landscape that Java calls home.--matthew

    +1
  4. +10^10
  5. ++
  6. Craig Russell nomination[ Go to top ]

    I nominate Craig Russell for his work on JDO 2. Especially for keeping silent about the fact that JDO 2.0 is still much better than EJB 3.0/JPA.

    And a blackball for the rest of the EJB 3.0/JPA spec team for obviously not listening to Craig.
  7. Craig Russell nomination[ Go to top ]

    I nominate Craig Russell for his work on JDO 2. Especially for keeping silent about the fact that JDO 2.0 is still much better than EJB 3.0/JPA.And a blackball for the rest of the EJB 3.0/JPA spec team for obviously not listening to Craig.

    I am sure EJB3 will win hands down. :o(

    It makes vendors happy.

    My thoughts on EJB3 and the JCP:

    Interesting Times in the Java Enterprise:
    http://jdj.sys-con.com/read/216307.htm

    http://jroller.com/page/RickHigh?entry=my_jdj_editorial_covering_ror


    Rick Hightower (linked in),blog
    JSF, Spring, and Hibernate training and consulting
  8. Craig Russell nomination[ Go to top ]

    I am sure EJB3 will win hands down. :o(

    It makes vendors happy.

    You're right of course.

    It's still really rather strange the EJB3 is not as good as Hibernate, Spring, or JDO 2.0. They could have made the spec a direct copy of any of those 3 options and it would have been much better than it is.

    Does anyone know what the spec turned out to be a dud?
  9. I am sure EJB3 will win hands down. :o(It makes vendors happy.
    You're right of course. It's still really rather strange the EJB3 is not as good as Hibernate, Spring, or JDO 2.0. They could have made the spec a direct copy of any of those 3 options and it would have been much better than it is.Does anyone know what the spec turned out to be a dud?

    I find it strange as well. :)
    EJB in general, except as a learning experience, is generally viewed as a failure. The real problem was not just EJB but the misapplications of EJB. This was widespread as it was promoted with the J2EE Blueprint, not to mention the misapplication of JTA, and more features of J2EE. Not to say that applications can't benefit from JTA and EJB, it's just that many, many Web applications don't need them.

    EJB 3.0 is much better than EJB 2.x. If you compare EJB3 to an older version of EJB, EJB3 is a boon; however, if you compare EJB3 to Spring and Hibernate, it stinks.

    The related OR (Object Relation) Persistent API does not have a criteria API specified; any persistent API that does not define a criteria API is not finished.

    The AOP support in EJB3 is broken. EJB3 has a method interceptor, but no pointcuts. In addition, the method interceptors are declared and imported with class-level annotations. This effectively tightly couples the class to the method interceptors that decorate it (Can you smell the bad odor?).

    Rod Johnson mentioned thess same problems about EJB3 Method Interceptors at a recent Java enterprise conference (in his talk "Are We There Yet" at TSS S) and went on to mention many limitations on the @Resource style of DI, the absence of FactoryBeans, post processors, Constructor Injection, lists/maps, and a lot of the features Spring developers know and love are just missing.

    (It seems)The EJB3 JSR members did not look at any of the prior art in this space and created their own limited version of what was already available.

    I've heard some call EJB3 a dumbed-down version of what is available by using Spring and Hibernate. "EJB3 is Spring and Hibernate's (retarded) cousin" is frequently echoed.

    After three years of deliberation, the JCPs delivered EJB3, which is inferior to de facto standards. Many parts of EJB3 are a big step backward from Spring, and, to many, EJB3 is broken. As Bruce Tate says about EJB3: "Don't make me eat the elephant again."

    It's not just the persistent API and the AOP support that's broken in EJB3, it's also the random use of annotations, another misguided effort. The idea of annotations is good. The implementation of the annotations ruins some of the principles of the POJO model; namely, it ties your Java classes through a compile-time dependency to the standard API you're using and to any value-add annotations the vendor supports. Now why would vendors like this approach? Hmmm...I wonder. (Hint: Follow the money!)

    In that question lies the real problem with the JCP. The JCP is heavily influenced by vendors that have "business need(s) or corporate agenda(s)." Parts of the enterprise Java community is innovative, parts stink, but there are many parts.
    Read editorial at: http://jdj.sys-con.com/read/216307.htm
  10. It would have been nice to see JDO 2.0 listed, since it is, IMHO, such an excellent specification for transparent object persistence, relational or not.
    +1
    They've clearly taken a bung from certain large corporations ...
    [These opinions are mine and represent my employer totally]
    <blobkquote>I would also have liked to see Craig Russell nominated for specification lead of the year+1
  11. Ed Burns[ Go to top ]

    +1 for Ed Burns of JSR 252 for putting up with Adam and I
  12. Ed Burns[ Go to top ]

    +1 for Ed Burns of JSR 252 for putting up with Adam and I

    +10
  13. XMLSpy damnit!
  14. I would vote for JSF. It makes web development easier than model 2 frameworks and provides a much needed standard web component model.

    I would vote against EJB3. It is a poor imitation of what you can do with Spring and Hibernate. Its use of Annotations are broken. Its AOP has no pointcuts. Its, related, persistence API has not criteria api.

    I wrote more about why I dislike EJB3 here:

    http://jroller.com/page/RickHigh?entry=my_jdj_editorial_covering_ror

    and here

    http://jdj.sys-con.com/read/216307.htm

    Rick Hightower (linked in),sleepless blog
    JSF, Spring, and Hibernate training and consulting
  15. I would vote for JSF. It makes web development easier than model 2 frameworks and provides a much needed standard web component model.I would vote against EJB3. It is a poor imitation of what you can do with Spring and Hibernate. Its use of Annotations are broken. Its AOP has no pointcuts. Its, related, persistence API has not criteria api.

    You are right.

    I believe that good JSRs should encourage innovative development based on them; they should not simply formalise what is already around. Whatever its faults, this certainly seems to be happening with JSF. The opposite is the case with EJB3 - it is a subset of already existing innovative ideas.
  16. I would vote for JSF. It makes web development easier than model 2 frameworks and provides a much needed standard web component model.I would vote against EJB3. It is a poor imitation of what you can do with Spring and Hibernate. Its use of Annotations are broken. Its AOP has no pointcuts. Its, related, persistence API has not criteria api.
    You are right.I believe that good JSRs should encourage innovative development based on them; they should not simply formalise what is already around. Whatever its faults, this certainly seems to be happening with JSF. The opposite is the case with EJB3 - it is a subset of already existing innovative ideas.

    We could not agree more. I think you put your case to mildly. It is a real step backwards from what already exists.

    In the last year, demand for EJB skills has dropped 20%. Thanks in a large part to the book "Bitter EJB" (Bruce Tate et al) and "J2EE with EJB" (Rod Johnoson).

    In the same last year, demmand for JSF, Hibernate and Spring doubled. Rod Johnson et al has a better vision. EJB should have been dumped and something like Spring + Hibernate should be the new standard.

    (Hibernate more than doubled.)

    Let's see how well EJB3 does in a year. Time will tell.

    I hope Spring is entrenched enough. Time will tell.

    Down with JEE 5 (EJB 3). Up with J3EE (Spring and Hibernate).

    Remember J3EE, when TSS rocked and world of Enterprise Java was fresh with new ideas.

    Memory lane:
    http://www.theserverside.com/news/thread.tss?thread_id=23403
  17. I forgot to mention....

    When ideas were fresh and EJB vendors like Hani were quaking in their boots....

    Have you ever seen fear from an EJB vendor, if not look here:

    http://www.jroller.com/page/ara_e/20040118#j3ee_is_on_the_horizon
  18. (misfire... with wrong link...)

    I forgot to mention....

    When ideas were fresh and EJB vendors like Hani were quaking in their boots....

    Have you ever seen fear from an EJB vendor, if not look here:

    http://www.jroller.com/page/fate/?anchor=j3ee_is_moron_bait
  19. We could not agree more. I think you put your case to mildly.

    Oh I do try and be mild :)
    EJB should have been dumped and something like Spring + Hibernate should be the new standard.(Hibernate more than doubled.)

    I would not be totally at ease with this. I have no personal experience of using Hibernate (I guess it is about time I did!), but there were debates about the merits of different approaches to persistence on the recent JPOX topic. I hope that JDO 2.0 products pick up at least some of the EJB demand; JDO 2.0 is a rich and useful specification, and having a choice of approaches to persistence is healthy (after all, Hani does not like JDO either!)
  20. We could not agree more. I think you put your case to mildly.
    Oh I do try and be mild :)
    EJB should have been dumped and something like Spring + Hibernate should be the new standard.(Hibernate more than doubled.)
    I would not be totally at ease with this. I have no personal experience of using Hibernate (I guess it is about time I did!), but there were debates about the merits of different approaches to persistence on the recent JPOX topic. I hope that JDO 2.0 products pick up at least some of the EJB demand; JDO 2.0 is a rich and useful specification, and having a choice of approaches to persistence is healthy (after all, Hani does not like JDO either!)

    Hani hating something does not mean I will like it. I agree with him about a lot of things, and think he is a talented person (just wrong about Maven, JSF, Spring and Hibernate).

    I have not formed an opinion on JDO or JPOX either way.

    (After all, Hani dislikes Struts as do I.)
  21. Hani hating something does not mean I will like it.

    I wasn't serious - this was just a poor attempt at humour, as in that blog entry, JDO was listed along with Hibernate and Spring and others as things that will pass and replaced with 'new cool things'.
    I agree with him about a lot of things, and think he is a talented person (just wrong about Maven, JSF, Spring and Hibernate).

    Agreed.
    I have not formed an opinion on JDO or JPOX either way.

    My gentle suggestion is that it might be interesting to look at JDO (especially JDO 2.0, which is a vast improvement over JDO 1.0), before there is a suggestion that 'Hibernate is the new standard' :) (Regarding JPOX, it is nice to have JPOX as an open source RI for JDO 2.0, but there are also some extremely good commercial JDO products, with great tools).
  22. Hani hating something does not mean I will like it.
    I wasn't serious - this was just a poor attempt at humour, as in that blog entry, JDO was listed along with Hibernate and Spring and others as things that will pass and replaced with 'new cool things'.
    I agree with him about a lot of things, and think he is a talented person (just wrong about Maven, JSF, Spring and Hibernate).
    Agreed.
    I have not formed an opinion on JDO or JPOX either way.
    My gentle suggestion is that it might be interesting to look at JDO (especially JDO 2.0, which is a vast improvement over JDO 1.0), before there is a suggestion that 'Hibernate is the new standard' :) (Regarding JPOX, it is nice to have JPOX as an open source RI for JDO 2.0, but there are also some extremely good commercial JDO products, with great tools).

    I know you were kidding.


    I tried JSF b/c I was not happy with Struts. It was hard to build richer web apps. It could be done, but you were on your own.

    I tried Spring b/c I was not happy with EJB. It was hard to build/deploy. It slowed down development. XDoclet! enough said.

    I tried Hibernate b/c I was sick of my home grown ORM and EJB2.x CMP/CMR was limited.

    I guess my issues with JDO (and for that matter EJB3) is I am happy with Hibernate.

    If I were unhappy with Hibernate, then I would be all over JDO.

    Then again, I thought I was happy with JUnit until I saw Cedric's talks on TestNG.

    To me, the case has not been made for JDO (at least one that gets me motivated to try it).

    Please name five reasons I should use JDO over Hibernate.

    (This is not a test, but a sincere request.)

    I am not hard headed. I change (not often but I do change).

    One year, I spoke at JavaOne on the wonders of EJB2.x and XDoclet. At some point I met Gavin King at the first TSS S, and he explained the wonders of Hibernate (in the lobby while drinking beers), and I was sold (and have never looked back).

    Why should I use JDO over Hibernate?

    (EJB3 is a lost cause for me. I'll use it when a client demands it and not before.)
  23. I know you were kidding.

    Sorry - I sometimes find it hard to read the tone of posts.
    Please name five reasons I should use JDO over Hibernate.(This is not a test, but a sincere request.)

    That is a hard one! Because I wasn't suggesting that you switch, or that JDO is better for your uses. I was simply reacting to the combination of your statements that Spring + Hibernate should be the new standard and that you have not formed an opinion on JDO. Hibernate is great, and has helped to revolutionise Java persistence, but it some ways it does not suit me, so I am cautious about any idea that it should be 'the' persistence standard.

    Getting round to answering your request, I'll have a go, although I am not sure I can get to five!

    1. JDO is not just for relational systems. Although I have never yet used this ability, I really like the idea that I can write an application that can work efficiently on high-end databases but also possibly work on XML data stores , or even CSV files, perhaps in some sort of portable or demo version of the software. I have possible future projects where this could be extremely useful.

    2. Having a standard with multiple implementors can encourage innovation in all sorts of directions. Just look at what Xcalia are doing with their implementations, using JDOs non-relational abilities.

    3. JDO has (in my opinion) useful object lifecycle features that can allow an implementation to be very efficient in terms of memory use for large transactions.

    4. JDO has (in my opinion) useful features like fetch groups and plans that allow fine tuning of what is retrieved without having to change queries, and can also allow queries to be simpler - they can express things in broader terms.

    5. Having a standard with competing implementations can give a user some leverage when dealing with a JDO vendor!

    made it to 5!

    Now, Hibernate may or may not have some of these features - I don't know it well enough. I know it has features that JDO 2.0 does not. Also, I realise the advantages of some of the things I describe above are hotly debated. But, these points explain why I like JDO 2.0, and why I would be cautious of any 'Hibernate standard' (althought I realise it is so widely used it could the standard in all but name).
  24. I know you were kidding.
    Sorry - I sometimes find it hard to read the tone of posts.
    Please name five reasons I should use JDO over Hibernate.(This is not a test, but a sincere request.)
    That is a hard one! Because I wasn't suggesting that you switch, or that JDO is better for your uses. I was simply reacting to the combination of your statements that Spring + Hibernate should be the new standard and that you have not formed an opinion on JDO. Hibernate is great, and has helped to revolutionise Java persistence, but it some ways it does not suit me, so I am cautious about any idea that it should be 'the' persistence standard.Getting round to answering your request, I'll have a go, although I am not sure I can get to five!1. JDO is not just for relational systems. Although I have never yet used this ability, I really like the idea that I can write an application that can work efficiently on high-end databases but also possibly work on XML data stores , or even CSV files, perhaps in some sort of portable or demo version of the software. I have possible future projects where this could be extremely useful.2. Having a standard with multiple implementors can encourage innovation in all sorts of directions. Just look at what Xcalia are doing with their implementations, using JDOs non-relational abilities.3. JDO has (in my opinion) useful object lifecycle features that can allow an implementation to be very efficient in terms of memory use for large transactions.4. JDO has (in my opinion) useful features like fetch groups and plans that allow fine tuning of what is retrieved without having to change queries, and can also allow queries to be simpler - they can express things in broader terms.5. Having a standard with competing implementations can give a user some leverage when dealing with a JDO vendor!made it to 5!Now, Hibernate may or may not have some of these features - I don't know it well enough. I know it has features that JDO 2.0 does not. Also, I realise the advantages of some of the things I describe above are hotly debated. But, these points explain why I like JDO 2.0, and why I would be cautious of any 'Hibernate standard' (althought I realise it is so widely used it could the standard in all but name).

    To me Hibernate is the de facto standard and not a standard per se. When I looked at JDO 1... the problem was that the relational mappings were not defined well enough.

    I actually like the fact that Hibernate focuses on Relational DB mappings, and not generic storage. Relational DB mapping is complex enough.

    A de facto standard that is used by most people is better than a limited official standard.

    I may look into JDO 2.0 at some point in the future. I've heard good things about KODO. It has been a while since I looked into JDO so I forgot most of what I learned. I never used it in anger. It sounds like it is better. But, Hibernate works for what I am doing. EJB3 does not b/c EJB3 does not have a criteria API.
  25. To me Hibernate is the de facto standard and not a standard per se.
    When Hibernate came out there were not too many open source choices.
    Yes, it became a de-facto standard because it was/is a good solution, but the were no alternatives.
     When I looked at JDO 1... the problem was that the relational mappings were not defined well enough.
    Yes, this is true. But the typical mapping requirements
    were well supported by many vendors.
    More, JDO allowed multiple vendor extensions to be defined
    in the same .jdo files.
    Anyway, I don't see this lack of spec of OR mapping in JDO1 a real big issue.
    If you were with hibernate and decided to change vendor you had no
    alternatives both for the Java part and the mapping part.
    You had to change you application.
    If you were with JDO and decided to change vendor you had
    to change only the mapping part. No change in Java was
    necessary.
    I would add a 6th reason to your request.
    Try how it is easy to develop you entire application with a zero-mapping JDO implementation (e.g. objectdb) and the switch (if you need) to you favourite OR mapping one.
    I've heard good things about KODO. It has been a while since I looked into JDO so I forgot most of what I learned. I never used it in anger. It sounds like it is better. But, Hibernate works for what I am doing. EJB3 does not b/c EJB3 does not have a criteria API.
    Yes, from my experience KODO works quite well.
    Unfortunately, I don't like recent marketing decisions (core runtime + JPA impl being open source and JDO2 impl closed source) :(

    Guido
  26. hen I looked at JDO 1... the problem was that the relational mappings were not defined well enough.

    I fully agree - but JDO 2.0 is full-featured in the area (I would say it even has better relational mapping capabilities than EJB3).
    I actually like the fact that Hibernate focuses on Relational DB mappings, and not generic storage. Relational DB mapping is complex enough.

    I am not sure I agree with this as a criterion for choosing Hibernate. There are JDO implementations that have a reputation for being very efficient and high-performance on relational systems. Being more versatile has not prevented JDO implementations from being very effective on relational DBs.
    I never used it in anger. It sounds like it is better.

    JDO 2.0 really is a huge improvement over JDO 1.0.
    But, Hibernate works for what I am doing. EJB3 does not b/c EJB3 does not have a criteria API.

    Neither does JDO!
  27. We could not agree more. I think you put your case to mildly. It is a real step backwards from what already exists.
    I don't understand this position.

    The JCP's goal simple: to advance the Java platform.

    Sometimes, it means innovating and exploring brand new areas, and other times, it's just about standardizing a popular product in order to bootstrap the industry and create more vertical innovations.
    In the last year, demand for EJB skills has dropped 20%. Thanks in a large part to the book "Bitter EJB" (Bruce Tate et al) and "J2EE with EJB" (Rod Johnoson).In the same last year, demmand for JSF, Hibernate and Spring doubled.
    These relative trends are close to meaningless.

    It's a bit like saying that Linux adoption has increased 50% and Windows only 1% and deducing that Linux is going to take over the planet.

    Don't get me wrong: Rod and his team are doing a fantastic job and Spring definitely has a bright future in the Java universe, but so does EJB3 and many of the technologies you so quickly dismiss.

    --
    Cedric
    TestNG
  28. Say what? Dismiss EJB3... I don't think so.

    I have not dismissed EJB3. I'll end up using it at some point I am sure (kicking and screaming), and as I stated many, many times it is better than EJB2.

    EJB3 is inferior to Spring. The JCP screwed up. It took to long and it stinks.
    These relative trends are close to meaningless.

    No its not. Especially if you are looking for work and like JSF, Spring and Hibernate. Meaning requires context. The context is there for me. Besides the trends are for a year. In technical terms a year is fairly long. I think you overstated your case. The verdict is out on EJB3. Classic EJB was shrinking thanks to Bruce, Rod and friends... plain and simple.

    The point of the stats was to show that your bile buddy predictions were meaningless, namely, that JSF, Hibernate, and Spring did not have a future. He made these predictions two years ago or more. Wrong. wrong. wrong.

    BTW great talk on TestNG at TSSS. I don't use it yet, but plan to.
  29. These relative trends are close to meaningless.
    No its not
    Let me try something else, then.

    At some point in the past, you could say the same about Jini or JXTA: they were all the rage, were featured in conferences, forums, blogs (well, actually no, there was no blog back then). Their rate of adoption and buzz was measured in the same terms you are using and everybody concluded that they clearly represented the future of Java.

    We all know what happened after that.

    So, again: measuring how fast something is growing is absolutely meaningless unless you have at least one of the following two metrics accompanying it:

    - Volume. Big volume.
    - Continuous growth over a period of several years (I'd say three).

    Jini and JXTA never had any of those, they just "grew a lot" for a short period of time and then just died.

    In short, these trends are only the symptom of a burst of attention by the Java community, nothing more.

    --
    Cedric
  30. These relative trends are close to meaningless.
    No its not
    Let me try something else, then.At some point in the past, you could say the same about Jini or JXTA: they were all the rage, were featured in conferences, forums, blogs (well, actually no, there was no blog back then). Their rate of adoption and buzz was measured in the same terms you are using and everybody concluded that they clearly represented the future of Java.We all know what happened after that.So, again: measuring how fast something is growing is absolutely meaningless unless you have at least one of the following two metrics accompanying it:- Volume. Big volume.- Continuous growth over a period of several years (I'd say three).Jini and JXTA never had any of those, they just "grew a lot" for a short period of time and then just died.In short, these trends are only the symptom of a burst of attention by the Java community, nothing more.-- Cedric

    Exactly. There was a lot of buzz about Jini and JXTA but no job demand. Job demand is an indicator of adoption (not a perfect one). Buzz is not. We are in violent agreement.
  31. Cedric,

    I realize now that I did not specify the demand for skills was demand for jobs. I assumed it was clear, but now I don't.

    This is from a recent comment on my blog:
    The verdict is in:

    Drum roll!

    Looking at the job demmand growth charts for the last year:

    Demand for Spring developers more than doubled.

    Demand for JSF developers more than doubled.

    Demand for Hibernate developers more than doubled.

    Demand for WebWork developers is up 1/3.

    Demand for Tapestry developers is up 1/3 (the demmand is less than 1/3 of the demmand for JSF).

    Demand for Struts is up 10%. (Shocker!)

    Demand for EJB is down 20%. (Yeah!)

    Demand for C# is up a hair.

    Demand for Java is flat.

    (I verified the above.)


    I checked JDO for kicks.

    Demand for JDO has dropped by 30%.

    This is not the only indicator for adoption. And, it may not be a leading indicator. It is an indicator.
  32. I checked JDO for kicks.Demand for JDO has dropped by 30%.

    To be honest, JDO hasn't been that widely used for statistics to be that accurate one way or another. I suspect even measures of demand for Spring and Hibernate are innacurate (and underestimate their use) as I would imagine that in the past those products have been used substantially by individual developers or small teams, or for internal projects, such as when EJB has proved unworkable.

    I may be being foolishly optimistic, but the presence of a good open source version of JDO 2.0 - JPOX - may increase its use.

    If JDO does decline to the point where it effectively dead, so be it. Just as long as I don't have to use EJB 3.0 as it is in its current form.