Java Web Application: To Spring or Not To Spring

SimonTemplar

I'm designing a new internal web application for my company. I'm curious what architectural considerations determine if the Spring framework should be leveraged when developing Java web applications or simply rely on standard Servlet functionality.

Any opinions would be welcome.

MajesticDonkey

Just started with Spring myself. Quite easy to use and get an app up and running quickly. It also has great support for MVC stuff like view resolvers (Thymeleaf in particular).

GreeBo

SimonTemplar wrote: »

I'm designing a new internal web application for my company. I'm curious what architectural considerations determine if the Spring framework should be leveraged when developing Java web applications or simply rely on standard Servlet functionality.

Any opinions would be welcome.

Unless you are doing something ridiculously simple (HelloWorld) there is no point in rolling your own flow/mvc code on top of raw servlets, make your life easier and grab *any* web framework.

TrueDub

And to follow up on Greebo's post, if you're doing an MVC app that's predominantly server-side (as opposed to a javascript type one), Spring is the quickest to get up to speed on, and the most flexible to configure.

All IMO of course.

Sheeps

spring

croo

I'd say spring too - you can use what you want and leave what you don't.

ChRoMe

Spring is basically a requirement at this stage to do a Java web app.

Johnny Jukebox

Completely disagree.

There is nothing you cannot do in JEE6 that you can do in Spring. For me, JEE6 is the more complete, standards based approach for Enterprise and Web development.

And check out JBoss Forge 2 for a super RAD toolset.

croo

Johnny Jukebox wrote: »

Completely disagree.

There is nothing you cannot do in JEE6 that you can do in Spring. For me, JEE6 is the more complete, standards based approach for Enterprise and Web development.

And check out JBoss Forge 2 for a super RAD toolset.

To be honest I have not even looked at JEE (J2EE) in many years... purely because Spring worked. Maybe I should broaden my horizons. I'm sure I can google any number of for/against blogs but, from your perspective, does JEE simply standardize the functionality & flexibility of Spring or does it move things forward? Is there any specific new ideas I should be looking at in JEE?

Finally, any reason why to specify JEE6 rather than the newer JEE7?

moycullen14

ChRoMe wrote: »

Spring is basically a requirement at this stage to do a Java web app.

Spring, like hibernate, is great for rapid development. I spend a lot of time dropping in on projects where Spring has been used for a long time. One of the characteristics of such projects is the wide variety of ways in which Spring is used. Often any architectural decisions or methodology has been long forgotten and there is very little knowledge of how or why things work.

This is all fine until something goes wrong and you have a mish-mash of approaches, lack of knowledge and general head scratching.

Problem seems to be that Spring is so wide-ranging that people don't/can't understand it - they simply want a 'how-to' guide which can and does lead to unmaintainable systems.

Long story short: Great for rapid development but can be a pain to maintain, particularly if the development has been done in an 'ad-hoc' fashion.

Oh and I think IoC is the most overrated and abused pattern out there.

croo

moycullen14 wrote: »

Oh and I think IoC is the most overrated and abused pattern out there.

Funny, I thought it was the simplest, most innovative, idea I saw in decades!

moycullen14

croo wrote: »

Funny, I thought it was the simplest, most innovative, idea I saw in decades!

OK, it was a bit of a troll but.....

As a concept IoC is great but the implementation, especially in the wrong hands or in the case of very large systems, can be horrendous.

Start off with hundreds of POJOs, DAOs, DTOs, service & Management layers and you can end up with thousands of XML files to configure a system. If there are single implementations for each interface (aside: how many interfaces are actually implemented more than once?) then what's the point?, If there are multiple implementations (notable exception is testing/mocking) then how do you figure out what is actually been used?

Too often the coupling that we try to avoid has just been pushed out from the core language (e.g. java) to a configuration file (XML) which has the effect of making traceability much harder. It's kind of like '#include' in C - meant to make life easier but just adds complexity and coupling in different areas.

Don't just dismiss it as a 'bad' implementation. I've seen it happen too often for it just to be a developer aberration. Too many patterns and development methodologies break down in the real world.

Maybe I'm just jaundiced at the moment because I'm looking for a connection leak in a system whose design goal seems to have been 'Let's see if we can use every pattern and package known to man to implement this system'.

My job would be a lot easier if the initial developer had never heard of GoF!

GreeBo

XML config is SO last season, annotations my good man, annotations.

That way you dont have a means to trace whats happening until runtime, super fun times.

croo

moycullen14 wrote: »

Too often the coupling that we try to avoid has just been pushed out from the core language (e.g. java) to a configuration file (XML) which has the effect of making traceability much harder.

While I see your point to me the key difference between configuring in code and XML files is that you can change the XML config and at most you can expect to just restart the app, but if you must change the config in the core language then you must recompile/build & redeploy. But again I completely agree with the comments re testing & debugging... it's a bitch in XML. All those great debugging tools developed by the IDE teams become useless.

lemon_remon

