Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11010

Re: Volunteer for Java Development

Show all headers | View raw

On 11-12-26 11:29 PM, Tom Anderson wrote:
> On Sat, 24 Dec 2011, Lew wrote:
> 
>> On Friday, December 23, 2011 3:47:40 PM UTC-8, Qu0ll wrote:
>>> "Lew"  wrote in message
>>> news:31036852.221.1324660513125.JavaMail.geo-discussion-forums@prfi34...
>>>
>>>> Spring sucks.
>>>>
>>>> Why not use good stuff instead?
>>>
>>> Care to elaborate on that postulation?
>>
>> Conclusion, not postulation.
>>
>> I have used Spring on mnay projects.  It was always a tangled mess of
>> obscure
>> references to extrinsic resources to obfuscate logic.  This may not be
>> Spring's
>> fault, but it's a consistent result.
>>
>> Java EE annotations do everything Spring hopes to, only better, more
>> simply,
>> with a more flowing mental model, in accordance with the standard.
> 
> That is not *quite* true.
> 
> CDI replaces some of the fundamental bits of Spring: the dependency
> injection, and AOP. Done and dusted.
> 
> You could argue that JSF replaces Spring MVC. I don't think it does,
> because Spring MVC is an action-style framework, and JSF is a
> component-style framework. Rather different beasts. There is no
> EE-standard action-style framework, so there is no genuine EE
> replacement for Spring MVC. There are other action-style frameworks that
> are smaller than spring MVC and more aligned with EE (Stripes with the
> injection enhancer, perhaps), so you could argue that modern EE lets
> them make Spring MVC obsolete.

I just don't see the web framework as being something that is part of
Java EE, I really don't. Servlet API yes, web framework no. I'm content
that there's a wide choice list out there, and I'd prefer none of them
to be considered as "standard".

> But there are many other bits of Spring.
> 
> Security? Does JAAS and friends cover everything Acegi does? Don't think
> so.

It's sort of apples and oranges, that. "JAAS and friends" are a
foundation, and there isn't much at all that you can't do with them. But
much of the "final mile" stuff needs to be coded up. That's one reason
security frameworks like Spring Security (Acegi really, it was Acegi's
original motivation) and Apache Shiro have appeared.

This of course is something that we've seen before with "standard" Java
APIs, that they supply the API but a weak or non-existent
implementation. Logging has this problem, XML parsing had this problem,
JAAS is sort of in the same ballpark insofar as to customize and shape
the actual solution a fair bit of coding may be needed.

Another motivation behind Acegi and Shiro was ease of use - a lot of
developers struggle with JAAS. They could do what they need to do with
JAAS, they just struggle. My feeling, having used both, is that Shiro is
better than Acegi at ease of use.

I'll bet you though that 90 percent of developers using Spring Security
are solving application security problems that are actually readily done
with JAAS.

> Web Flow? It's a sort of wizard-based web framework. Does JSF address
> that? Don't know. Does it address it within an action-based framework? No.

I'm not familiar with Web Flow, but part of what it addresses - page
navigation and navigational/conversational state - is very much also a
JSF thing.

On the action-based thing, I think it's worth pointing out that JSF
components aren't involved in the 'C' in MVC. Sure, the components are
sources of action events, but the actual controller logic isn't all that
dissimilar to Struts: you've got an ActionServlet or a FacesServlet
that's (leaving aside filters) the first point of processing for an
incoming request, and further handling is handed off to "actions". We
actually call them actions in Struts, and you have a method in an action
class that is executed; in JSF it's precisely the same as you have a
method in a class that gets executed.

A lot of the things that happen in JSF phases (once the FacesServlet has
started to process the request) are peculiar to the component
processing, and are orthogonal to the "action" type processing that
happens in the JSF INVOKE_APPLICATION phase. Also, navigation concerns
*are* addressed during this "action" phase of JSF.

> JDBC templates? They're simple, but they apparently really simplify JDBC
> programming (for people who need to do raw JDBC).

No doubt. I've been in situations where I'd prefer iBatis/MyBatis to
JPA. JPA is nice stuff as far as I am concerned but it's not ideal for
100% of all circumstances.

