Summary
With the demise of my former employer, I found
myself on the streets holding a sign that said: "Will do Jini for food." I finally landed a job with a company that does Jini, although I am
not doing Jini. This entry is a reflective on what I
learned about Java EE in that three month period.
Advertisement
Drinking the Java EE Kool-aid
I knew it was going to be hard to find another Jini-related job, especially
since I was not able to relocate; but I had no idea. In the past, I'd never had
more than a week between jobs so I figured this wouldn't take too long. After
a few weeks though, I realized there was a pattern developing. Nearly all the
jobs in my area were J2EE jobs. In fact, if they were asking for a Java
programmer, what they really meant was J2EE programmer. Java had become
synonymous with J2EE.
It was time to list J2EE experience, no matter how meager, in my resume. As if
by magic, I started getting calls. Unfortunately, no one wanted to pay my
going rate for the previously mentioned meager J2EE experience. Thus began my
quest for J2EE enlightenment.
I had a chance to go to JavaOne for not too much of my own money and I figured
this would be a great opportunity to pour a pitcher full of J2EE down my
throat. Sun's theme for this JavaOne was Java EE which is the new moniker for the
latest version of Java Enterprise technology. All kinds of great new stuff
was in store for the J2EE community.
For me, the theme of JavaOne was waiting in line to drink the Kool-aid. A new
system was put
in place to ensure people didn't get stiffed on the sessions they wanted to
see. Or at least they didn't get stiffed at the last moment. Instead we had to
sign up online for the right to wait in ridiculously long lines to scan our
Java card to make sure we were authorized to see the session.
I don't know if this
was any better than before, but it gave me time to think about Jonestown.
I always felt that enterprise Java was a giant hairball. The more I learned
the less I liked. Everything was wrong. Since I had a Jini job, and Jini I
felt, was actually a well-designed technology, I didn't worry too much about
the pathetic state of enterprise Java. Now though, I was waiting in line and
I was going to choke down the Java EE Kool-aid regardless of how I felt about
it.
EJB: Distributed Objects Gone Bad
How in the world did EJB end up requiring that an object need multiple
interfaces? Why is the programmer burdened with so many details? Why is this
technology so over-complicated? Why is it so limited? Why is it so slow?
Why is it so heavy? Why must all my "distributed objects" run in a single
app server? The list goes on and on.
Most of this garbage is probably a result of a rush-to-market standardization
(I use that term loosely) process. To some extent, the technology was born of fear, rushed to market to be the first to fill an obvious need. Regardless, the enterprise Java world was blessed with a number of
forward-thinking open projects such as Spring, JBoss, and Hibernate. These
efforts, I think, really drove improvements in the standards. I may be wrong,
but from my outsider's view, developers, being so pragmatic, finally got sick
and tired of the crap and started building the right stuff.
One side-effect was EJB 3.0 which I learned at JavaOne, really ain't so bad.
Some of the wild-and-wooly open source ideas eventually ended up in the standard. It
reminds me of how race cars influence our minivans. Did I just equate EJB 3.0
with a minivan? Ok, our Suburbans.
JSF Finally Accepted?
JSF has been around for a long time but it finally seems to be gaining some
traction. I understand the EE community had to wait a couple of years for
the standard and reference implementation to be completed and that there was
a general fear that it would be EJB for the UI. To me it looks like YMAB: Yet
More Angle Brackets. But experts assure me it's a really sound platform.
Platform because those same experts say that JSF is a great foundation but
there weren't a lot of capabilities delivered with it. There must be truth to
the goodness of JSF (and the incompleteness), because of the vast number of
frameworks built atop it:
Seam
Faclets
Shale
MyFaces
Tomahawk
Oracle's ADF
Just to name a few.
I confess I don't know a lot about these but I think it's fair to say groups
of people aren't going to invest the time to create these frameworks
atop a technology that sucks.
Converging Upon Goodness
So it appears enterprise Java is converging toward goodness. Many times I
heard folks at JavaOne and at
a recent No Fluff, Just Stuff conference say, "Java EE is finally
approaching what it should have been in the first place!" I'm not going to
list all the improvements, but from my less expert eyes, Java EE is a vast
improvement over its predecessors. It addresses many of the things I found
intuitively repulsive at first glance.
I might just be able to enjoy a new life with Java EE. Maybe it won't be
such a compromise of my professional standards. And, after all, it probably
is the best way to deliver web applications and services. Or is it?
The EE Counter-culture
I notice enterprise Java programmers divide into two groups. On one side of
the room are the Java EE folk who feel the pain is worth the gain. On the
other side are the agilists for a lack of a better term. These are the
pragmatic folk who are more focused on getting the job done quickly and
efficiently than they are about following standards. They are the ones who
use and maybe even helped build technologies like Ruby on Rails, Spring,
Hibernate and other lightwieght frameworks. This counter-culture rightly
views Java EE with skepticism. They fashion themselves the enlightened
counter-culture of enterprise computing.
The later is the group that recently seems to have had the greatest influence on
enterprise Java and I am sure they will continue to be on the leading edge.
These are probably the same kinds people who are building the 200 or so AJAX
toolkits. It is this group, and what they stand for, that gives me pause
as I put the jug of Kool-Aid to my lips.
If It's So Great, Why Do We Need So Many Toolkits?
The progress made with AJAX, JSF, EJB 3.0, and Java EE in general, hasn't
seemed to stop the gushing flow of new frameworks and alternative technologies.
If Java EE is so great, why do we need all this other stuff? Maybe this
question just shines a light on the fact that I don't get it. But it seems to
me that if the state of the enterprise Java market were sound,
convergence would reduce the need for all this extra stuff. The good news,
I suppose, is that, at least in the case of JSF, many of these toolkits are
being built atop the core Java EE technology rather in independent of it.
My belief is that several forces are at work. First being that we simply
haven't tapped out the potential of web-based computing. New tools that enable
powerful paradigms are arising all the time. AJAX makes rich clients more
practical, for example. And there is convergence on what denotes good practice,
thus allowing the abstraction level to rise resulting in new toolkits and
technologies. For example, Ruby on Rails uses stereotypes,
or templates (or whatever they're
called in that world) to rapidly build good enough web apps.
So I guess all this change should be expected. But that doesn't mean I'm not
nervous about it.
My Big Questions
How are organizations dealing with the turmoil of the rapidly changing
enterprise computing
landscape? There are so many options and choices. There are so many tools
and frameworks, many of which don't seem to worry much about backward
compatibility. Knowing how fast things are changing, what is the thought
process for picking a suite of enterprise tools for constructing an
application?
Once the choices are made and the application is built, how
do companies evolve? I've been bitten by this recently on my own
small EE project.
In a matter of a year, the component technologies have changed
dramatically. Deprecation is rampant, backward compatibility is elusive, and
the standards are changing. I understand the issue of technology
migration in general but in this EE world, the depth and breadth of the
problem seems so vast as to make it intractable for traditional approaches.
As I interviewed for all the J2EE jobs I spoke of eariler, this theme seemed
universal. All the companies were struggling to keep up. All the companies were
in some form of entropic distress. None of them seemed to have an answer other
than to throw more people and more expertise at their problem. Hire someone
well-versed in the latest toolkits and TLAs and hope they are the hero that
saves the day.
Maybe my impressions are wrong. Maybe I'm trying to justify my ingrained
prejudices toward enterprise Java. I don't know. But now that I've sipped the
Kool-Aid, I'm beginning to wonder if I'm making a mistake. Ah heck! Look on
the bright side: If nothing else, there's plenty of work to do! Gulp!
> EJB: Distributed Objects Gone Bad</h1> > > How in the world did EJB end up requiring that an object > need multiple > interfaces? Why is the programmer burdened with so many > details? Why is this > technology so over-complicated? Why is it so limited? Why > is it so slow? > Why is it so heavy? Why must all my "distributed objects" > run in a single > app server? The list goes on and on.
Most of these complaints are universally accepted as being pretty obvious. The original J EE specs were built wrong from the ground up. A flawed design philosophy is like a mis-poured foundation.
I remember being frustrated by all the esoteric gotchas in J2EE and if you didn't buy into it 100% and know every one of the thouands of details of what it took to make it work you 'just didn't get it'.
If I'm not mistaken, that's why there is so much change. The whole thing had to be cleaned up and simplified into what it should have been in the first place. Now comes the hard part: getting all of the people who have been singing it's praises for years to turn around and admit it was crap all along and start dismantling the mess that was created.
Great post. I'm a 8+ year Java veteran and I'm having a hard time justifying it for use on most projects. The amount of effort required to get anything done (unless you're using an IDE) is far from trivial. I've never been a fan of J2EE for that reason and it appears Web Services are going down the same path as J2EE. There seems to be an unwritten rule in the Java community that "if it ain't hard, it ain't right". I've become a huge fan of RoR because it can easily accomodate most web based projects with minimal amount of effort. EJB 3.0 makes things easier but not easy enough.
In short, use J2EE/.NET for heavy hitting projects and look to RoR or PHP for moderate to less complex applications.
Maybe I just fall into the pragmatic camp, but I don't understand why Sun's reaction to a successful library like Hibernate is to create EJB3 (at least the persistence part). This is unnecessary bloat. Hibernate works perfectly well. Even if the EJB3 design starts great, the third party libraries will still surpass it as they evolve at a more rapid pace.
> Maybe I just fall into the pragmatic camp, but I don't > understand why Sun's reaction to a successful library like > Hibernate is to create EJB3 (at least the persistence > part). This is unnecessary bloat. Hibernate works > perfectly well. Even if the EJB3 design starts great, the > third party libraries will still surpass it as they evolve > at a more rapid pace.
Are you saying that Hibernate has some sort of entitlement to a monopoly of persistance services, on the grounds that it "works perfectly well"?
You can blame J2EE on JCP's lack of developer community oversight and a focus on quantity instead of quality of JSRs.
There is no mandated feedback loop with the users, as most (Sun-led) JSRs are ran from the ivory tower of ignorance. There are no mandated alpha releases of open source RIs to go with the spec drafts. There are no mandated open source test suites to go with the specs drafts to encourage people to implement them and find holes in the specs. There is no mandate to have multiple open source implementations passing the test suites before a JSR is passed through to the next stage.
With the way the JCP works, it's no wonder half the stuff coming out of it is of questionable quality and utility in practice.
I couldn't agree more. Lately I have found programming heaven using simple Java + Echo2: web apps as they are supposed to be. The browser is nothing more than a GUI container anyway.
> You can blame J2EE on JCP's lack of developer community > oversight and a focus on quantity instead of quality of > JSRs. > > There is no mandated feedback loop with the users, as most > (Sun-led) JSRs are ran from the ivory tower of ignorance. > There are no mandated alpha releases of open source RIs to > go with the spec drafts. There are no mandated open source > test suites to go with the specs drafts to encourage > people to implement them and find holes in the specs. > There is no mandate to have multiple open source > implementations passing the test suites before a JSR is > passed through to the next stage. > > With the way the JCP works, it's no wonder half the stuff > coming out of it is of questionable quality and utility in > practice.
Reviewing the JCP process, I see that there are two public review periods and maintenance. I also see that a reference implementation is required - although not an open source one - before final draft can be approved. There is nothing that precludes additional implementations that could well be open source. Many JSR members build their own implementations and they have major influence on the spec. Furthermore, many reference implementations have been open source. I do not see a requirement for test suites of any kind but I know they are often created as part of the process. That would be a nice requirement.
Regarding the competence and motivation of the EGs, my impression is that it varies from JSR to JSR. I know of some that have brilliant people on them and the results are good. I know of others that are staffed with folks who are more concerned with politics and territorial defense than with quality technology. Sun's role often seems too powerful as well but I view Sun as a benevolent dictator type tending to rule reasonably well (exceptions accepted).
Looking at the complete set of JSRs, I'd say the success rate is pretty good. I would also say that certain areas seem to suffer more than others. Enterprise computing seems to struggle, but of course it's a big problem. The mobile market JSRs are a disaster but they know it and say they are working on it.
I think there is a lot of room for improvement in the JCP, but I'm not convinced your specific complaints are at the top of the list.
My conspiracy theory/brutal economics take on J2EE is that the big players in Enterprise development had a certain vested interest in things being complex and requiring lots of people applying relatively little skill to each bit they dealt with.
J2EE looked like the much-desired "Software Factory" environment.
I hate to be the lone voice willing to disagree, but the article had absolutely nothing of substance other than the fact that there are no JINI-related jobs and there are lots of enterprise Java jobs. While it may make the author feel personally better to denigrate enterprise Java, there is probably a good reason why companies are willing to pay people to build things with it, and conversely one could draw the conclusion that companies see no significant value in building things with JINI. Sooner or later, we'll have to stop blaming Sun and/or the entire business community for this, and accept that there is something fundamentally untenable (from a business perspective) with JINI. If it doesn't effectively solve problems that businesses are facing, they won't pay people to play with it -- it's that simple.
Cameron, all your points are valid. I didn't intend the article to merely be another diatribe from a disgruntled Jini developer. I feel the substance of my post is in the last section, "My Big Questions." I think these are important and substantive questions, and I was hoping the discussion would focus on them. The Jini story I tell is for context and to emphasize that I'm looking at enterprise Java from a particular perspective.
This post kicked off a long discussion on www.theserverside.com. No one discussed the Big Questions, and the discussion rapidly turned to dissention about which of the multitude of alternative technologies was best. This is precisely the point I'm trying to make when I say there is no convergence on a reasonable number of approaches. New alternatives are popping up every week and what I want to know is how companies dealing with this tidal wave of change.
I'd like to hear your experience with these challenges. (BTW, I enjoyed your session at JavaOne)
> Are you saying that Hibernate has some sort of entitlement > to a monopoly of persistance services, on the grounds that > it "works perfectly well"?
Not exactly. Good working libraries are available. What is the compelling need to create one more that it not better than what is already out there? I understand that Sun wants Java to be a monolithic software stack, but can't we see that is a fool's errand at this point?
I have a bit of a different take on the point of there being too many frameworks and toolkits and such. I think having a number of tools and frameworks out there in and of itself out is fine.. what I think is lacking often times are support and integration tools that should be built along with the software to make them easy to get up and running and use them in a project. I find myself in XML-config hell a lot of time just to get something working, whereas if it came with a nice Eclipse plug-in, or some sort of config wizard (like a lot of the .NET tools do), I could get the thing basically working, and if I needed some more complex functionality, I could delve a little deeper. I do both J2EE and .NET, and the one thing I like about .NET is that when push comes to shove (as if often does with project timelines), I can go the "quick and dirty" route much more easily in .NET.
> I didn't intend the article to merely be another diatribe > from a disgruntled Jini developer.
That's where I was worried it was going.
BTW - I have no problems with gripes about J*EE .. I've authored quite a few myself. I just want to see some real meat on the arguments ..
> I feel the substance of my post is in the > last section, "My Big Questions." I think these are > important and substantive questions, and I was hoping the > discussion would focus on them.
OK .. here they are:
1. How are organizations dealing with the turmoil of the rapidly changing enterprise computing landscape? There are so many options and choices. There are so many tools and frameworks, many of which don't seem to worry much about backward compatibility. Knowing how fast things are changing, what is the thought process for picking a suite of enterprise tools for constructing an application?
It's true that the individual components of enterprise Java appear to evolve very rapidly, but the platform itself is on a roughly 18 month update cycle, and the standards (with very few exceptions) have maintained compatibility from release to release.
The surrounding projects and products (Struts, Spring, Hibernate, and 1000s of others) are obviously less "controlled" as a rule than the JCP-driven enterprise Java specifications and corresponding releases. However, this is little different from the projects that surround any successful technology -- even Java itself.
The "good ones" have good compatibility and stable releases. Spring is a good example.
2. Once the choices are made and the application is built, how do companies evolve? I've been bitten by this recently on my own small EE project. In a matter of a year, the component technologies have changed dramatically. Deprecation is rampant, backward compatibility is elusive, and the standards are changing. I understand the issue of technology migration in general but in this EE world, the depth and breadth of the problem seems so vast as to make it intractable for traditional approaches.
The technology itself is advancing pretty rapidly. So while an architecture from 2003 is still working well today, and the code still probably compiles and runs with newer versions of the JEE specs, app server and various other libraries, its architecture is not "contemporary".
From one perspective, it's hardly a bad thing that technology is progressing .. there's a lot more options today for doing it bigger / better / faster than there were even just a year or two ago.
On the other hand, it does tend to make recent investments look antiquated, whether it is a company looking at a system or a developer looking at their resume. That can have the effect of causing organizations and people to artificially attempt to stay on the bleeding edge.
> I'd like to hear your experience with these challenges. > (BTW, I enjoyed your session at JavaOne)
I guess you're referring to "the top 10 ways to botch a J*EE app" one .. that was a lot of fun.
> The technology itself is advancing pretty rapidly. So > while an architecture from 2003 is still working well > today, and the code still probably compiles and runs with > newer versions of the JEE specs, app server and various > other libraries, its architecture is not "contemporary".
Wow, 3 years from hype to legacy! If that is "nothing of substance" then I'd like to know what a substantial problem for Enterprise computing should be. Is it the permanent migration from legacy frameworks to "contemporary" frameworks?
Flat View: This topic has 24 replies
on 2 pages
[
12
|
»
]
Previous Topic
