Participate or STFU Rod
Posted by billburke on July 6, 2007
I got a few people pissed at me for being a little rough with Rod Johnson on a TSS thread on how Rod feels that EE 6 is “Getting it right”. Here’s what I wrote:
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.
I later added:
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.
Some were skeptical that Interface 21 could even work together with JBoss in EE 6. 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.
So what was the underlying cause of my original emotional outburst? Rod and company have built a framework and business around tearing down various pieces of EE and replacing it with their own stuff. JBoss has taken a different approach and engaged the JCP process to improve the specifications rather than fight against them. Until Rod and company actually implement a JSR (even one!) or integrate into the JCP process, their opinions on EE 6 direction really mean nothing to me and is just a bunch of posturing. Many of us on EE 6 already know where EE 6 is “Getting it Right” because we’re the ones who pushed a lot of the bullet points in Rod’s “Getting it Right” blah blah blah.
Finally, its easy to smell like shit when you’re knee deep in it. Easier to criticize and tout how much you can do it better when you’re not involved. This is why I wish Rod would STFU, join the JCP, and actually try and fix some of the broken things. If after he’s tried, and it doesn’t work out, then fine, I’ll STFU then. I’m sure with the popularity of the Spring framework, Bill Shannon and company would welcome Rod with open arms. Such a move would have the support of JBoss and I’m sure other vendors.
July 6, 2007 at 6:14 pm
FWIW, I wasn’t one of the people who were pissed off. I was merely pointing out that there might have been good reasons why the Spring folks didn’t join the standardization effort yet. I’m not in the position to ‘defend’ them to start with anyway; it is often hard to find the technical reasons behind the smoke screen of egos and politics.
July 6, 2007 at 6:21 pm
I know Rod said he was spurned by JSR-250, the common annotations spec. So, its excusable he wasn’t involved in EE 5. I really, honestly don’t think there would be a problem in EE 6.
July 6, 2007 at 7:04 pm
Hi Bill,
It sounds like we need to rename the “Java Community Process” to the “Java Vendor (Including open source ones) Process”.
The truth is that this spat doesn’t mean a jot to the average Java developer. If you’ve spent years struggling to build real life business applications with J2EE like I have you would know.
IMO you guys are getting obsessed with your own navels, and missing the point.
Premature and poor standards help no one other then vendors who want to create a gauranteed market for sub-standard tools.
What people want is tools that do the job, and on this point I would have to agree with Rod, although I agree that perhaps he isn’t being totally open about his motives.
Personally, I believe the issues with JEE stem from design flaws in the Java language itself, but if a Java Enterprise Component Framework that is simple, and productive and does the job arrives on the seen, then why bother with J2EEX? In such a scenario why sit in the shit (your words not mine :^))?
OSGi maybe?
Or better still fix Java.
July 6, 2007 at 7:33 pm
Thanks for responding. I enjoy a good heated argument. Anyways…
The truth is that this spat doesn’t mean a jot to the average Java developer. If you’ve spent years struggling to build real life business applications with J2EE like I have you would know.
This was a good argument 2-3 years ago with J2EE 1.4, but now? Have you even tried EE 5 yet?
BTW, I have built business applications with J2EE. How do you think I got involved with JBoss to begin with?
Premature and poor standards help no one other then vendors who want to create a gauranteed market for sub-standard tools.
JBoss isn’t in the business of pushing sub-standard tools for big bucks. I’ve said this before, but, if you’re architecture requires complex tooling, then there’s something wrong with your architecture. This is why I’m not a big fan of BPEL and WS-*, and conversely, happy with the direction EE 5 has gone with annotations.
OSGi maybe?
I think you read too much Spring propaganda. OSGi doesn’t do much to help the end user beyond the classloader scoping. Its really a kernel specification meant for vendors and framework developers.
July 6, 2007 at 8:59 pm
Interface 21 is on the “Supporting this JSR” list on JSR 319… Hopefully that will be the beginning of great things :0)
I’m still hopeful that they’ll have some input for JSR 299, but I doubt it.
As for Spring-OSGi, you’re absolutely right… there is a lot of propoganda out there. It’s also probably about a year away from being useful.
However the biggest win it will have for developers is better application modulaization. Right now we Spring users are kind of forcing one big .war file. That just shouldn’t be “the way.” Spring-OSGi should theoretically solve that problem.
I would like to see more helpful information from I21, IBM, BEA and Oracle which are all on the OSGi bandwaggon.
Heck, I’d like to see a clean solution that enables easy Hibernate-OSGi integration…
July 6, 2007 at 10:43 pm
BB: This is why I’m not a big fan of BPEL and WS-*…
Umm…does that mean we can expect JBossESB to stay away from WS-* and BPEL etc? Wonder what Mark Little would have to say about that
or are you going to do a u-turn when JBoss ESB also plays the WS-* game?
July 7, 2007 at 1:28 am
Hi Bill,
I agree with you about OSGi. Getting over class loader problems helps, but that is not the whole story. You didn’t respond to this though:
“…but if a Java Enterprise Component Framework that is simple, and productive and does the job arrives on the seen, then why bother with J2EEX? In such a scenario why sit in the shit (your words not mine :^))?”
And I guess this is why I’m giving you a hard time :^). IMO the best frameworks emerge from working applications, and this is where I believe OSS is at it’s strongest. People solving real world problems and then factoring out parts that can be re-used and then choosing to share those parts with their peers.
Standardisation should occur once a technology is proven, which is why J2EE5 is much better than J2EE1.4. BTW thanks for Hibernate/JPA it really does help.
Going forward, I’m not sure that J2EE6 will be based on proven technology. How about building it first, seeing what works, then standardising?
If you had got it wrong with Hibernate, then it wouldn’t have become popular and it wouldn’t of ended up as a standard - which is a good thing :^).
July 7, 2007 at 1:51 am
Hi Bill,
Just to be sure you understand me. What I mean is that good technology emerges over time through experimentation and evolution. Freezing this process prematurely is IMO one of the main reasons why J2EE has performed so badly over the years.
If the OSS community joins in with this “premature standardisation” practice also, then IMO Java in the Enterprise is truly doomed.
July 7, 2007 at 12:14 pm
Paul,
J2EE hasn’t performed so badly over the years. Otherwise you wouldn’t have so many deployments out there and WLS, Websphere, and JBoss wouldn’t be making so much money for their perspective companies. JMS, JTA, JMX, JCA, and Servlet are great specifications. Persistence and EJB are on the road to recovery. JSF is pretty damn good as Seam has shown. Even JAX-WS has made things easier for Java-based web services.
Again, I’ll repeat myself. Standards should be about standardizing existing innovations. This is the point where JBoss jumped into the JCP game. We brought Hibernate to the JCP. We’re working out the kinks with Seam before we bring it to the Web Beans JSR.
Each volunteer OSS project or vendor each have their own innovations that many times overlap. Instead of having a fractured community isn’t it better to bring groups together to decide on something common and grow the community?
July 7, 2007 at 12:21 pm
BB: This is why I’m not a big fan of BPEL and WS-*…
Umm…does that mean we can expect JBossESB to stay away from WS-* and BPEL etc? Wonder what Mark Little would have to say about that
or are you going to do a u-turn when JBoss ESB also plays the WS-* game?
Mark Little and I disagree on things, agree on others. Of course, he has a much better educated opinion on this subject than I do. He’s the man, I’m just a loud jackass.
But, JBoss ESB already plays the WS-* game. I’ll u-turn when JBoss or a specification effort has simplified things.
July 8, 2007 at 7:50 pm
I do think the discussion is very interesting. As you probably guessed, I would like to see more collaboration between JCP and Rod Johnson (who actually does have some worthy accomplishments in his background), and I felt that the tone of your post really moved things in the wrong direction.
Your original TSS post suggests that the only way Rod Johnson can assist with the standards process at this point is to “bring Spring to a standards body”, and I’m really not sure that’s correct.
The Interface21 folks have brought some really good ideas to the table (backed by successful work in the field) in terms of improving Java EE for users, and yes, they did influence the Java EE5 specification. I think it’s extremely short-sighted to think that Rod Johnson couldn’t contribute some very useful ideas about extension points on Java EE servers, and specifications of profiles, regardless of what happens with the Spring product.
And at the end of the day, you will always get back to the question of what should be standardized.
AspectJ? That’s very appealing to me, but that’s not Rod Johnson’s baby.
Those goddawful proprietary annotations that are all the craze these days? I don’t want those in Spring, much less in the standards process.
The XML configuration format? This is certainly the most visible target, but I’m not buying it. In my opinion, this file format serves the same function as a proprietary graphical configuration tool that would be offered by IBM, BEA, or JBoss. It is basicallly a useful input format that delegates to the standards API’s. There are a dozen ways that configuration and dependency injection can be performed, and it’s not clear to me that this particular one needs to be standardized.
Those cute little helper API’s? Nah, these sorts of take-it-or-leave-it bits belong right where they are, as a third-party optional library.
In my opinion, the most valuable thing that Spring could contribute to the standards process would be their data access runtime exception hierarchy. I think it really adds to the existing specs, and makes it much easier to work with disparate database vendors. But I don’t think that’s the sort of broad contribution you had in mind.
So, if you were advising Interface21, what would be involved in “bringing Spring to a standards body”?
July 9, 2007 at 2:29 pm
Corby wrote:
So, if you were advising Interface21, what would be involved in “bringing Spring to a standards body”?
I thought I’ve said this over and over? Maybe not. I want the pure IoC stuff standardized and for Interface 21 to follow whatever is standardized. We don’t need a fragmented component model between EJB and Spring users. Unifying them, like we did with Hibernate, JDO, and CMP in EE 5, would be uber beneficial to the community at large.
The persistence exception hierarchy would be beneficial as well, but I see that as something minor. Their security work with acegi might be something too, but I know the Seam guys have different ideas for the same space. Really, I’d just want the IoC stuff standardized.
As far as stepping over the line Corby, well, I get aggravated and emotional sometimes, so be it, its my nature and personality. But hopefully I backed it up later on with some reasoning behind it. If Red Hat wants to fire me over my tone that’s their prerogative.
July 24, 2007 at 11:22 pm
My biggest gripe is that after like a year JBoss’s EJB3 is still a little rough around the edges (the classloader leaks are really getting on my nerves) and still no servlet injection. Lastly…why did we need the useless pools by default? why oh why?
The current choice of “eat as much XML as you can stand” or “1 class - 1 container oversimplification” is still not very satiating. That being said…spring really is starting to show it’s age. EJB3+JPA really shines as a programming model by comparison…but market uptake and vendor failure (including JBoss’s) to bring production products to market in a timely manner is really making Java EE 6 a questionable enterprise in my mind…let alone 7. And there is of course what I said some time ago….EJB3 should have never been named EJB because EJB is associated with “suck” in most developers’ minds. Branding baby. (though spring is a bad brand because news.google.com never brings up weather)
Meanwhile its obvious the market is moving on. The big boys and middle sized boys are all in ESB, BPI and SMD and shouting things that mean nothing like SOA. Injection is so last year.
August 1, 2007 at 9:37 pm
BB: This is why I’m not a big fan of BPEL and WS-*…
Umm…does that mean we can expect JBossESB to stay away from WS-* and BPEL etc? Wonder what Mark Little would have to say about that or are you going to do a u-turn when JBoss ESB also plays the WS-* game?
Mark Little and I disagree on things, agree on others. Of course, he has a much better educated opinion on this subject than I do. He’s the man, I’m just a loud jackass.
Found your blog just today. Boy, you kept this secret
I think WS-* (and BPEL is a good example) is over hyped and more complex than it needed to be (blame the vendors!) Web Services are another tool that makes sense for certain scenarios (heterogeneous interoperability being the prime candidate). They’re not a global panacea. People get burned by trying to replace existing infrastructure with entire Web Services based implementations! Many people who say they need BPEL don’t even understand what that means. Plus BPEL 2.0 is a lot poorer in many respects than the original BPEL4WS. Anyway, your entry wasn’t about WS-*, but I thought since someone mentioned my name I’d chime in here
I agree with you: it could have been a lot simpler/easier and tooling support needs an overhaul.