Guice is the **** compared to Spring when it comes to IoC. Much simpler, no XML, no configuration and you get real type safety. Play is also a better MVC framework than Spring.

moycullen14

lemon_remon wrote: »

Guice is the **** compared to Spring when it comes to IoC. Much simpler, no XML, no configuration and you get real type safety. Play is also a better MVC framework than Spring.

Will someone please think of the maintainers?

Great, so the next eejit who comes along will use these and we'll be left with a project with two more bits of technology that nobody understands. Why, because they're better!

Just for once could we not leap on the 'next big thing'? Wouldn't it be much better if we refined our knowledge and experience of current technology. You know, do it properly with the tools at hand rather than leaping onto the next bandwagon.

Was at a presentation recently about Java 8. All were raving about lambdas and functional programming. No mention of the pile of sh**e in the existing code and the vast swathes of developers that still don't understand Collections (List vs Set, anyone?). We seem addicted to shiny, new toys.

If I ruled the world then the criteria for introducing a new piece of technology/framework would be: One in, one out.

Rant over

Oh and I'm sure you're right re Guice & Play. It's just that I can't see them solving problems with existing code.

moycullen14

croo wrote: »

While I see your point to me the key difference between configuring in code and XML files is that you can change the XML config and at most you can expect to just restart the app, but if you must change the config in the core language then you must recompile/build & redeploy. But again I completely agree with the comments re testing & debugging... it's a bitch in XML. All those great debugging tools developed by the IDE teams become useless.

But my XML is in a jar/war.:( I have to stop the app, unpack the library, edit the XML, save it, repack the jar/war, restart the app. This is where technology has really overtaken received wisdom. Nowadays rebuilding an app is dynamic and just as fast as editing a text file so the old saw of 'avoid recompile/build with external configuration files' is no longer true. In fact there is much more support for dropping in changed code to a running app than there is for dynamically recognising configuration changes.

Technology evolves; patterns, practice and received wisdom take a while to catch up.

You're dead right about the IDE support for XML testing/debugging.

carlmango11

moycullen14 wrote: »

But my XML is in a jar/war.:( I have to stop the app, unpack the library, edit the XML, save it, repack the jar/war, restart the app. This is where technology has really overtaken received wisdom. Nowadays rebuilding an app is dynamic and just as fast as editing a text file so the old saw of 'avoid recompile/build with external configuration files' is no longer true. In fact there is much more support for dropping in changed code to a running app than there is for dynamically recognising configuration changes.

In a dev environment, yeah. But once you ship something it's nice for to be able to configure it without having to go back and repackage it all

ChRoMe

moycullen14 wrote: »

Spring, like hibernate, is great for rapid development. I spend a lot of time dropping in on projects where Spring has been used for a long time. One of the characteristics of such projects is the wide variety of ways in which Spring is used. Often any architectural decisions or methodology has been long forgotten and there is very little knowledge of how or why things work.

This is all fine until something goes wrong and you have a mish-mash of approaches, lack of knowledge and general head scratching.

Problem seems to be that Spring is so wide-ranging that people don't/can't understand it - they simply want a 'how-to' guide which can and does lead to unmaintainable systems.

Long story short: Great for rapid development but can be a pain to maintain, particularly if the development has been done in an 'ad-hoc' fashion.

Oh and I think IoC is the most overrated and abused pattern out there.

That's nice, all it shows is that you are working with bad developers. It's nothing to do with the framework/technologies used.

lemon_remon

moycullen14 wrote: »

Was at a presentation recently about Java 8. All were raving about lambdas and functional programming. No mention of the pile of sh**e in the existing code and the vast swathes of developers that still don't understand Collections (List vs Set, anyone?). We seem addicted to shiny, new toys.

If your developers don't know the difference between a Set and a List (my little brother in first year CS does) then I'd be much more worried about your hiring process than what frameworks you're using. Lamdas make code easier to read and maintain because you can do things like abstract the concept of a loop into a reusable chunk. That's how they can improve existing code.

Guice is an easier framework than Spring to learn. That's pretty much a fact. New developers joining your team, especially interns and new grads, will have a much easier time using Guice effectively than Spring. It's hardly cool new tech. It's a very well respected and known framework. Just because Spring is popular doesn't mean it should be the default framework to use. In most cases for simple Java web application then Spring is an overkill. You'll end up developing around the framework rather than developing around your business code. This is why I'd recommend Guice over Spring for a project like the OP's.

ChRoMe

lemon_remon wrote: »

You'll end up developing around the framework rather than developing around your business code.

Can you provide an example?

GreeBo

lemon_remon wrote: »

You'll end up developing around the framework rather than developing around your business code.

I find the opposite tbh, with simple app's using a fwk like Spring means I am developing business code much faster and not writing boilerplate crap.

If you are having trouble with spring fwk it might just mean you arent using it as it was designed...

ChRoMe

lemon_remon wrote: »

Guice is an easier framework than Spring to learn. That's pretty much a fact.

Looks like subjective opinion to me tbh.