I think there are two main areas where standards can fail:

(a) the standard itself is not that good, e.g. forgets some scenarios
or is inspecific or even inconsistent -- AFAIK early versions of
Bluetooth fell into that category
(b) they are not enforced properly

I think point (b) is quite interesting. In theory consumer power could
enforce a standard, but it's like assuming voters cast sensible votes
-- sounds good in theory, but in practice other effects can easily
override the sensible behaviour. As example: SQL was a standard as
long as NIST tested it (and no US government agency bought anything
not succeeding the test), it broke apart when NIST stopped the
testing.

I think Sun is doing the right thing with the TCKs and certification
programs. You can still get something that is kind of JEE but not 100%
-- it just won't be certified. If you want to play the safe(r) game,
you take only certified components.

Coming back to JEE: I must admit that I never bothered to fully read
the JEE spec or actually really check who's certified and who's not (I
think that TCK is only a recent thing and I haven't been in any
position to chose a JEE platform lately). But the issues I remember
were all on a level that I strongly suspect will not be covered in the
specs: the administration side. Basic things like the web.xml might be
defined, but all the other configuation issues are always
vendor-specific and I suspect that they always will be -- a lot of
these things can be OS-specific, too. We have had issues on the Java
API levels, but that's the stuff you can easily file as a but
somewhere. The problem is the stuff everyone declares to be someone
else's problem, which means in the end it is yours since you are the
only one who cares. If it is covered in the spec it is easy to tell
who's fault it is if it doesn't work the way it should.

   Peter

On Nov 15, 2007 2:53 AM, Casper Bang <c...@brunata.dk> wrote:

Its funny how Java EE 6 (http://jcp.org/en/jsr/detail?id=313) is an
effort to standardize enterprise application development. Its got
years of man hours contributions from members such as BEA, IBM,
Oracle, JBoss, Apache.
OTOH, Spring is not standards based and created *mostly* (http://
www.ohloh.net/projects/41/analyses/latest/contributors) by
Interface21.

But now, Interface21 is also started getting involved in Java EE 6
(http://blog.interface21.com/main/2007/09/30/our-approach-to-the-jcp/)

So even though now its a question of Spring vs Java EE, in 3 years
that will become irrelevant. Something similar to the Hibernate vs JPA
argument. In future, a specific profile of Java EE 6 will be a
lightweight IoC framework (thanks to Spring)

Like many of you have pointed out - Innovation happens first.
Successful proven ideas are made standards. Not the other way around.

To answer your question *today* - you don't need Java EE if you get
all the features from Spring. The answer will obviously be different
in 2-3 years.

- vineet

I hope you're right, but will vendors allow JEE to become a
lightweight container if it means the death of the application
server?  Gavin King, who speaks for one such vendor, JBoss, doesn't
even agree that IoC/DI is the proper way to architect enterprise
applications.

On Nov 16, 1:31 pm, vineetb <vineet.vine...@gmail.com> wrote:

NB: for the purpose of my reply, I am going to assume that we are
talking about Java EE 5, and _not_ J2EE, even though that distinction
is not clear in some of the other replies.

Java EE 5 is a huge step in the right direction: getting rid of XML
configuration.

My complaints with Spring are along the lines of Transaction and
Database support being _very_ fiddly.

Also, Spring is broken for refactoring.
E.g. I have a Class A which I'm injecting in one place, and I extract
some method signatures into Interface B, which Class A implements
(without changing _anything_ else in A), but now _everywhere_ that I
inject A is broken.  I think it has something to do with the way
Spring aggressively proxies interfaces?

For someone like me that likes to operate at a higher level of
abstraction, and refine the design, that makes Spring frustrating.

I think that later versions of Spring allow you to use @Annotations,
so Spring will adapt and improve, rather than staying in one place and
stagnating.

As for inversion of control, I don't think that it is such an amazing
thing as to justify an entire framework.  I do like some of the stuff
that comes with the grab bag of stuff.  Their basic web framework was
pretty good (Spring MVC), but there was another web framework which
was horribly broken when I looked at it (i.e. the examples didn't work
as advertised out of the box), which is good for those who require
their web framework to be enormously complex for no good reason.  :D

I think GWT is better than Spring MVC, passing a java object back to
the client side is just too cool.  But all the freebies I get with
Spring MVC are way better than any of the other 'server side'
frameworks I've seen.

One of the things I see a lot of is Hibernate still being a required
skill on projects.  It doesn't seem to have sunken in that:
EJB3 > Hibernate

One of the great things with Netbeans and Java EE 5 was being able to
abstract away from my persistence layer.  Yes, I can use Hibernate,
but I don't have to get my hands dirty with the Hibernate XML files
(because if you do, you are in for a world of pain).  It may generate
the Hibernate XML files somewhere behind the scenes, but as they say
out of sight, out of mind.

Also, Java EE 5 is a nice conceptual fit with JAX-WS, since they are
both @Annotation based frameworks.  I think JAX-WS is one of the more
amazing hidden secrets of Web Services.  I guess because the SOA
pushers would find their business collapsing if Web Services became
easy, and JAX-WS makes them incredibly easy indeed.

On reflection, taking out all the SOA consultants and shooting them
would be an important next step for Java. It seems they collectively
have their feet jammed firmly on the brakes of Java progress, since
they have an agenda of making life extremely difficult for developers,
so that they can push their products and services.  Whereas removing
the SOA bus typically allows you to make _all_ the WS/SOA pain go away.

On Nov 18, 5:04 pm, Rick <rickcar...@gmail.com> wrote:

I think historically there are these waves of theories and
technologies that look good on paper and have good intentions but are
undone by reality and soon become anti-patterns.  Im proud to be the
stick in the mud who says "well that aint going to work" while
everyone else is calling me a flat-earther.  Perhaps thats why I
havn't done so well as a consultant. :)

True, but a good IDE (e.g., Eclipse) will refactor fully qualified
class references in text files, including XML, so from a practical
standpoint this isn't an issue.

Annotations are neat-o, but inappropriate for many problems, of which
DI is one.  The goal of DI is to separate the concern of wiring
application components; peppering DI annotations throughout a codebase
isn't separating anything.  Moreover, they entail a close coupling to
the DI framework (be it Spring, Guice, EJB3, or whatever) that is
undue.  Consider a generic library/framework consisting of a graph of
POJOs used by several projects that each use a different DI
framework.  Should the POJOs contain a sum of the annotations from all
the DI frameworks?

Indeed, those that employ DI might prefer to write the wiring code
manually, and I certainly wouldn't argue with that approach.  Perhaps
the appeal of Spring is that it standardizes the pattern.  Of course,
Spring entails other value-add features such as AOP and factory bean
awareness, and some might find the XML-config approach convenient.

I love GWT and use it on web projects whenever I can; never used
Spring MVC.

Some might use Hibernate simply as an EJB3 implementation.  I have
(but must confess to find occasion to use some Hibernate-specific
annotations...)

Some might argue that contract-first is the proper methodology for web
services, but I myself find JAX-WS too convenient to ignore.

That is an interesting definition.  I'd have said:

The goal of dependency injection (DI) is to solve the design problem
"how do these two objects know about each other?"

I have to disagree.  There are simpler solutions if the goal is simply
to solve the dependency problem, e.g., singletons, factories.  The
goal of DI is not only to solve the problem, but to do so in such a
way that values and adheres to the principle of separation of
concerns.

On Nov 19, 12:50 pm, Rick <rickcar...@gmail.com> wrote: