Home

News: Rod Johnson: "Java EE 6 Gets it Right"

  1. Rod Johnson: "Java EE 6 Gets it Right" (74 messages)

    Rod Johnson has pointed out that the Java EE 6 proposal has gone before the JCP (round two, with the first one having been withdrawn), and says that the new specification gets things right with the inclusion of "profiles," which offer a range of functionality instead of making a compliant container implement everything in the spec, most of which might not be used. The JSR is only put offered for consideration at this point, but the proposal itself offers some intriguing possibilities, centering around four major areas:
    • Extensibility
      The new specification proposal suggests offering more service provider interfaces and extension points, meaning that technologies can "cleanly layer on or plug in to" Java EE application servers.
    • Profiles
      Profiles "may include a subset of Java EE platform technologies, additional JCP technologies not part of the base Java EE platform, or both." Part of the proposal offers the initial definition of a "Java EE Web Profile - a subset of the Java EE platform targeted at web application development. This profile will provide a more gentle introduction to the Java EE platform, providing only those technologies needed by most web application developers, without the enterprise technologies that sometimes confuse such developers."
    • Pruning
      The proposal also offers a mechanism which, along with profiles, can convert currently required specifications into optional specifications. For example, as Rod says in his blog, Java EE 5 still mandates support for EJB 1.1 and EJB 2.0. This isn't necessarily a bad thing, but for new development, EJB 1.1 and EJB 2.0 are largely irrelevant, and shouldn't be required in an application server used to develop new Java EE 5 applications. The "pruning" aspect of the Java EE 6 specification allows the definition of the process by which mandated subspecifications can become optional.
    • SOA support
      The new specification is considering aspects of the Service Component Architecture for inclusion into the Java EE specification. Unfortunately, there are two major revisions of SCA - one under JCP control (and largely stalled, to all appearances) and the other, alive and well under IBM's and BEA's stewardship. That said, both IBM and BEA are supporting this specification, so perhaps some future unification is in order.
    One other important note is that the Java EE 6 specification is an "umbrella specification," meaning that it's largely built on other specifications that co-exist with it: the Servlet 3.0 specification, the Web Beans specification, the Java API for RESTful Services, etc. Rod is positive about Java EE 6, following an exellent analysis of his positions on J2EE and how Java EE 6 addresses many of them with:
    I believe that the enterprise Java community should welcome Java EE 6, and should welcome Sun's willingness to move with the times and take the choices that will strengthen the enterprise Java platform as a whole. There's a lot of good in J2EE/Java EE, but some of the problems have obscured it. Java EE 6 should change that!
    While Java EE 6 is more a factor of the JCP and not Sun, Rod's sentiments are well taken.

    Threaded Messages (74)

  2. If the spec bloat is significantly reduced, would it be possible to consider making Spring a Java EE 6 application server? /Henri Karapuu
  3. I find that highly unlikely. Some parts of Spring are designed to work on existing JEE services. I can't imagine they will reinvent a servlet container, JMS, JPA, JMX, etc. However I imagine it will be likely that Spring technology will be the basis of certain JEE 6 profiles on top of containers like Tomcat. Much like how BEA Weblogic 10 uses Spring to help implement some of its JEE 5 services.
  4. I find that highly unlikely. Some parts of Spring are designed to work on existing JEE services. I can't imagine they will reinvent a servlet container, JMS, JPA, JMX, etc.
    Umh, no i didn't mean that they would actually re-write components, i meant gluing existing ones together to form functionality which would satisfy requirements of some Java EE 6 profile. Something like 'Spring AS' subproject, offering a ready-to run bundle, perhaps. /Henri Karapuu
  5. I guess he is right. But *sigh* there is a part of me that longs for the good old days when Spring was seen as something that flew in the face of those unwieldy "J2EE standards" and "core J2EE patterns" :) I felt that the turning point was when Rod endorsed JPA. I also gather that the Spring folks are endorsing JSF as well which IMHO makes me like Spring a little less :( So I guess the container is dead and now it is all about things you can glue together to get the services that you *truly* need. Come to think of it, this was what was happening anyway with JPA for e.g. Long live Java EE! But it will take a lot of convincing to get me to move away from my Jetty + Spring + Hibernate + Wicket "ideal" stack to things like EJB3 and JSF though.
  6. Extensibility is the key[ Go to top ]

    I don't think that is the idea. The word 'extensibility' is the key. If the new spec is to offer more extension points for developers/frameworks, Spring could be more integrated, serving as a plugin to the container. I mean, today integration is made between frameworks. Only frameworks that can delegate object creation to another framework can be easily integrated, because Spring only injects dependencies into its own managed beans. Say, WebWork/Struts2, JSF, Tapestry integration. It can't, for example, inject dependencies into EJBs. But, if the EJB container had an extension point for bean creation, it could inject not only other EJBs or JNDI resources, but also Spring components. It could let Spring act directly on EJBs lifecycle. It could provide some way to programatic declaration of EJBs, so Spring beans could be automatically exported to the EJB container registry. Or Servlets, listeners, resources. Depending on the changes of the spec, Java EE can turn into an integration platform, instead of an application framework. Today, its functionality is a mix of infrastructure and application framework. Servlets are infrastructure, JSF is (part of) an application framework. EJBs should be infrastructure, but because of its lack of standard extension points, you can only rely on infrastructure supported by the spec (security, tx, threads, lifecycle, etc.), but you can't add new ones or switch to other (better) solutions (acegi instead of the EJB container security, for example) without many tricks, roundtrips and workarounds. And, by turning Java EE into an integration platform, it is logical to see all of its technologies (security, tx management, messaging, etc.) in a more modular way. Then, 'profiles' make more sense. You could mix and match features on demand, like what Spring already does today. Maybe in the future Spring's container will be just another option of container, and its various components will be just extensions of the standard model. Well, I hope they really get it right :)
  7. Re: Extensibility is the key[ Go to top ]

    I mean, today integration is made between frameworks. Only frameworks that can delegate object creation to another framework can be easily integrated, because Spring only injects dependencies into its own managed beans.
    @Configurable?
  8. I guess he is right. But *sigh* there is a part of me that longs for the good old days when Spring was seen as something that flew in the face of those unwieldy "J2EE standards" and "core J2EE patterns" :)

    I felt that the turning point was when Rod endorsed JPA. I also gather that the Spring folks are endorsing JSF as well which IMHO makes me like Spring a little less :(

    So I guess the container is dead and now it is all about things you can glue together to get the services that you *truly* need. Come to think of it, this was what was happening anyway with JPA for e.g.

    Long live Java EE! But it will take a lot of convincing to get me to move away from my Jetty + Spring + Hibernate + Wicket "ideal" stack to things like EJB3 and JSF though.
    How do you get the idea that the Spring people are endorsing jsf? There have been jsf bindings from spring into JSF for a long time (even in 1.x), so nothing new there. And if you mean Orchestra, that is a myfaces subproject, not a spring project. JSF is just one of the supported frameworks from Spring, their own cow so to say is Spring MVC ;-). So there are no conspiracy theories to be found here and no significant endorsement. It is just that the JSF IoC and the Spring IoC model are very similar so replacing the JSF one with pure spring simply makes sense, hence you can see a lot of work to be done in this area (most of the work although outside of the Spring project itself)
  9. Peter, You raise some interesting points, to which I'd like to respond.
    I guess he is right. But *sigh* there is a part of me that longs for the good old days when Spring was seen as something that flew in the face of those unwieldy "J2EE standards" and "core J2EE patterns" :)
    Spring set out to help solve problems, not oppose anything in particular. The Spring team will continue to focus on solving problems and developing the best software we can. There has been much about all previous Java EE releases that I couldn't subscribe to (and still don't). But it would be intellectually dishonest for me not to support the EE6 direction, as I genuinely believe it's exciting. If Java EE6 is no longer unwieldy and no longer requiring hacky "patterns," it makes sense to support it. Of course, there's going to be a lot of work in making the vision become reality in the final EE6 release, but I am keen to try to do what I can to help there, from the inside.
    I felt that the turning point was when Rod endorsed JPA. I also gather that the Spring folks are endorsing JSF as well which IMHO makes me like Spring a little less :(
    Similarly, I think JPA is good news and love the fact that CMP is now going to be effectively deprecated in its favour. Sure, JPA and JPA products still have some maturing to do, but it was clearly a good direction. I still haven't made up my mind about JSF, but we have people in our community who want to use Spring (and Spring Web Flow) and JSF, and it's important that we accommodate that. Also, JSF and SWF are very complementary, so its natural for them to work together. Note that will not be forcing people to use JSF if they want to use Spring web technologies; merely ensuring that the Spring web stack is the best choice if they do.
    Long live Java EE! But it will take a lot of convincing to get me to move away from my Jetty + Spring + Hibernate + Wicket "ideal" stack to things like EJB3 and JSF though.
    Well, if you're happy with your solution and it works, you don't need to move away from it. If you want a profile without EJB3 and JSF...EE6 should allow that possibility. Rgds Rod
  10. Wow, so now will have less books espousing the virtues of EJB CMP! Less books preaching "But it is the standard from Sun". Large JEE app server vendors will really start to focus on selling people ESB products as the ultimate solution for all enterprisy requirements, and best of all fewer code monkeys will be needed to type away the J2EE core patterns!
  11. Fantastic[ Go to top ]

    This is the best news JEE has had for some time. With the people behind this spec having made what is a very hard but necessary decision, and with people like Rod Johnson contributing to the JEE development process, the future of Java in the enterprise is looking brighter than it has done for some time.
  12. see it here: Can Someone Tell Sun About OSGi? I find it strange also, since Spring people are involved with OSGI too (not mentioning almost all existing J2EE implementations!), and thus should have noticed the same issues as Peter did.
  13. My wish list for JEE6: - JEE2 runtime is governed by OSGi runtime - Deploy applications as OSGi bundles, and not EARs... - APIs such as JMX, JMS, EJB have become OSGi bundles... - JEE6 modularity implemented with OSGi. Choose just what you need. - bundles interchangeable between vendors.
    • SOA support
      The new specification is considering aspects of the Service Component Architecture for inclusion into the Java EE specification. Unfortunately, there are two major revisions of SCA - one under JCP control (and largely stalled, to all appearances) and the other, alive and well under IBM's and BEA's stewardship. That said, both IBM and BEA are supporting this specification, so perhaps some future unification is in order.
    I'd just like to correct the comments about Service Component Architecture (SCA). Java EE 6 is indeed considering the inclusion of SCA. However, there are not 2 major revisions of SCA. There is only one version of SCA - Version 1.0 - which can be found at: http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications SCA has been created by the Open SOA collaboration - a collaboration of 18 companies, including IBM and BEA, but also including Oracle, SAP, Sun, TIBCO, Red Hat, Interface21. SCA has never been part of the JCP process, in part because SCA spans multiple programming languages (For example, BPEL, C++, PHP as well as Java). Far from being stalled, SCA is alive and well and appearing in an increasing number of implementations, both open source and commercial: http://www.osoa.org/display/Main/Implementation+Examples+and+Tools SCA has now been submitted to OASIS for formal standardization under the Open CSA member section, which you can find here: http://www.oasis-opencsa.org/ Since there is only one SCA specification - there is no need for any "future unification". Java EE 6 can take it as it is... Yours, Mike
  14. Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU. Regards, Bill
  15. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.

    Regards,

    Bill
    Well, who cares about all these JSR's anyway. They are so many now, and they are overlapping. A product doesn't get any better just because you create a JSR for it. It probably gets worse, since now you have to compromise because company A has a existing product that they want to implement this JSR, and company B has some other product that they want to implement the JSR. Then they agree on a unusable standard, and everyone has to use proprietary vendor extensions, and find themselfs locked in by a vendor anyway. It could be good if a product implementing a JSR would find itself to be more future proof, but it seems to be the complete reverse... /Magnus
  16. Re: Put out or shut up Rod[ Go to top ]

    Well, who cares about all these JSR's anyway.
    LOTS of people care about JSRs. * companies which want a stable technology environment to make a longterm (10 year +) investment in * vendors who implement specifications and want to minimize the risk of investing in R&D for a market that may or may not be there * ISVs who implement proprietary products on top of specifications, and want a set of lower-level APIs that are stable and supported across the industry * folks who build tooling (or use it) Just look at the JSF space, and the number of third-party products which have been built on top of JSF, and compare to Struts, which is much older and more widely used. That's the difference a JSR makes.
    They are so many now, and they are overlapping.
    Really, such as?
    A product doesn't get any better just because you create a JSR for it. It probably gets worse, since now you have to compromise because company A has a existing product that they want to implement this JSR, and company B has some other product that they want to implement the JSR.
    In my view, the JPA specification is in several respects "better" than any of the non-standard products which preceded it. To get all vendors to agree to a design was a pretty high bar to cross over, and guaranteed that we pretty much *had* to get it right.
    Then they agree on a unusable standard, and everyone has to use proprietary vendor extensions, and find themselfs locked in by a vendor anyway.
    One of the great paradoxes of the standards vs. nonstandards debates is this idea that you are somehow better off if you tie 100% of your code to some totally proprietary solution than you are if you use standards for 98% of your code, and then use some vendor extension for the remaining 2%. You're not. You are 98% worse off.
  17. Burke vs Johnson[ Go to top ]

    Will we ever have Bill Burke vs Rod Johnson at a WRESTLEMANIA? Or maybe MTV Celebrity Deathmatch? This "Spring vs JBoss war" or whatever it is needs to stop. Seriously.
  18. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.

    Regards,

    Bill
    Probably biting into a flame-bait sandwich here but what does one have to do with the other? Last I checked standards were there to help make different implementations, proprietary and open source, work together. So is it hypocracy for a proprietary vendor to embrace standards? Better run and tell IBM, BEA, etc.
  19. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.

    Regards,

    Bill


    Probably biting into a flame-bait sandwich here but what does one have to do with the other?

    Last I checked standards were there to help make different implementations, proprietary and open source, work together. So is it hypocracy for a proprietary vendor to embrace standards? Better run and tell IBM, BEA, etc.
    The difference is that at least IBM and BEA have products which are based on standards and many of their products participate in standardization efforts, while Rod and company only produce non-standard software controlled by Interface 21. Bringing pure IoC into EE 6 and getting somebody like Rod and Interface 21 behind it and supporting it would be a huge step in lengthening the viability of the EE platform. But I don't think Rod and company believe it is in their best business interest to do so. I hope they prove me wrong. We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler. Bill
  20. Re: Put out or shut up Rod[ Go to top ]

    We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler.

    Bill
    The big question is when - if ever - the time is right for a project to join a standardization effort. Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so. It needed to 'beat' the standards (EJB, JDO) before people took it seriously and before it could make a serious contribution to JEE. Maybe the time is right for Spring doing that now. OTOH, given the level of hostility between JBoss and Spring in threads like these, chances are that that would just result in more politics and less technology.
  21. Re: Put out or shut up Rod[ Go to top ]

    Bell Berk is the only hostile one left. The others have left the building already. People like Gavin and other RHAT employees are far more civilized and are interested in cooperations & negotiations.
  22. Re: Put out or shut up Rod[ Go to top ]

    Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so.
    Ditto!! I think this is the pot calling the kettle black. Right tool for the job, -Robert
  23. Re: Put out or shut up Rod[ Go to top ]

    The big question is when - if ever - the time is right for a project to join a standardization effort. Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so. It needed to 'beat' the standards (EJB, JDO) before people took it seriously and before it could make a serious contribution to JEE.
    Yes, that's very fair, there are indeed times when it makes sense to oppose "bad" standards, when that is the best way forward to "good" standards. The problem we have is that everyone has their own ideas on which standards are "good", and which are "bad".
    Maybe the time is right for Spring doing that now. OTOH, given the level of hostility between JBoss and Spring in threads like these, chances are that that would just result in more politics and less technology.
    I just want to say that you shouldn't confuse individual people's opinions with the strategy of a whole company. JBoss is deeply committed to improving and furthering the EE standards and we are deeply committed to working productively with anyone who shares the goal of a better Java EE. I've certainly disagreed with the Spring team on several issues and, indeed, there was a time when I was extremely upset at Rod/Juergen for not supporting the EJB3 effort. You might wonder why? Well, what many people don't realize is just how close the EJB3 spec came to being killed off. If that would have happened, we would have been left with: * no JPA (we would have the horrid JDO document instead) * the misdesigned and outdated EJB2 as the only welldefined component model for Java EE This might have been great for JDO vendors and also for Interface21, but I simply do not believe it would have been good for Java. I understand that from the outside it might look as if EJB3 and JPA were simply inevitable and destined to "be", but at the time they were not. You had the editor of this site running continuous stream of bad press about EJB3, public criticism/smears and private political jockeying from JDO vendors, public criticism from the Spring team, etc. And the vicious personal smears and lies which were whispered about folks like Linda, myself and others during this period were disgusting: there are certain people in the Java community who's mendacity I will simply never forgive. But the smearing and lying was definitely not done by folks at i21, and I've have never had any reason to suspect them of acting in any way remotely dishonorably. I have no doubt that from their point of view, their opposition to EJB3 and JPA was entirely principled, even if I disagree with their reasoning and conclusions. And, in the end, the EJB3 team got what we wanted, and in my view "rescued" EE5 from total irrelevance. We even ended up bringing some of the JDO community on board. Eventually, even i21 had to come out in support of JPA ;-) So there's no reason for us to be bitter. And, frankly, that was all a long time ago now and it's well past time to move on. We're building a totally killer component model for Java in the Web Bean's expert group, and we welcome anyone who wants to be involved!
  24. Re: Put out or shut up Rod[ Go to top ]

    I've certainly disagreed with the Spring team on several issues
    Oh, and for the pure "I told you so" value of it: The most famous public spat between the Hibernate and Spring teams - and in which most commentators roundly condemned us for our evil jbossian ways - was over Spring's HibernateTemplate/JPATemplate and transaction abstractions. I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it. Do you think I can get an apology now from everyone who called me names during that episode? No, I didn't really expect one ;-)
  25. Re: Put out or shut up Rod[ Go to top ]

    I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it.
    Indeed, but if you also look at one of the main reasons the HibernateTemplate is outdated you'll discover SessionFactory.getCurrentSession(). Which came in Hibernate 3.X if I remember well isn't it ? So while they needed 1.5 years to realize it, you needed exactly that much time to implement the reason for them to realize it. Anyway it's history now, I suppose. Spring is still great at abstracting away transaction management (and that's IMO one of the main reasons to use Hibernate with Spring), DB exception handling and whatnot. As Hani replies to that blog post you rarely see a company that discourages usage of their APIs so that their users can remain vendor independent. Also it's good to see that you are no longer that much acid at the Spring guys as you used too (now with the new insight of EJB 3.0/JPA being eligible for shutdown I understand also the reason for that, at that specific moment, and I totally agree that JPA is a huge win and the loss of JPA would have made J2EE close to irrelevant if you take out JSP Servlet and JMS). Also I cannot stop me from observing that obscenity that seemed to have left with Mark returns in the person of another JBOSS affiliate which is Bill Burke. No matter how great JBOSS products are, I've always been a critique of that attitude.
  26. Re: Put out or shut up Rod[ Go to top ]

    Indeed, but if you also look at one of the main reasons the HibernateTemplate is outdated you'll discover SessionFactory.getCurrentSession(). Which came in Hibernate 3.X if I remember well isn't it ? So while they needed 1.5 years to realize it, you needed exactly that much time to implement the reason for them to realize it.
    Hibernate3 went final in March 2005, > 2 years ago. Nice try.
    Spring is still great at abstracting away transaction management
    Personally, I think that JTA is just great at abstracting transaction management. I'm not aware of any compelling critique of the JTA spec. So I've never really fully understood the reason for a proprietary abstraction of a standard abstraction. I mean, I kinda "get" that historically people didn't have a JTA implementation in environments like Tomcat. But that problem was easier fixed by a simple standalone JTA implementation (that would not even have to support distributed transactions). I'm not sure why someone didn't just do that years ago... And I also kinda "get" that people wanted declarative tx demarcation without being forced into the legacy EJB2 programming model. And Spring did a great job of providing that. But surely that was best viewed as an interim solution to a temporary problem, where the "final" fix was to improve the EE specs, rather than a justification for tossing the standards alltogether?
  27. Re: Put out or shut up Rod[ Go to top ]

    Also I cannot stop me from observing that obscenity that seemed to have left with Mark returns in the person of another JBOSS affiliate which is Bill Burke. No matter how great JBOSS products are, I've always been a critique of that attitude.
    I can see why people think like this, but, on the other hand, I can't say that I think the usual corporate-smug/condescending-nicey-nicey-political-correctness is necessarily more admirable. I personally would rather deal with people who are direct and tell me what they think to my face. I'm just more comfortable that way. I understand that many other people don't feel the same as me. But, it is a fact that the culture of JBoss has always been one of extreme directness (even more so internally than in public). The oldschool thecore at jboss dot org email flamewars are legendary, and remembered with great affection by everyone here. I only really recall one instance of a JBoss employee being "censured", for an email that was really, really out there... However, this culture is changing somewhat since the acquisition. If you knew Bill personally, you'd know what a super-nice guys he is. But in my opinion that doesn't come across at all in his contributions to discussions on TSS ;-) One thing you should know is that Bill is waaay more scathing of me in IM than he ever is of anyone here on TSS! Damn, if you think he's rough on his competitors, you do *not* want to try being his friend! :-) Anyway, there's lots of reasons for us to get more "corporate" here. But I still prefer the old, fearless, JBoss :-)
  28. Re: Put out or shut up Rod[ Go to top ]

    Also I cannot stop me from observing that obscenity that seemed to have left with Mark returns in the person of another JBOSS affiliate which is Bill Burke. No matter how great JBOSS products are, I've always been a critique of that attitude.


    I can see why people think like this, but, on the other hand, I can't say that I think the usual corporate-smug/condescending-nicey-nicey-political-correctness is necessarily more admirable. I personally would rather deal with people who are direct and tell me what they think to my face. I'm just more comfortable that way. I understand that many other people don't feel the same as me.

    But, it is a fact that the culture of JBoss has always been one of extreme directness (even more so internally than in public). The oldschool thecore at jboss dot org email flamewars are legendary, and remembered with great affection by everyone here. I only really recall one instance of a JBoss employee being "censured", for an email that was really, really out there... However, this culture is changing somewhat since the acquisition.

    If you knew Bill personally, you'd know what a super-nice guys he is. But in my opinion that doesn't come across at all in his contributions to discussions on TSS ;-) One thing you should know is that Bill is waaay more scathing of me in IM than he ever is of anyone here on TSS! Damn, if you think he's rough on his competitors, you do *not* want to try being his friend! :-)

    Anyway, there's lots of reasons for us to get more "corporate" here. But I still prefer the old, fearless, JBoss :-)
    Gavin most people aknowledge jboss contributions, they are very high and wide and phantastical, but jboss has been and basically is stil regarded as the one entity (conglomerate or whatever) which is know to be rude to their own users. And there are people who outright refuse to use anything from jboss due to not wanting to be insulted for questions. Pretty much everyone here in this list has been insulted one or several times in the jboss forums by the jboss people themselves. I personally think, while your technical contributions are excellent, the attitude has cost you guys a lot more commercial customers in the long run than it helped you out. I personally keep the attitude no matter how dumb a question is or how much stress you have on your own, never ever insult your users openly, you can curse about them internally but never ever do it in the public, this simply is unprofessional. Even if you probably are a bunch of really nice guys - and I know you are, it does not really look that way in the open. Anyway I am glad the situation is changing since the merger also internally you guys have a lot to gain for being more friendly ;-)
  29. Re: Put out or shut up Rod[ Go to top ]



    Gavin most people aknowledge jboss contributions, they are very high and wide and phantastical, but jboss has been and basically is stil regarded as the one entity (conglomerate or whatever) which is know to be rude to their own users.
    And there are people who outright refuse to use anything from jboss due to not wanting to be insulted for questions.

    Pretty much everyone here in this list has been insulted one or several times in the jboss forums by the jboss people themselves. I personally think, while your technical contributions are excellent, the attitude has cost you guys a lot more commercial customers in the long run than it helped you out.

    I personally keep the attitude no matter how dumb a question is or how much stress you have on your own, never ever insult your users openly, you can curse about them internally but never ever do it in the public, this simply is unprofessional. Even if you probably are a bunch of really nice guys - and I know you are, it does not really look that way in the open. Anyway I am glad the situation is changing since the merger also internally you guys have a lot to gain for being more friendly ;-)
    Werner, thanks for these words. I only can confirm that. The track record of very crude and arrogant postings by JBoss officials to user forums or websites like this is really sort of impressive. And I think that this is really a major reason why many people feel more comfortable with sticking to a proprietary solution from one vendor (Spring) than using standards-compliant software from JBoss (even though this may be irrational. But hey, we may be nerds and geeks, but still human beings, aren't we?)
  30. Give me a break!!![ Go to top ]

    Now we even have the sensitive ponytail guys weighing in on the discussion! Arrr!!! I've never heard of technology decisions being made due to the lack of discretion of the developers. Sure, we all hear some of the "mere mortals" comments and maybe a perceived slight but we can take it. I welcome the criticism of my work and so should you. You have to admire their passion for Java and trying to keep people from messing it up. Also, I appreciate the responses on their forum no matter how direct. They foster their community better through their forums than most companies do through their support department! I'm very excited about Java EE 6. With this much passion behind it's creation, you know it will be a solid contribution to the community.
  31. Re: Put out or shut up Rod[ Go to top ]

    Pretty much everyone here in this list has been insulted one or several times in the jboss forums by the jboss people themselves. I personally think, while your technical contributions are excellent, the attitude has cost you guys a lot more commercial customers in the long run than it helped you out.
    If there's any "history" I could change, it would be this. But I believe we're doing much better today in this respect than we were 2 years ago. My team is managing to handle the traffic in the Seam forum without the problems that plagued the Hibernate forums. OTOH, I can turn it around and say: pretty much everyone at JBoss has been insulted hundreds or thousands of times in jboss forums, Hibernate forums, TSS, blogs, etc. This attitude has cost the community by turning us into bitter, paranoid, defensive, nervous wrecks (at times). And there's always been a template for getting good support on any open source forum or list. It goes like this: ----------- Hi everyone, I just started using Hibernate/Spring/Seam/JBoss/Wicket, and I'm really enjoying the experience. Thanks for the good work! But, there's one thing that I can't seem to figure out / make work / understand / get right - ..... [provide sufficient information about your problem here] Thanks! ----------- Perhaps that seems like I'm asking you to kiss ass. Well, no, I actually don't need continuous asskissing. I'm merely pointing out that this "safe option" is always available to you in any opensource forum, if you're sensitive to "direct" responses. But I don't disagree that there was a period where we did a very bad job in this respect.
  32. Re: Put out or shut up Rod[ Go to top ]

    Perhaps that seems like I'm asking you to kiss ass. Well, no, I actually don't need continuous asskissing. I'm merely pointing out that this "safe option" is always available to you in any opensource forum, if you're sensitive to "direct" responses.

    But I don't disagree that there was a period where we did a very bad job in this respect.
    Actually Gavin thanks for those words, I noticed a significant change for the better the recent months/year. The main problem I see is, once something becomes successfull you have the usual percentage of whiners who just are unfriendly and being stressed out doesnt really help to keep calm. You are right it is really hard to keep your mood down in such a situation.
  33. Re: Put out or shut up Rod[ Go to top ]

    I can't say that I think the usual corporate-smug/condescending-nicey-nicey-political-correctness is necessarily more admirable. I personally would rather deal with people who are direct and tell me what they think to my face. I'm just more comfortable that way. I understand that many other people don't feel the same as me. But, it is a fact that the culture of JBoss has always been one of extreme directness (even more so internally than in public). The oldschool thecore at jboss dot org email flamewars are legendary, and remembered with great affection by everyone here.
    ... earlier ...
    And the vicious personal smears and lies which were whispered about folks like Linda, myself and others during this period were disgusting: there are certain people in the Java community who's mendacity I will simply never forgive.
    The passion almost kills me.
  34. Re: Put out or shut up Rod[ Go to top ]

    Indeed, but if you also look at one of the main reasons the HibernateTemplate is outdated you'll discover SessionFactory.getCurrentSession().
    No, that is not the reason why the HibernateTemplate/JpaTemplate is outdated. Getting access to the current Session/EntityManager (via the lookup or with injection) is AFAIK not what the template is responsible for. It would indeed be a horrid design if you'd have to use proprietary Spring API (wrapping the JPA standard!) only to get a Session/EntityManager injected. The template simply wraps the API and provides exception handling. The few additional methods and shortcuts added by the template are certainly not worth the added learning curve and confusion this is causing for newbies who don't know what API they are using. I could quote numerous posts from the Hibernate user forum here but I'm too lazy. I actually think that this misconception ("I need the template to get the Session!") is what kept it alive for so long, even years after H3 was released.
  35. Re: Put out or shut up Rod[ Go to top ]


    Indeed, but if you also look at one of the main reasons the HibernateTemplate is outdated you'll discover SessionFactory.getCurrentSession().


    No, that is not the reason why the HibernateTemplate/JpaTemplate is outdated.

    Getting access to the current Session/EntityManager (via the lookup or with injection) is AFAIK not what the template is responsible for. It would indeed be a horrid design if you'd have to use proprietary Spring API (wrapping the JPA standard!) only to get a Session/EntityManager injected. The template simply wraps the API and provides exception handling. The few additional methods and shortcuts added by the template are certainly not worth the added learning curve and confusion this is causing for newbies who don't know what API they are using. I could quote numerous posts from the Hibernate user forum here but I'm too lazy.

    I actually think that this misconception ("I need the template to get the Session!") is what kept it alive for so long, even years after H3 was released.
    Just out of curiosity, the thing is dead nowadays anyway, I personally thought the templates to be an excellent encapsulation for its time, it is obsolete now. At least if you use orm (pure JDBC is another issue) But this thing is such a small aspect of Spring, why the discussions about it for such a long time? (I havent given them a thought for years, being such a small api part of the entire framework) After all the templates influenced parts of your work as well, like making the hibernate exceptions unmanaged or providing a simple SessionFactory.getCurrentSession(). And yes I second that the Templates themselves are somwhat redundant since you can inject the session and you could do it back then as well and really obsolete by now. But what strikes me is that it still is discussed openly now. Anyway guys, just to sum my somewhat harshful posts in this threads up. It is really a great stuff you guys have done in the past and you are still doing (Seam is one of those examples, same goes for your work on JEE which finally is usable and good) So I hope those endless flamewars will come to an end. And thanks a lot for the work you have done guys, the same goes for the Spring people, their stuff I also have used often. Btw. I agree also with Gavins previous post here, I have seen a significant change in attitude in the recent months since the RedHad merger, the direction also from an attitude side is much more professional than it used to be.
  36. Re: Put out or shut up Rod[ Go to top ]

    I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it.


    Indeed, but if you also look at one of the main reasons the HibernateTemplate is outdated you'll discover SessionFactory.getCurrentSession(). Which came in Hibernate 3.X if I remember well isn't it ? So while they needed 1.5 years to realize it, you needed exactly that much time to implement the reason for them to realize it. Anyway it's history now, I suppose. Spring is still great at abstracting away transaction management (and that's IMO one of the main reasons to use Hibernate with Spring), DB exception handling and whatnot. As Hani replies to that blog post you rarely see a company that discourages usage of their APIs so that their users can remain vendor independent.

    Also it's good to see that you are no longer that much acid at the Spring guys as you used too (now with the new insight of EJB 3.0/JPA being eligible for shutdown I understand also the reason for that, at that specific moment, and I totally agree that JPA is a huge win and the loss of JPA would have made J2EE close to irrelevant if you take out JSP Servlet and JMS).

    Also I cannot stop me from observing that obscenity that seemed to have left with Mark returns in the person of another JBOSS affiliate which is Bill Burke. No matter how great JBOSS products are, I've always been a critique of that attitude.
    Actually my personal opinion about having made the Templates redundant, is generally @Transactional as standardized transaction demarkation annotation and jpa as becoming slowly a good solid orm foundation really made them redundant so from a personal point of view it is not even 1.5 years, but from a current perspective it is a good idea to slowly declare them deprecated. (The deprecation probably will happen once the majority of users has left JDK 1.4) SessionFactory.getCurrentSession() just was the first cornerstone to fix one of the issues, fixed by the templates, from outside. And an important one. Just my personal opinion though.
  37. Re: Put out or shut up Rod[ Go to top ]

    yes.. spring is a thin framework. We had a framework coded for the company much like spring back in yr 2001 for web presentation . This was used with xsl presentation layer. Also toplink was the original one: http://toplink.waldura.com/TopLinkVsHibernate Again jsf copies tapestry. May be opinion ibm/bea is better than jboss.. Cheers, hari_sujathan at yahoo dot com Blr, India Don't marry, be happy: http://www.nomarriage.com
  38. Re: Put out or shut up Rod[ Go to top ]

    yes.. spring is a thin framework. We had a framework coded for the company much like spring back in yr 2001 for web presentation . This was used with xsl presentation layer.

    Also toplink was the original one: http://toplink.waldura.com/TopLinkVsHibernate

    Again jsf copies tapestry.

    May be opinion ibm/bea is better than jboss..



    Cheers,
    hari_sujathan at yahoo dot com
    Blr, India
    Don't marry, be happy: http://www.nomarriage.com
    Ahem... Toplink was the first, then kodo then Hibernate, Tapestry copied webobjects to some degree and the jsf took some concepts of tapestry (among many others) This is called incremental evolution, or progress ;-)
  39. Re: Put out or shut up Rod[ Go to top ]

    I've certainly disagreed with the Spring team on several issues


    Oh, and for the pure "I told you so" value of it:

    The most famous public spat between the Hibernate and Spring teams - and in which most commentators roundly condemned us for our evil jbossian ways - was over Spring's HibernateTemplate/JPATemplate and transaction abstractions.

    I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it.

    Do you think I can get an apology now from everyone who called me names during that episode?

    No, I didn't really expect one ;-)
    Mhh just from the view of a spring user, back then I saw the templates as heavens sent, they encapsuled some of the nastyiness of various incompabible orm layers into a rather common API and also helped to encapsule the applications from the rather nasty ejb2 to some degree. Nowadays everyone seems to settle on @Transactional for transaction control and JPA as final (for now) common ORM API ground they indeed are obsolete, but there was a time, especially in pre JDK 5 and pre JPA days when they were needed to gain at least some api independend transactional and orm isolation. I also recall some of the jboss guys going into a rage over it because it was easier to replace the orm layer that way (That it helped people to move mostly to hibernate) from other solutions was mostly overseen. The templates are indeed now obsolute I agree with you and also (if they really said it) the Spring guys here, but they had their place in the time they were programmed.
  40. Re: Put out or shut up Rod[ Go to top ]

    I also recall some of the jboss guys going into a rage over it because it was easier to replace the orm layer that way (That it helped people to move mostly to hibernate) from other solutions was mostly overseen.
    And that's why we worked so hard on providing a standardized API (JPA) on top of Hibernate, because we don't like people switching implementations? Uh?
  41. Re: Put out or shut up Rod[ Go to top ]

    I also recall some of the jboss guys going into a rage over it because it was easier to replace the orm layer that way
    (That it helped people to move mostly to hibernate) from other solutions was mostly overseen.


    And that's why we worked so hard on providing a standardized API (JPA) on top of Hibernate, because we don't like people switching implementations? Uh?
    Three years are a long time, things change ;-). I personally can remember a discussion on the jboss mailinglist I had with exactly you Christian (I used hibernate in a project back then in combination with spring) where we exactly had this discussion, and you pointed out that usually you never switch orm layers, and I said there often are reasons why you have to do it. (Some are political some can be technical) I do not say you have a problem now, obviously you dont, but I am not sure if you had back then, but JBoss business was different than it is now. The templates were not the ideal solution back then but they were the most neutral ones at that time, and you guys didnt provide a lot to neutralize the argument that they were obsolete until a real vendor neutral solution came along (which you took great part in it btw. credits where credits are due!) But before that endless discussions afair, and no real replacement ;-) I dont think that the answer of Gavin, is fully correct, that now that the Spring people have declared Templates obsolete -> I told you so now apologize, really is the correct answer. Times have changed things have changed the Templates were a good solution for its time, but they are not anymore! So what? This is not a big deal to whine about anymore. I can remember an article from about two years ago, which was titled why Spring is obsolete, the entire article focused on the orm aspect where Hibernate added some things which made the templates somewhat redundant, but the article ommitted entire other encapsulation aspects of spring, like non jta transaction handling encapsulation of services, ioc, aop, etc... you name it. I have yet to see one of the spring guys whine openly in this forum about the article which just took one aspect and then pushed a title, this stuff is not needed anymore ;-) Just my two cents regarding attitudes.
  42. Re: Put out or shut up Rod[ Go to top ]

    Gavin,
    I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it.
    For the record: SessionFactory.getCurrentSession() was introduced in Hibernate 3.0.1, so post 3.0 final, which is why Spring 1.2 - released at the same time - didn't support it right away. We introduced support and documentation for the getCurrentSession() style of writing Hibernate DAOs in Spring 1.2.2, released in July 2005. So Spring has been supporting this native Hibernate3 style right from the start; same for JPA's EntityManager style in Spring 2.0. We did realize and document this as soon as possible, while supporting the template style for our existing users who preferred to keep using it (in particular for existing codebases). In Spring 2.0, we added support for aspect-driven data access exception translation - which was designed for native ORM DAOs such as ones in Hibernate3 style or JPA style! I assume that most Spring users finally learnt about those DAO styles at that time, since we put stronger emphasis on it. That was in mid 2006. Alef's recent blog posting simply reiterated the overall story there. Christian,
    I actually think that this misconception ("I need the template to get the Session!") is what kept it alive for so long, even years after H3 was released.
    That might well be the case. Lots of people were used to HibernateTemplate from the Hibernate 2.x days, so simply kept using it for Hibernate 3.x and might not have realized that an alternative style was there already. On the other hand, if the template worked for them, they might simply not have felt a need for change in the first place... In any case: As I pointed out, Spring included documentation on both DAO implementation styles very early. I've also personally been pointing out both options ever since. (Check my slide deck at http://www.jugs.ch/html/events/2005/spring2.html, for example, which includes samples for both styles.) Apparently it took 1.5 years for JBoss to realize Spring's support there? Juergen
  43. As I pointed out, Spring included documentation on both DAO implementation styles very early.
    At the end of 2003 I started keeping an eye on the spring framework (don't remember if it was already called like this at that time), and in the first months of 2004 I started playing with it and, starting from the samples then provided with the distribution, I prototyped a number of things which would become our current e-commerce architecture. The data access layer hasn't changed in its major aspects and there is not a single hibernate template (because I didn't like them very much, even if I find them very practical at times). We simply used a different approach, based on hibernate session-initialization proxies. The speed this allowed us at the startup of our project was considerable.
  44. Re: Put out or shut up Rod[ Go to top ]

    And to think that I always felt like a big mean jerk for telling people those templates were stupid/useless.... I guess using them was a safe bet in theory, but it's like eating food or visiting a different country....You have to have the balls to embrace and try it out as the author intended or you'll never be able to fully realize the benefits.. Right? Of course we can probably start to find similar things happening in the area of XML && annotations. Again - another clear winner has emerged but we're going to stick to our guns because well....That's the safest thing at this point. (even if everyone knows it's not the best thing)
    ...I would like to just mention, FTR, that the Spring team recently announced on their blog that HibernateTemplate isn't needed anymore. It only took one and a half years for them to realize it.

    Do you think I can get an apology now from everyone who called me names during that episode?

    No, I didn't really expect one ;-)
  45. Re: Put out or shut up Rod[ Go to top ]

    I just want to say that you shouldn't confuse individual people's opinions with the strategy of a whole company.
    Ok, sure. It's sometimes hard to distinguish people voicing their opinions as a member of an organization or as mere individuals. Though 'visible' individuals bare some responsibility in this as well. Btw, in the same fashion, people keep confusing individuals mentioning Wicket who we - the team behind the framework - often don't even know. Not that I mind people do mention the framework, but we often undeservedly get the flak for promoting too aggressively and hijacking threads. Maybe it's just that the whole Java community has toes that are too long ;)
  46. Re: Put out or shut up Rod[ Go to top ]

    Btw, in the same fashion, people keep confusing individuals mentioning Wicket who we - the team behind the framework - often don't even know. Not that I mind people do mention the framework, but we often undeservedly get the flak for promoting too aggressively and hijacking threads. Maybe it's just that the whole Java community has toes that are too long ;)
    Shrug, you've got passionate users. Good for you.
  47. Re: Put out or shut up Rod[ Go to top ]

    Btw, in the same fashion, people keep confusing individuals mentioning Wicket who we - the team behind the framework - often don't even know. Not that I mind people do mention the framework, but we often undeservedly get the flak for promoting too aggressively and hijacking threads. Maybe it's just that the whole Java community has toes that are too long ;)


    Shrug, you've got passionate users. Good for you.
    Indeed, good for us.
  48. Desperate Housewives[ Go to top ]

    There is more drama on this topic than all my sister in-laws rolled together (and I have seven). I guess it is reassuring that there is still so much passion in our geeky industry. I know I've blown my lid a few times on this board myself. With success comes envy, with envy comes scorn. Fear leads to anger, anger to hate, yadda yadda. Anyway speaking for some of us on the ground who just like using solid frameworks, thanks for the effort. I hope you'll continue to fight toward the common goal of making Java development easier.
  49. Re: Put out or shut up Rod[ Go to top ]

    The big question is when - if ever - the time is right for a project to join a standardization effort. Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so. It needed to 'beat' the standards (EJB, JDO) before people took it seriously and before it could make a serious contribution to JEE.


    Yes, that's very fair, there are indeed times when it makes sense to oppose "bad" standards, when that is the best way forward to "good" standards.

    The problem we have is that everyone has their own ideas on which standards are "good", and which are "bad".


    Maybe the time is right for Spring doing that now. OTOH, given the level of hostility between JBoss and Spring in threads like these, chances are that that would just result in more politics and less technology.


    I just want to say that you shouldn't confuse individual people's opinions with the strategy of a whole company. JBoss is deeply committed to improving and furthering the EE standards and we are deeply committed to working productively with anyone who shares the goal of a better Java EE.

    I've certainly disagreed with the Spring team on several issues and, indeed, there was a time when I was extremely upset at Rod/Juergen for not supporting the EJB3 effort. You might wonder why?

    Well, what many people don't realize is just how close the EJB3 spec came to being killed off. If that would have happened, we would have been left with:

    * no JPA
    That is still a subset of JDO.
    (we would have the horrid JDO document instead)
    That maybe you never read.

    * the misdesigned and outdated EJB2 as the only welldefined component model for Java EE

    This might have been great for JDO vendors and also for Interface21, but I simply do not believe it would have been good for Java.
    Why ?


    I understand that from the outside it might look as if EJB3 and JPA were simply inevitable and destined to "be", but at the time they were not. You had the editor of this site running continuous stream of bad press about EJB3, public criticism/smears and private political jockeying from JDO vendors
    Where are those ? Guido
  50. Re: Put out or shut up Rod[ Go to top ]

    We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler.

    Bill


    The big question is when - if ever - the time is right for a project to join a standardization effort. Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so.
    I totally agree. Standardization processes should be about standardizing successful innovations. I think the Spring framework is mature enough to join a standards effort, don't you?
    It needed to 'beat' the standards (EJB, JDO) before people took it seriously and before it could make a serious contribution to JEE. Maybe the time is right for Spring doing that now. OTOH, given the level of hostility between JBoss and Spring in threads like these, chances are that that would just result in more politics and less technology.
    Aligning EE 6 with pure IoC is definately where JBoss wants to go for EE 6, so I don't think there would be a problem working together. I actually think JBoss and Interface 21 would make pretty good partners in pushing EE 6 in the right direction. This brings me back to my original
  51. Re: Put out or shut up Rod[ Go to top ]

    We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler.

    Bill


    The big question is when - if ever - the time is right for a project to join a standardization effort. Do you think Hibernate would ever have made the impact it made if it would have tried to play the standards game from a very early start? I don't think so.


    I totally agree. Standardization processes should be about standardizing successful innovations. I think the Spring framework is mature enough to join a standards effort, don't you?

    It needed to 'beat' the standards (EJB, JDO) before people took it seriously and before it could make a serious contribution to JEE. Maybe the time is right for Spring doing that now. OTOH, given the level of hostility between JBoss and Spring in threads like these, chances are that that would just result in more politics and less technology.


    Aligning EE 6 with pure IoC is definately where JBoss wants to go for EE 6, so I don't think there would be a problem working together. I actually think JBoss and Interface 21 would make pretty good partners in pushing EE 6 in the right direction.

    This brings me back to my original
    Whoops...forgot to finish my thought on the reason for my original emotional outburst. Decided to blog about it instead....Flames welcome and encouraged.
  52. Re: Put out or shut up Rod[ Go to top ]

    I think the Spring framework is mature enough to join a standards effort, don't you?
    I do.
  53. Re: Put out or shut up Rod[ Go to top ]

    We did it with Hibernate and now with Seam and we found that really embracing standards instead of giving them lip service is a great business enabler.
    Well, for someone who's admitting it took years to learn that lesson, you are being typically harsh with whole STFU thing. Really, trying to find some sincerity in here somewhere. Right tool for the job, -Robert
  54. Re: Put out or shut up Bill[ Go to top ]

    We did it with Hibernate
    Still perpetuating the "Hibernate is JPA" thing ? Why is it that JPA is such a weak standard ? Maybe because you couldnt get Hibernate to meet existing standards and wanted to dilute things down just in the attempt to say "Hibernate standards based" perhaps
  55. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.
    You're over the line, Bill. In your position, you have a responsibility to shoot for a better level of discourse than this.
  56. Re: Put out or shut up Rod[ Go to top ]

    Just saw this today, and couldn't agree more Corby. Bill - learn some manners, your tone and words are shameful. Make an argument instead of these spiteful comments. Mark
  57. Re: Put out or shut up Rod[ Go to top ]

    This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome.
    Hmm.... I thought he was just working on another defacto-standard, like what you guys did in the early days with Hibernate in the face of JSR-243 and JSR-220. Now surely, Bill, you wouldn't criticize someone for doing that! Right tool for the job, -Robert
  58. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor?
    I find it interesting that JBoss would want Spring to be standardized, so that they can finally provide what it offers, too. Anyway: how can a block of open source software be "controlled by one vendor"? It can be forked, it can be reimplemented by a competing solution offering the same interfaces and configuration mechanisms (which Spring can't change because of compatibility), it can be extended...
    Until then, who cares what you think.
    Uhm. Last time I checked, Rod was among the most influent persons in the java enterprise space, and one of those with the most interesting opinions.
    Put your money where your mouth is or STFU
    ...
  59. standards[ Go to top ]

    In my past j2ee projects, I used all the j2ee libraries that humans have invented: ejb 2.x/3, spring, Hibernate/TopLink, JSF..... IMHO, I succeed faster using a simple and modular SW, simple to test and to configure and use, but still powerful and flexible, regardless of the standards. Standards are more important for the vendors. If a standard does not solve a problem, (but creates another problem), why should I use it? I think old j2ee standards were not a good choice. I think standards are not so important from the point of view of a developer: why should I use a standard if it is ugly to use and difficult to learn and debug? If the standard is good, I will use it, if not, I will use some other SW. BTW some years ago the standard was CMP, not Hibernate! Now Hibernate is the standard, and CMP is deprecated. I hope EE6 will be a good standard....only for the standard it self!
  60. Re: standards[ Go to top ]

    Now Hibernate is the standard, and CMP is deprecated.
    While CMP mostly certainly is deprecated, Hibernate is actually an implementation of a standard (JPA) and there are many other implementations of the very same standard, and also implementations of other standards for the same programming domain.
  61. Re: Put out or shut up Rod[ Go to top ]

    So, since Java EE 6 "Gets it Right" does this mean you're going to bring Spring to a standards body so that its not controlled by one vendor? Until then, who cares what you think. This talking standards out of one side of your mouth and pushing proprietary software outside the other becomes tiresome. Put your money where your mouth is or STFU.

    Regards,

    Bill
    Geez, what an ******* you are. You guys must surely be threatend by Spring. Who cares what *you* think?
  62. Extensibility[ Go to top ]

    Extensibility The new specification proposal suggests offering more service provider interfaces and extension points, meaning that technologies can "cleanly layer on or plug in to" Java EE application servers.
    I blogged about this awhile back about how we can do this very thing: Open up Java EE 6
  63. Lately I've been using Spring and honestly I don't agree that IOC is better. It's definitely different, but to claim it is inherently better is purely an opinion and not a fact. Using AOP to inject behavior into code or glue things together is useful, but it's not appropriate for all situations. I see benefits of each approach and I also see the weaknesses. For example, what happens if you don't have access to the server and can't modify the configuration. Or worse, you don't have access to the server logs, so debugging requires calling the support people to look at the logs for you. If the application doesn't use IOC or AOP to inject dependencies, you know it's your code that blew up. Using a framework controlled by some other group within the company and deploying to an environment where you have zero control, using IOC "can" make things more difficult. Of course, this isn't because Spring is bad. It's not Spring's fault that some environments are restrictive. In a restrictive and slow environment, I'd much rather code the dependencies than rely on a framework. Debugging at 1a.m. on a saturday because some configuration in the framework is wrong isn't my idea of easier or lighter. When people ask me whether I would use Spring, my first response is "do you have control over the server?" if you don't have control over the server or the framework, you're better off not using an IOC approach. of course, one could argue the problem isn't Spring and that would be correct. Technology is not a solution in and of itself. People need to consider whether the tool fits the business. I'm sure those who work in large US corporations with very restrictive policies and procedures have seen these types of conditions. my bias 2 cents peter
  64. Actually I'm not 100% convinced that the EE6 proposal really does get it right, though it is certainly a step in the right direction. What we've been quietly pushing for behind the scenes is not the idea of "profiles", but rather the idea that each of the individual specifications in the Java EE platform may be independently implemented and distributed, independently of a full EE implementation. I can see that "profiles" are useful from the following points of view: * for sales, "profiles" give vendors a nice way to do price discrimination and make "larger" "enterprise" customers pay more than "smaller" ones * for vendors (like Interface21) who would like to distribute a Java EE server, but don't yet have all the "bits", it lowers the barrier to entry into the space But I don't see either of these as especially beneficial to users (well, users would benefit from increased competition and choice, perhaps). OTOH, a much greater degree of choice, competition, and flexibility would be obtained if it were possible to implement any EE spec and distribute it, independently of any special "profile". As I understand it, there are two objections to this approach: * The EE TCK is monolithic, and thus it is not welldefined what it means to comply to an individual spec - only compliance with the whole EE platform is welldefined. * some of the interfaces between different specs are not welldefined (eg, perhaps its not clear how to plug vendor X's JTA into vendors Y's EJB container) In my view, we should be trying to solve these problems! OK, I understand that that is potentially a lot of work, and might require a rev of every spec Java EE, but I think it would be worth doing, at least as a longterm direction from Sun, even if not as an immediate goal for EE6. So, I think maybe Rod's rejoicing is a little premature. (Though I certainly see how this "profiles" stuff is a good for his business, and also for ours.) Well, I might be wrong on this...
  65. OTOH, a much greater degree of choice, competition, and flexibility would be obtained if it were possible to implement any EE spec and distribute it, independently of any special "profile". As I understand it, there are two objections to this approach:

    * The EE TCK is monolithic, and thus it is not welldefined what it means to comply to an individual spec - only compliance with the whole EE platform is welldefined.

    * some of the interfaces between different specs are not welldefined (eg, perhaps its not clear how to plug vendor X's JTA into vendors Y's EJB container)

    In my view, we should be trying to solve these problems!
    Once again, OSGI could be the answer. There shouldn't be a need for profiles, just let the developers choose which server and the set of components they need for each project, all in a vendor-independent way, mixing and matching at their will. The benefits would be huge, a total revolution in JEE in many aspects, since this would mean less "power" to the server vendors, a shift of focus to the component makers, and JEE servers would finally and completely become commodity. But I am not sure if all server vendors would be willing to give up such level of control on their JEE platform as they have today, mainly the closed-source ones.
  66. I am switching to Microsoft[ Go to top ]

    Good god these threads are pointless. I am switching to microsoft to avoid all the finger pointing and history writing.
  67. anti-JEE5[ Go to top ]

    Thats great that you can wait for the 2-3 year build-out of another rev. of the app servers to support the "new" JEE specification, but last time I checked we were just beginning the build-out of the JEE5 spec. for app server implementations - - it is entirely self-serving (i.e. counter-productive) to avoid JEE5... From a business standpoint, it serves only Interface21 to pit JEE5 against JEE6, as u have done with this post, apparently your exalted role (as evidence from your many backers) does not include diplomacy, and I would be glad to argue that this "JEE6 Gets it Right" theory does more damage to Java penetration in the enterprise than anything Bill Burke will ever say, who is, as an aside, completely discredited via passion... That gives a lot of credit to Spring, but as I have seen in the past few months of debating with people like Solomon Duskis among many other Spring supporters, you do have some responsibility in this process, and that is my main point of contention...I understand u have corporate responsibilities to promote your platform, and this is naturally an effort to do at the expense of EJB3...but to undermine JEE implementations coming on to the market is a great under-achievement by Interface 21... I have seen Spring support across most the JEE5 app servers that I have looked at, including Glassfish, Geronimo, and WebLogic, although I am sure since JBoss is taking Sun's 'Metro' JWS implementation, there is the capability to have Spring work with JBoss as well...what prevents Interface21 from working within the JEE model today, rather than splintering the community, like u have done with this post?... The bottom-line is that u missed an opportunity to grow the market, and chose the less advanced position by dis-crediting JEE5, too bad...but I think your intended effort to bring about a Spring v. JBoss competitive front has been accomplished, so maybe u have satisfied your own motivations... IMO, i see JBoss and Glassfish working on app/component portability and WebLogic and WebSphere working with Spring on lock-in, but maybe that just serves to enhance an already unfortunate flame-war...
  68. Re: anti-JEE5[ Go to top ]

    Douglas,
    what prevents Interface21 from working within the JEE model today, rather than splintering the community, like u have done with this post?
    To be very clear on that point: We do work with the Java EE model today, just like we've always been working with 'good old' J2EE! Spring 2.x works very nicely on Java EE 5 servers, as you pointed out yourself. And it's not just the server vendors aiming for that, it's of course ourselves aiming for close integration as well. Java EE 5 is a first-class runtime environment for Spring. Have a look at what we're doing with Spring 2.1: A major theme behind that release is close integration with Java EE 5, which includes support for JSR-250 annotations (as embraced by Java EE's component models) in Spring-managed beans, integration with JSF 1.2 etc. And we had full JPA support in Spring 2.0 already, playing nicely with standalone JPA as well as JPA in a Java EE 5 environment. We also keep supporting present mainstream environments: Spring 2.1 remains compatible with JDK 1.4 and J2EE 1.4, which we consider very important at this point. We have always been very pragmatic about this; we recognize that J2EE 1.4 environments such as WebLogic 9 and WebSphere 6 will be around for years to come. Spring 2.x will keep bringing new technology onto those established platforms! That said, Java EE 6 of course shows an interesting trend: openness towards technologies which live on the Java EE platform instead of being an inherent part of it. Consider what this really means: It's not all about APIs being *included in* the EE platform but rather also about frameworks *building on* the EE platform. The latter is what Spring has been doing for years now, of course... Juergen
  69. Re: Juergen[ Go to top ]

    I will look for Spring to promote what you say alongside the messages for promoting your platform. I don't see this Spring/JEE relationship as a zero-sum affair, where there are corresponding winners and losers, this is a positive step for the entire enterprise Java market. I respect what you guys are doing, and am encouraged that you are becoming a full-service business, with the funding you have received, and believe that will be good for the ecosystem of products that developers will have to choose from to work with, and be more productive. Definitive post on your part, and I would assume that you are in touch with Rod on this JEE5/6 issue, so I will reserve analysis of the shortcomings of the Spring messaging vis-a-vis JEE, as I can see that you are serious about expanding the market for enterprise Java solutions. thanks, douglas dooley
  70. VC[ Go to top ]

    I respect what you guys are doing, and am encouraged that you are becoming a full-service business, with the funding you have received, and believe that will be good for the ecosystem of products that developers will have to choose from to work with, and be more productive.
    I'm torn here. On the one hand it is definately a good thing that Interfacse21 has a very solid financial basis now. But one the other hand what's the exit strategy of the investor? Most likely the intention is that Interface21 gets acquired at some day like JBoss did (busines models based on consulting are not known to scale that well). In this case I would find it rather worrying to have several projects of mine based on proprietary technology owned by - say, aehm - Oracle, BEA, Sun or IBM..
  71. Re: VC[ Go to top ]

    I respect what you guys are doing, and am encouraged that you are becoming a full-service business, with the funding you have received, and believe that will be good for the ecosystem of products that developers will have to choose from to work with, and be more productive.


    I'm torn here. On the one hand it is definately a good thing that Interfacse21 has a very solid financial basis now. But one the other hand what's the exit strategy of the investor? Most likely the intention is that Interface21 gets acquired at some day like JBoss did (busines models based on consulting are not known to scale that well). In this case I would find it rather worrying to have several projects of mine based on proprietary technology owned by - say, aehm - Oracle, BEA, Sun or IBM..
    I wouldnt consider Spring to be a proprietary technology, the license pretty much prevents that. Sure the main developers might get bought out, but that does not prevent anyone from taking over the code and moving it forward.
  72. One thing is for sure. JEE6 will help the cause of Spring, just like EJB3 helped the cause of Hibernate.
  73. Cause - read marketing.
  74. Java EE used to be imo a vendor oriented force. Developer interests got trampled. That resulted in the famous JEE blowback. In spite of all the heat that's being generated in this and similar TSS threads there's a significant degree of light from both camps. Gavin King/Seam and Rod&J├╝rgen/Spring have imo. been very beneficial influences on the JEE space recently in driving the specs in the direction of more developer oriented architecture. I can only hope that they continue this influence in JEE 6+. (apologies to all the people who I fail to mention) Kudos to both camps. JSR standards are very valuable imo despite all the well known criticisms. The Java space is very fragmented with vendors and frameworks. Unlike the Microsoft space. JSR standards deliver much needed integration points and stability in the competition with Microsoft.