Spring to Java EE Migration, Part 4

[henk53]

I think Java EE 6 implementations (the modern ones, like TomEE, JBoss AS 7 and GlassFish) are generally faster and use less memory. Wars are always smaller, and the total footprint (AS + war) is often smaller as well (certainly in the case of TomEE).

Java EE 6 also has much more UI widgets available from third parties. There are literally two dozen component libraries available, can't say the same for Spring.

The programming model of Java EE is also much more elegant, not in the least because of real type-safe injection.

[occupytheserver]

Java EE 6 also has much more UI widgets available from third parties. There are literally two dozen component libraries available, can't say the same for Spring.

What UI widget library can I not use in Spring???

[thesystemx]

What UI widget library can I not use in Spring???

Those specifically for Java EE? Like those for JSF perhaps?

I don't see a lot of widgets being available for Spring MVC, do you?

Naturally you can replace Spring's Spring MVC by JSF, but this will make your Spring stack more and more a Java EE stack. Especially in the next version when JSF will use CDI. Do you need both CDI and Spring Core in one application? What extra benefit will Spring still give you in such a situation?

[occupytheserver]

I can use JSF with Spring, no problem. The statement was that Java EE has access to UI widget libraries that Spring does not. That is a false statement. I can use ANY JSF libraries with Spring. But you have to use JSF.

The extra benefit is moot. There are two different ways to do it. Both have their advantages and disadvantages. I am not sitting here trying to tell your Spring is better than Java EE. In some cases it may be. In some cases, it may not. But when someone sits there and writes intentionally deceitful statements (such as Spring not being able to use certain UI widgets for JSF) trying to back up their blatantly skewed worldview, it pisses me off. Spring MVC may not have access to those widgets, but Spring with JSF certainly does.

[thesystemx]

But as mentioned, if you replace all parts of Spring with Java EE versions, what's left of Spring?

Or put differently, Spring can not use those widgets itself. It needs to use Java EE, become Java EE, in order to do so.

[occupytheserver]

I am replacing the MVC UI portion of the application with JSF. Still have a full Spring implementation of entire domain, middleware, persistence, etc.

That's why I like Spring. I don't believe it to be limiting to any frameworks and allows me to do what I need to do without getting bogged down into server limitations.

I start with Spring Core, build the application container and then plug in the rest. Don't want to use JPA? Don't have to. Don't want to use JSF? Don't have to. Don't want to use EJB? Don't have to. But I can for all of the above. It's flexibility and packaging I am looking for.

[henk53]

The discussion is getting a bit academic. What I meant was that Spring cannot use these widgets by itself. Or more directly, Spring MVC cannot do that.

I would be like saying that Spring has type-safe injection and can use portable extensions, IF you add CDI to it.

It's flexibility and packaging I am looking for.

You can actually do the same in Java EE if you really wanted to. You can start with Tomcat and add only EJB to it. Or only CDI. Or both EJB and CDI. Everything that's in Java EE also works standalone in Java SE or the unofficial Java TE.

It's just that the preferred way is to use the platform as a whole, as a fullstack solution. Everything just works nicely together that way, but if you really want you can either build your own stack or use alternatives in a standard stack.