Getting around BigDecimal pain with Groovy DSLs in Lisp
Aug 02

The need for a common Java stack

Java, Tech Add comments

SpikeSource announced more news around a stack.

This is sorely needed in the opensource world, and in no other software arena more than Java.

In general, Java folk are ‘engineers’. We like to try the latest and greatest. One project may be Tapestry/Pico/Kodo JDO/Ant and the next WebWork/Spring/Hibernate/Maven. We jump and leap between similar, and very disimilar worlds.

This can seem cool, and flexibility and choice is a pro for Java. But, imagine if you are running a huge company, and your large IT team is running around in this manner.

Now the Java platform becomes a burden as you can’t jump between projects easily, education becomes a nightmare, as well as reuse.

The goal at large IT shops is to be able to churn out applications in short order, that fit into the corporate enterprise view (and tie into the systems such as authentication, authorization, etc).

The Stack

This is where the need for a common stack comes in. As a CIO of BloodyHuge Inc. I want to enable some flexibility, but within the guidelines of a stack.

Wouldn’t it be nice to have a development team start a project and:

  • Know the technology inside and out (past projects, and good training)
  • Know the lay of the land for the project (shared dir structure, build goals, etc)
  • Have helpful code to gen some work (a la Rails)

We need common stacks to do this.

When I saw the SpikeSource announcement and the large amount of technologies in their ’stack’, I thought it was missing something. As a company I don’t just want to know that technology a thru z is ‘certified’ from a company, or that they offer support.

They want help. They want you to work with their engineers to choose a common stack that has everything setup from the beginning.

They also want it to be locked in stone for a couple of years, with a known release cycle of updates to the Stack.

When I look at SourceLabs and their AMP Stack, I think they may have gotten it.

Update: SourceLabs does have a Java Stack:

  • Spring Framework: version 1.2.3
  • Apache Axis: version 1.2.1
  • Struts: version 1.2.7
  • Hibernate: version 3.0.5

Java + Common Stack = Productivity

J2EE != Stack

I personally don’t think that J2EE is the stack. Right now, if you look at an average Java project you will see myriads of dependencies that have nothing to do with J2EE. Although the Java platform is growing, and you could envison a stack that consists of JSF + EJB 3 + java.util.logger + … even this isn’t everything you need for a project.

J2EE is great from the standpoint of API education IMO. When you use different implementations you will often need to tweak things… maybe at a config level, or what have you.

9 Responses to “The need for a common Java stack”

  1. Michael Burke Says:

    So, the idea behind a stack is essentially ‘there’s only one way to do it’ and to have a common denominator for new developers, available books, training, conferences, coffee mugs etc etc.

    Surely that’s the whole point of J2EE (sorry Java EE)? A standard web toolkit, a standard ORM, a standard deployment model, etc.

    I’m just not sure that the open source Java world stays still long enough to be able to define such a thing. If you tried to define such a stack 2 years ago it would look very different now I’d wager.

    regards
    Mike

  2. Anonymous Says:

    I think quite a few big companies already do leverage their own “stacks”. Some stacks may be proprietary (slow to evolve and pretty costly in the end), but some are based on known OSS components.
    I’m actually working at a big European car maker company which commoditized Struts + OJB + Castor + Ant or Maven for all their Java projects.
    Using a common stack makes a lot of sense because it reduces the training costs, the learning curve, and the risk of failure of a project (always someone who experienced the same issue and who will know the solution), it promotes more reusability, it’s easier to get good support (both internally, and on the OSS project’s respective mailing-lists), etc. A lot of advantages.
    The sole drawbacks we could mention is that these “stacks” tend to be somewhat more boring to work with because you’re not “living on the edge” and using the most fashionable and innovative components available on the market place (no IoC, or other buzzwords). Moreover, it also happens that you’re not using the latest version of each components of your stack if the guys behind the stack are slow to upgrade.
    But overall, a common stack across the company is a pretty good bet.

  3. Emmanuel Pirsch Says:

    [preparing-for-thunderstorm /]

    There is one common stack… it’s called J2EE (soon to be JavaEE) ;-)

    To have a common stack mean to have standard. Means to have less innovative stuff.

    Actually, for the backend part, it’s easy… There is roughly two options… Hibernate vs CMP (I know, there is more, but momentum wise, there is no other real choice)… And CMP is on the way down.

    For services, you have POJO which can be deployed on any distribution technology more or less transparently using lightweigth containers.

    The real trouble comes with the UI. Right now, there is just too many options to choose from with none of these (beside struts) that have a lot of momentum. With Ajax taking a lot of buzz these days, we have even more options. The number of framework and pace of evolution for the UI part of the stack make it difficult to commit to any of them.

    Beside there is no large enough common ground between these framework to have UI related code easily deployable on different framework.

    I don’t think it is possible right now to commit to a full Java stack whitout commiting to an existing stable technology that will be “dead” soon.

  4. David Carter Says:

    Looks like SourceLabs does have a Java stack: SASH Stack for Java: http://www.sourcelabs.com/SASHStack.htm

    Spring, Axis, Struts, Hibernate, on Tomcat, WebLogic, or WebSphere, with Oracle 10g. I probably wouldn’t pick Struts for new development, but the rest of this stack seems fairly solid. It would be nice to see JBoss as a supported option.

  5. ocnsss Says:

    On personal opinion, I find this very helpful.
    Guys, I have also posted some more relevant info further on this, not sure if you find it useful: http://www.bidmaxhost.com/forum/

  6. swinger Says:

    I agree with you ocnsss.

  7. swinger Says:

    Oh and by the way nice site !

  8. cial Says:

    Hi fosamax

  9. miranda Says:

    very good
    buy xanax

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'

Loading...