Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
How to Save JEE, And It’s Not EJB 3.0
URL: How to Save JEE, And It’s Not EJB 3.0
At 11:10 AM on Dec 29, 2005, Brandon Werner wrote:
Fresh Jobs for Developers Post a job opportunity
“Nothing about Hibernate or Spring, EJB 3.0 is coming out, people need to start writing to the standards now.”
Wow.
As a person well versed in enterprise architecture and development, I find this inevitable push to bury Hibernate and Spring as throwing a lot of very good tools down the drain in order to continue the Sun monarchy and JCP worship. However, from the enterprise viewpoint, it doesn’t matter if you use EJB 3.0, Spring or even Hibernate to eliminate the DAO issues in dependent objects of light-weight Composite Entity patterns, it’s all JEE to the architect.
If JEE is to survive as a platform, we have to stop teaching JEE as a set of JCP blessed related technologies, often complicated, as implemented in the Glassfish reference implementation, may Sun (Ra?) be praised. I believe that the best way to move on to the JEE 5 era and eliminate all the weeping and nashing of teeth that EJB 1.x and EJB 2.x introduced to developers is to teach JEE as a set of patterns and ideas, abstract from the actual implementations of various providers, and label them as best practices of the enterprise space.
Think AJAX. AJAX is not a set of any one company’s technologies, and there is not even a “reference implementation” of it. You are free to use any backend you want, use any persistence you want, and even implement your own call-backs and improvements. The only thing AJAX is are a set of extremely important best practices and patterns developers use to create compelling web clients. Why can’t JEE be more AJAX like? Why do we have to politically migrate towards these reference JCP technologies when the actual, real JEE patterns don’t give a damn what you use?
When I create UML models or look at others and see lots of Business Object patterns and DAO patterns and Domain Stores in their neat little component architectures, I see JEE Proper: isolation, coarse grained objects, security & independence. Now, what does it matter of company A decides to implement their business logic by plugging a EJB 3.0 embedded in to their JBoss app server, or use Spring embedded in the JBoss application server? If I am a web developer or application developer using a sea of Business Delegates to access the core services of an enterprise application, how does that affect me? If I am an enterprise developer, and the architect has done his job of abstracting DAO and dependent objects from the Business Objects, I can quickly plug and play from Spring to EJB 3.0 quickly. That was the whole point of DAO patterns in the EJB 1.x and early EJB 2.x days… so that when this mythical time came when CMP EJBs were fast and ready for wide deployment we could just implement that, clean the overrides and slice off the DAO / JDBC side.
Why was it “acceptable” to do this during the J2EE 1.4 days with EJBs, but is sacrilegious to do so now to allow for Spring vs. EJB 3.0 plug-and-play? How does it not help JEE principles to write Adapter patterns to do this anymore than it did to abstract the dependent objects from DAO or to incorporate XML webservice processing in our Business Delegate patterns using the Delegate Adapter Strategy?
Some people contend that the whole reason for following only JCP blessed and Sun approved JEE components is that the tools to develop these applications and the application servers that run these applications MUST have one standard to code and test to. However, if JBoss has proven anything, it’s that multiple JEE technologies can be housed in one application server and even made available to the container without compromising or affecting JCP-blessed JEE technologies. In fact, as we have seen, JBoss and Oracle both use their own persisting technologies (Hibernate and TopLink) to implement EJB 3.0. Spring can run inside JBoss, and a lot of enterprise deployers now strip much of the JEE JCP technologies right out of their JBoss configuration to increase speed and improve reliability.
Further, on the tools side, the explosion of Hibernate mappers and Spring helpers for Eclipse, Netbeans and IntelliJ shows us that developers are more than capable in this day and age to add tools that can automate JEE technologies that are not JCP blessed. In a world where our IDEs are platforms in themselves, the flexibility of creating plug-ins to manage complexity in new JEE technologies should not cause anyone to worry about productivity.
I believe that if we are to save the JEE stack, and keep it innovative, we have to allow for non-JCP or even pre-JCP technologies in JEE, and to embrace them as much as possible. Think of what EJB 3.0 or JEE 5 would be like if Hibernate and Spring never existed? Do we really want to now step on the fingers of these programmers and point towards EJB 3.0 as the one true way?
What if we just understood JEE the way it should be understood, as a collection of best practices and server-side solutions, and let the community loose to invent awesome technologies to continue to solve how these technologies in JEE can be better implemented? As this latest JEE upset has shown, we can’t predict what amazing and interesting things are out there from the incredible Java community, and to isolate them from JEE and politically push only JCP technologies in the stack ensures not just the end of JEE for the big guys, but a possible end to all the great work that has been done in JEE engineering regarding software development, the software development process (RuP, Iteration) and development patterns. JEE is much too important to all of us Java developers to abandon it or kill it with inflexible “picks” of technologies to go in the stack.
JEE is about persistence, high availability, scalability, coarse grained objects, best practices and rapid development of enterprise quality code that can be organized and managed by teams and companies through business processes and refactored or scaled by keeping best practices in mind. As we have seen in the past, JEE can deliver on this, even if Sun throws things like the EJB 2.x spec in its way. Let’s keep the innovation going, let’s not return to the days of old.
Java deserves better.
19 replies so far (
Post your own)
Re: How to Save JEE, And It’s Not EJB 3.0
> JEE is about persistence, high availability,> scalability, coarse grained objects, best practices
> and rapid development of enterprise quality code that
> can be organized and managed by teams and companies
> through business processes and refactored or scaled
> by keeping best practices in mind. As we have seen in
> the past, JEE can deliver on this, even if Sun throws
> things like the EJB 2.x spec in its way. Let’s keep
> the innovation going, let’s not return to the days of
> old.
You're getting a little paranoid me thinks.
The editor is asking for a hiatus on Spring and Hibernate articles because EJB 3 is coming around the corner, and the developers of the world will be using it. Those developers will enjoy having tips, tutorials, insights and ways of looking at the new tech in different ways.
That's going to happen.
The only other alternative is that Spring/Hibernate becomes THE standard, and EJB falls to the wayside dying on the vine. That when new users come in to the JEE camp, all they find are books and articles on EJB 2 and Spring/Hibernate. That's NOT going to happen, and we all know why.
You may dispute the need for a standard of any kind, but given a second thought comes that realization that having no standard is pure madness. Despite it's history and many flaws, J2EE has transformed Enterprise computing. The single J2EE standard is an extremely powerful force in the market and back offices of the corporate world. The combination of Sun and the participating vendors is what makes it that kind of force.
JBoss is a ride along compared to BEA/IBM/Oracle, particularly in the early days. JBoss wasn't out cold calling CIOs about the benefits of Java and J2EE in the back end infrastructure. And having those large corporatations promote and use J2EE gave real world experience (both good and bad) to it, yet by the fact that they were promoting the same underlying specification, rather than individual application servers, gave the whole movement a network effect.
That network effect empowered the platform even more. That network effect expanded the platforms use and adoption. That expansion broadened the market and the entire experience base of developers on the platform.
Rather than having folks who knew Borlands server, or BEA's server, or IBM's server, you have folks that new J2EE at its core first and foremost, and the details of the servers next. Were it not for J2EE, the server market (if there was much of a market at all) would be horribly fragmented.
But that network effect and real life experience brought out v1.1, v2.0, and now v3.0. That network effect enabled J2EE to reach the likes of Rod Johnson and Gavin King who worked to make their little worlds better, and eventually shared that info with us. Who knows what would have happened. Perhaps Spring would have ended up a PowerBuilder tool set, or some other proprietary platform, because we would have had the fractured Java Server market that may have never attracted Rod Johnson, rather than the spec based one we have now.
EJB 3 is taking experience of Spring and incorporating it into its new specification. Why is it doing that? Because it is clear that Spring has definate advantages in development, and the vendors want to make sure that their servers are attractive to developers. Bssically the vendors are adopting Spring because they're greedy bastages, and know that their bread is buttered by JEE servers and developers.
So, while you assert that the JCP has killed innovation, I'd argue that it obviously hasn't. You just look at the JCP FOR innovation, when that's not its role. It's role is consolidation and formalization. It's not an R&D firm, it's a beauracracy, a foundation that takes the knowledge of the day, codifies it, documents it, and gives those that use the JCP documents a foundation on which to work in order to maintain some modicum amount of interoperability. Yet, with all of that stifling red tape, we still have things like Spring and Hibernate not just appear, but leave an indelible mark upon the entire community by being embraced within EJB 3.
It all goes back to that network effect. The JCP standards are what empower the Java server marketplace that we see today. For example, web server. There are a few Java servers that do not implement the Servlet spec, but they're a rare breed that have difficulty gaining any traction against a Servlet spec'd based server. And I think, despite its shortcomings, we all can acknowledge how the wide spread adoption of the Servlet spec has given strength to the whole web side of the Java server industry.
Without the Servlet spec, we'd be in a world like the web servers are today. Apache and it's TWO module apis, Windows and its ISAPI, and Sun with its NSAPI, plus whatever every other web server may use to offer extensibility. How many folks know all of those APIs? How many even know more than one? How many developers are basically "trapped" in their little island of compatability by embracing one of these APIs?
But if you know the Servlet Spec, the whole world is available to you, across servers, across implementations.
Industry wanted a web app api, ANY web app API, and they needed something so they could present a unified front against the de facto standard making power of Microsoft. Sun was able to get the parties together and start publishing these things, and industry decided to ante up and participate. Standardizing and promoting the specification first, and their servers second.
So, yes, it's important for developers to be exposed to and learn EJB 3. It's important for the industry, and everyone within it. Book and magazine sellers are eager for a new flood of content to hit the market as we start to embrace the new spec, learn to work with it, nod and smile where it seems to work well, curse and fume where it frustrates us, and then turn to the web and others to see how they're making this new pig sing.
You can still use Spring within EJB 3, tho maybe it's less necessary now. You can still use Hibernate, but since Hibernate is the implementation layer, maybe you can get what you need talking soley through the EJB 3 layer, and only penetrate that for a particular performance bit, just like we use proprietrary BEA/IBM/JBoss bits in our "portable JEE" applications today.
So, it's probably wise now to learn the subsets within EJB 3, and then the specific extra functionality offered by Spring and Hibernate later as needs arise.
You seem to think that they're crushing Hibernate and Spring. They're not. Rather the technologies are being included and promoted. Spring and Hibernate "won" whatever battle you think it is they're fighting.
Re: How to Save JEE, And It’s Not EJB 3.0
A great post. Much appreciated.ENOUGH ALREADY!
I lost interest in reading the rest of your post when I encountered this at the beginning of paragraph 4:>If JEE is to survive as a platform, we have to ...
Since 1999, when I first got involved with Java and J2EE, I've encountered a steady stream of "Java is doomed unless..." missives from various self-styled seers, many of whom had some other agenda they were promoting. None of the alarmist bullshit ever rang true, and, unsurprisingly, none of it ever proved true.
You may have some interesting or informative points to make, Brandon. If so, please try to present them without wrapping them in breathless sensationalism. This rant is not directed at you specifically, but rather the seemingly endless parade of FUDsters who predict the eminent demise of Java or J2EE for one stupid reason or another. Your post just happened to be the one that triggered it.
http://qform.sourceforge.net
Musicians: Check out RPitch Relative Pitch Ear Training Software at http://rpitch.sourceforge.net.
Re: How to Save JEE, And It’s Not EJB 3.0
Java needs these good standards, so both managers don't have to make complex choices.On the other hand, there won't be anyone or anything preventing you from using Spring + Hibernate, or any other open-source framework.
Whatever floats your boat.
... although I do hear EJB 3 will concetrate on ease of use.
"If JEE is to survive as a platform, we have to stop teaching JEE as a set of JCP blessed related technologies"
Yes, but that's what JEE is ... a set of JCP blessed specifications.
Some are good, some have been proven to be overkill.
But standards are a Good Thing TM *always*.
Re: How to Save JEE, And It’s Not EJB 3.0
To the posters above, I will try to clarify what I wrote about JEE.My argument is not that JEE as a standard should go away, but in a world where we are moving to a SOA style of implementing business processes and modeling business needs in to the architecture, that we must stop thinking in terms of concrete technology (faster bubble sort, smoother scrolling) but in terms of patterns and methodologies that best address the problem we are solving.
My gripe was not with EJB 3.0 at all, but with the idea of EJB 3.0 "replacing" Spring and Hibernate; A fear that people considering designs in which using these technologies in a JEE application makes sense abandoning them do to the idea that EJB 3.0 is now the JCP approved technology in the stack.
I'm certain a lot of JEE developers and architects understand that many JEE applications don't require EJBs at all, and many have abandoned or restricted their use of EJBs in their architecture because they have the reputation of being so heavy (particularly CMP). Other technologies have come to the front of the architect's and developer's tool-kit to create persistence and coarse grained behavior without even writing one EJB. I don't want that kind of innovation and flexibility in the JEE environment to go away.
JEE has been great, and I discussed how JEE has changed enterprise development in to what it is today. But BEA, IBM and the rest are abstracting this out even further now in the enterprise space, where your SOA environment can use Java, .Net, Python, or anything. The big guys listed above aren't even submitting their SOA ideas to the JCP at all, stating that SOA is bigger than Java. It is in this environment that I talk about JEE surviving. When those guys go about defining how things are going to work, and leave Sun outside the door, you have to think about agility in the JEE space.
Re: How to Save JEE, And It’s Not EJB 3.0
> To the posters above, I will try to clarify what I> wrote about JEE.
>
> My argument is not that JEE as a standard should go
> away, but in a world where we are moving to a SOA
Yeah, a lot of people say that "we" are moving to SOA, but I've seen very little evidence that it's actually happening. So far, SOA strikes me as a bunch of overblown hype flogged by vendors with SOA products to sell.
> style of implementing business processes and modeling
> business needs in to the architecture, that we must
> stop thinking in terms of concrete technology (faster
> bubble sort, smoother scrolling) but in terms of
> patterns and methodologies that best address the
> problem we are solving.
>
> My gripe was not with EJB 3.0 at all, but with the
> idea of EJB 3.0 "replacing" Spring and Hibernate; A
> fear that people considering designs in which using
> these technologies in a JEE application makes sense
> abandoning them do to the idea that EJB 3.0 is now
> the JCP approved technology in the stack.
People make technology choices for a whole lot of reasons, Brendon. Some of the choices they make are better than others. That simple fact should not cause you any fear, however. Cheer up.
>
> I'm certain a lot of JEE developers and architects
> understand that many JEE applications don't require
> EJBs at all, and many have abandoned or restricted
> their use of EJBs in their architecture because they
> have the reputation of being so heavy (particularly
> CMP). Other technologies have come to the front of
> the architect's and developer's tool-kit to create
> persistence and coarse grained behavior without even
> writing one EJB. I don't want that kind of innovation
> and flexibility in the JEE environment to go away.
And there's no reason why it will go away, as long as there are people who want to use it.
> JEE has been great, and I discussed how JEE has
> changed enterprise development in to what it is
> today. But BEA, IBM and the rest are abstracting this
> out even further now in the enterprise space, where
> your SOA environment can use Java, .Net, Python, or
> anything. The big guys listed above aren't even
> submitting their SOA ideas to the JCP at all, stating
> that SOA is bigger than Java.
Yeah, and a few years ago the "big guys" told me that by now I would be using a diskless "network computer", renting my application software, and storing my data on their servers -- all in my "paperless" office, of course. I laughed at their bullshit then, as I laugh at it now.
SOA serves a purpose, but it's not going to be the basis for all (or even most) future enterprise development -- regardless of what the "big guys" say.
> It is in this
> environment that I talk about JEE surviving. When
> those guys go about defining how things are going to
> work,
Maybe they define how things work in your world, but not in mine.
> and leave Sun outside the door, you have to
> think about agility in the JEE space.
Agility is a good thing to think about regardless.
http://qform.sourceforge.net
Musicians: Check out RPitch Relative Pitch Ear Training Software at http://rpitch.sourceforge.net.
Re: How to Save JEE, And It’s Not EJB 3.0
As the creator of Hibernate, and coauthor of much of the EJB3 specification, I really don't see how my project is being "buried".On the contrary, EJB3 gives us the opportunity to bring Hibernate and ORM technology to a much, much bigger group of people than was possible before. *You* might be lucky enough to be able to use whatever cool opensource technologies you can pick up off the street, but a lot of people are not that fortunate, and have to use stuff that is blessed by the standard.
Before damning EJB3, actually take a look at the spec. Compare it to Hibernate. Look at the EntityManager API. Look at the transitive persistence model. Look at the query language. Where do you think those came from? (Yes, the APIs are not *exactly* the same as Hibernate - that is a natural and correct part of the specification process.)
Now look at the things in EJB3 which were *not* in the earlier editions of Hibernate: the annotation-based O/R mapping, the new managed persistence context model, the improved callback facility, a packaging spec and pluggability contract to allow easy depoyment in any appserver. All these things are things I wished Hibernate could have had! It couldn't have annotations earlier, cos the Java language did not have annotations. It couldn't have a decent managed persistence context model because we did not "own" the service layer, and because the most popular service layers used with Hibernate were stateless stuff like Spring. I couldn't have a portable packaging format, because I did not control the appserver. Etc. All this stuff combined represents a great advance in ease of use compared to Hibernate2.
Hibernate is not being buried, rather, it is becoming the standard. To do that, we had to negotiate and work with other important stakeholders, especially Sun and Oracle. This is all Right and Good, and how it should be.
More importantly, since the best practices in ORM are now well-documented in an actual formal spec, languages that come *after* Java will be able to look at the spec to understand how they should handle persistence. Just like Java learned remoting and managed transactions from the C++ community.
Re: How to Save JEE, And It’s Not EJB 3.0
Gavin:Certainly, Hibernate has had a large impact on EJB 3.0 and rightfully so, but when one walks in the door and makes the party better, it's best not to shut the door behind you, someone else equally as impressive may walk in after you.
I wrote in the original article to imagine what EJB 3.0 may have been had Hibernate and Spring never been. If the community had not been open to thinking about other technologies inside their JEE stack, you might not have been able to influence EJB3 as you have.
My point is not to shut the door, but to continue to allow other interesting new technologies, like Hibernate was, in to the JEE space.
Re: How to Save JEE, And It’s Not EJB 3.0
But how would the EJB 3 stifle any new innovation? If anything, EJB 1 and 2 ENCOURAGED innovation.All of these thing are merely snapshots in time. Snapshots that record the state of the art at the time the picture was taken. Nothing stops or culls any advances. With the variety of open source app servers (all of them EJB app servers for those making notes) give innovators a vast array of platforms on which to fiddle and experiment, to perhaps come up with the Next Big Thing.
But in the meanwhile, for the poor blue collar Joe coder's out there in the trenches, they can't live on the bleeding edge. They and their companies rely on vendor support and training. So, they enjoy it when something like EJB 3 comes out to make their day to day work that much easier.
The only way EJB and JCP hindered Gavins work was because there were areas that were effectively off limits to him because of the lack of extensibility within the container. He could certainly have attacked all of those angles there at JBoss, and made JBoss the Container Of The Future, and in fact it can be argued he has done just that, using JBoss as a platform and test bed to finalize and test his designs that are now within the EJB 3 spec.
The reason he chose not to was to better finish the Hard Part rather than the fringe details.
Or, you can do what the Spring folks did and abandon the container completely. They looked at the EJB container and simply said "bu-bye", and kicked it out the door, bolting together their own on top of a Servlet container. JCP didn't stop them one wit, NOR, may I add, did it stop people like you from joining them. Obviously the EJB container charms didn't hold you to keep staying with it, how will EJB 3 hold you?
Finally, EJB 3 has NOTHING directly to do with SOA and, more specifically, web services. That's entirely on the web tier, and the W3 specs for all of the plethora of protocols and XML handshaking. From a purely internal point of view you can build a SOA app on anything from JSP Model 1 pages to tier upon tier of new and old, in house and 3rd party servers written in everything from VB to COBOL to Python and Ruby. You can even use EJB 3 to build SOA apps. Or, gasp, even Spring. Some stick in the mud can make a modern performant SOA back end on EJB 2!! OMG!
The vendors are working on tool suites to make it easier and more automated the boiler plate protocol management and base infrastructure binding mechnisms that facilite VERY loosely coupled system which is the heart of SOA. The systems are so loosely coupled that, as you mentioned, Java doesn't need to be used at any point.
But you think that the likes of Python and Ruby and what not are chomping at the bit, just waiting for something like SOA to set the free? You think that is what has been holding them back? That the JCP EJB onslaught has somehow targeted and crushed them under foot like the little upstarts that they are, and EJB 3 is yet another hammer blow aimed at Matz and Guido to keep them down?
Well, as much as they might like to "stick it to the man", I have a harsh reality for you. The things holding them back are their implementations. The JVM is what powers Java, it's performance, stability, and scalability on the large mutli-cpu monsters.
How does that go? "With web services, no one knows you're running Python"? Something like that.
What's going to attract people to the Java platform for SOA applications is what has attracted them the entire time. The proven back end technology, implementations of standards, vast libraries, portability and performance. Add to that the millions of man years of total Java knowledge.
EJB 3 simply sweetens the pot for Java developers. The vendors are working to on other platforms in order to ensure interoperability. Regardless of what Microsoft may say, interoperability is the key to web services and the SOA architectures that they expose.
EJB 3 isn't holding anyone back, it's actually moving them forward. It benefits folks like me who may well be able to work on EJB 3 in the future, but within my million lines of EJB 2 code. I don't have to port the whole damn thing all at once, I can simply add new pieces in the new style, and slowly migrate the old forward as time permits. I can do that with reasonable confidence that I'm not building a platform of shifting sand, that's changing as fast as I'm coding, and that when I choose the platform, I can expect that EJB 3.1 isn't going to come out within a month and invalidate all of my jar files.
It's hard enough to keep up with our application versions, much less the versions of the libraries and frameworks we depend upon.
Whatever fears you have I feel are completely unjustified. I welcome our new EJB 3 overlords and keenly await when I can get my EJB 2 tattoo burned off my left arm and replace it with EJB 3.
Re: How to Save JEE, And It’s Not EJB 3.0
Huh?? Who is shutting any doors?There will be an EJB 3.1. There will be an EJB 4.0.
Is the JCP some kind of closed shop that no-one except for certain blessed people is allowed to join and contribute to?
Or, if you think you have some whole revolutionary new way to do something that is already covered by the EJB spec, then do what I did 4 years ago, and go and start an opensource project. And guess what: EJB3, with its interceptors and callbacks will make it way, way, way more easier to integrate your new revolutionary product with the containers than it was for me to integrate Hibernate. EJB3 is the exact *opposite* of a closed door. It is an open, extensible platform for building both applications *and* frameworks.
Now, frankly, I simply don't see anyone inventing some whole new way of doing transactions or persistence or remoteness or state replication or resource/dependency management or interception in the next couple of years. These things are all essentially solved problems where all the successful implementations look broadly similar. (There is no longer a great difference in approach between the 3 major ORM solutions in the marketplace, for example.)
(OK, so Java EE security could do with a big f***ing shakeup, since it's a total disaster at the moment, but EJB3 makes it just incredibly easy to integrate any security model you like using interceptors and entity callbacks.)
But really, innovation is more likely to come from the *unsettled* problems than from the settled ones. I can take a guess at what some of these problems are, but I'm certainly not sharing
And if EJB3 has stopped innovation, then how do you explain:
http://jboss.com/products/seam
This is just the first of the coming explosion of open source frameworks that integrate with and build on top of EJB3. *That* is the power of a standard. That people can target a single, well-accepted platform to leverage and develop new things *on top of*. Lack of standards eventually strangles innovation, because people won't take the risk to build on top of things like Hibernate and Spring that are, in a certain sense, proprietary technologies.
Of course, if I had a total failure of any kind of vision for the future, what I would be trying to do right now is continue to fight the standard with my own little product, and throw more and more features and work into it for ever diminishing returns and eventually just run out of steam as the standards eventually overtook me.
But I don't want to spend the next 5 years of my life doing bloody persistence (I'm totally bored of it), for an ever shrinking number of people. Instead, I'd rather jump on the standard, and see what new uses I can put it to. I've got a real leg up here, since I made damn sure that the EJB3 spec had all the extension points I was going to need to do the kind of things I plan to do in the next year
Convert or fall forever?
"Convert to the new standard or fall forever"...Its a classic thing that I hear all the time. Everyone is trying to push for a standard that solves every problem so everyone can write to that standard. The problem is that there is enough difference in applications that simply adopting the 'standard' (whatever it is) simply won't make sense for everyone. Every design has been through some process to make it ideal for certain types of problems. If you don't need to solve those problems, adopting a standard is simply going to add risk where one shouldn't be.
I remember initially working on a project when EJBs were the 'hot' thing. The architecture we already had was sound, but we were extending it and someone decided that EJBs would make sense going forward. The problem was that EJB didn't solve ANY of the problems that we had and introduced a new level of complexity that we didn't previously have to deal with. Nevertheless it was the 'new' and best way to do persistence. Years later, the entire architecture was tossed in favor of something that fit more closely with our needs and we're much the better for it.
I think this level of critical design/architecture reasoning is missing in a lot of shops - certainly many that I've been to. There is an opinion that if its a standard or if it has come from x,y,z it must be good - therefore we should standardize on it. Precious little time is spent examining if a smaller subset of a standard that might perhaps exist in a 'non-standard' product would make more sense.
I'm a fan of standards - but only when they absolutely fit the problem. The technology should fit the problem, you shouldn't have to rework the problem in order to fit the technology.
Re: How to Save JEE, And It’s Not EJB 3.0
Standards are not wrong.And in the case of EJB 3.0 I believe they have gotten it right this time.
I'm much more worried about JSF though. Although I don't have any field experience with it yet, my gut feeling tells me that they have gotten it wrong again. In the end it is HTML which is an extremely poor language to design a web application in. Then, there is loads of javascript, which is very hard to debug. And all the round-tripping remains, although it will be obfuscated by means of AJAX. But let me not start a rant here.
In the latter case, don't worry: new open source projects and paradigms will emerge. Who is stopping you? My bets are on Macromedia Flex.
Re: How to Save JEE, And It’s Not EJB 3.0
I've been working heavily with JSF for several months now, and it is actually very nice. I don't have the knowledge of tapestry to say it is better or worse than tapestry, and certainly JSF *does* have some rough edges, but really it is a truly massive advance over Struts, or similar "web MVC" type frameworks that most people are using today.JSF is a great fit to a wide variety of the kind of applications that people use Java for. It is not the be all and end all of web presentation, but it does not need to be.
One of the things Seam does is polish off some of the rough edges in JSF, letting you use annotations instead of reams of XML, giving you a proper conversation scope, deeply integrating EJB 3.0, etc.
What *is* broken (really, truly, deeply broken) is JSP (Java Steaming Pile), but fortunately Jacob Hookom has given us Facelets, so that need not be a problem any longer
Re: How to Save JEE, And It’s Not EJB 3.0
I agree with your editor.JEE has to be more than a written down set of ideas and patterns, otherwise the brand will be worthless.
I think the JCP has worked well. It's embraced techniques and technologies that have been proven in the field and made them part of the JEE standard. It's looked not only within the java community but outside it to simplify enterprise java.
The need for spring may be diminished by JEE5, but that doesn't mean innovation will cease. Look for rails like technologies implemented in Java to gain popularity in the coming months.