|
|
|
Sponsored Link •
|
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
|
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.
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 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:
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.
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?
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.
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.
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!
Have an opinion? Readers have already posted 24 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Sean Landis adds a new entry to his weblog, subscribe to his RSS feed.
 | Sean Landis is a technologist and programmer interested in, among other things, mobile and distributed sytems, location-based services, and skiing. |
|
Sponsored Links
|
Digg
del.icio.us
Reddit