> Spring Integration? Web Services? Batch? I have no idea what they do. I
> would be very surprised if *everything* they did was now covered by EE.

I'd hope the web services stuff *is* covered by Java EE. I can't think
of anything I've needed to do with web services that isn't covered by
Java EE.

I'm not familiar with Spring Integration or Batch, but a quick skim at
docs tells me that Spring Integration is about external systems, and it
sure looks like aspects of ESBs are being incorporated also. Java EE
does a lot of that, with things like resource adapters and JMS and what
have you. For the other aspects I'd expect to use (and do frequently
use) Java EE to SOA-enable an application and then use existing ESBs to
handle the enterprise messaging and routing and transformations and so
forth. Can't expect Java EE to do everything - big bits of SOA are not
covered by Java EE.

> So, whilst i agree that EE now does everything the Spring *core* hopes
> to, better and more simply, i think there are other bits of Spring which
> may still be useful. If the Spring guys have a clue, they will adapt
> them to work with EE's DI and AOP mechanisms. Spring has always been a
> layer on top of EE; as EE gains the ability to do certain things well,
> Spring can simply evolve to do other things.

The original fundamental motivation for Spring, and a good one it was,
was that EJBs sucked. How do you look them up with JNDI, how do you
configure them, how much boilerplate do you have to write for each
component, an intrusive and frequently unnecessary distributed object
model, etc etc - old-style EJBs sucked.

Spring basically was originally about being able to give POJOs
J2EE-style services, like transactions, in a much less complex fashion.
And it more or less succeeded in being a lot better than J2EE 1.2 and
1.3, probably even 1.4. It clearly made sense then to use those parts of
J2EE that worked, like servlets, and so all that was a happy combination.

I digress in this fashion to indicate that I don't think Spring was a
layer on top of EE, I think it is a distinct enterprise application
framework that right from the gitgo has used solid parts of EE. But now
that Java EE does pretty much all that you really need, the guts of
Spring are not necessary.

So now it's pure competition: Spring versus Java EE.

> Which is not to say that Spring is the only way of doing these things,
> or is, or will remain, the best way!
> 
> tom

Just my opinion, but the Spring team started losing its way back with
2.x. And with 3.x they are completely adrift. J2EE/Java EE has been
moving in the right direction from a rocky start; Spring started out
relatively simple and clean, and now that entire ecosystem is a rambling
mess.

AHS

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-22 09:25 -0800
  Re: Volunteer for Java Development Roedy Green <see_website@mindprod.com.invalid> - 2011-12-22 14:40 -0800
    Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-22 21:59 -0800
      Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-23 03:46 -0800
        Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-23 09:15 -0800
          Re: Volunteer for Java Development "Qu0ll" <Qu0llSixFour@gmail.com> - 2011-12-24 10:47 +1100
            Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-24 12:33 -0400
            Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-24 10:06 -0800
              Re: Volunteer for Java Development Tom Anderson <twic@urchin.earth.li> - 2011-12-27 03:29 +0000
                Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-27 13:28 -0400
              Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:13 -0500
                Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-28 01:07 -0800
                Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2012-01-01 22:37 -0800
            Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:09 -0500
          Re: Volunteer for Java Development Roedy Green <see_website@mindprod.com.invalid> - 2011-12-23 20:54 -0800
            Re: Volunteer for Java Development Steve Sobol <sjsobol@JustThe.net> - 2011-12-24 00:18 -0800
            Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-24 11:09 -0400
              Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-24 07:26 -0800
              Re: Volunteer for Java Development Tom Anderson <twic@urchin.earth.li> - 2011-12-27 00:53 +0000
                Re: Volunteer for Java Development Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-12-26 22:23 -0400
                Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:24 -0500
                Re: Volunteer for Java Development Steve Sobol <sjsobol@JustThe.net> - 2011-12-27 16:13 -0800
            Re: Volunteer for Java Development Lew <lewbloch@gmail.com> - 2011-12-24 10:10 -0800
              Re: Volunteer for Java Development Sarkar <virtexamit@gmail.com> - 2011-12-25 06:45 -0800
            Re: Volunteer for Java Development Arne Vajhøj <arne@vajhoej.dk> - 2011-12-27 18:16 -0500

csiph-web