The Artima Developer Community
Sponsored Link

Weblogs Forum
Java EE: "Java Ever Evolving"

24 replies on 2 pages. Most recent reply: Jul 12, 2006 6:20 PM by Alper Akture

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 24 replies on 2 pages [ 1 2 | » ]
Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Java EE: "Java Ever Evolving" (View in Weblogs)
Posted: Jun 25, 2006 3:35 PM
Reply to this message Reply
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!


James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Java EE: "Java Ever Evolving" Posted: Jun 26, 2006 11:35 AM
Reply to this message Reply
> 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.

Damon Henry

Posts: 1
Nickname: dnice
Registered: Jun, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 26, 2006 5:32 PM
Reply to this message Reply
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.

My 2 cents,

- ddh

Michael Musson

Posts: 3
Nickname: mmusson
Registered: Jun, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 26, 2006 10:56 PM
Reply to this message Reply
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.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Java EE: "Java Ever Evolving" Posted: Jun 27, 2006 3:16 AM
Reply to this message Reply
> 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"?

Dalibor Topic

Posts: 26
Nickname: robilad
Registered: Mar, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 27, 2006 9:23 AM
Reply to this message Reply
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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Java EE: "Java Ever Evolving" Posted: Jun 27, 2006 9:40 AM
Reply to this message Reply
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.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Java EE: "Java Ever Evolving" Posted: Jun 27, 2006 9:49 AM
Reply to this message Reply
> 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.

Andy Dent

Posts: 165
Nickname: andydent
Registered: Nov, 2005

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 6:35 AM
Reply to this message Reply
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.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 7:00 AM
Reply to this message Reply
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.

Peace.

Sean Landis

Posts: 129
Nickname: seanl
Registered: Mar, 2002

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 8:42 AM
Reply to this message Reply
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)

Michael Musson

Posts: 3
Nickname: mmusson
Registered: Jun, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 11:09 AM
Reply to this message Reply
> 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?

D Taylor

Posts: 1
Nickname: bbnemesis
Registered: Jun, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 3:59 PM
Reply to this message Reply
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.

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Java EE: "Java Ever Evolving" Posted: Jun 28, 2006 5:33 PM
Reply to this message Reply
> Cameron, all your points are valid.

Phew ;-)

> 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.

Peace.

Roland Pibinger

Posts: 93
Nickname: rp123
Registered: Jan, 2006

Re: Java EE: "Java Ever Evolving" Posted: Jun 29, 2006 4:33 AM
Reply to this message Reply
> 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 [ 1  2 | » ]
Topic: Java EE: "Java Ever Evolving" Previous Topic   Next Topic Topic: Web Frameworks Jam


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us