Link Details

You should define what you mean by "lightweight". The word means something very specific in Spring that has nothing to do with anything in your blog entry. Spring does not claim to be "lightweight" in other ways.
,

The Spring programming model (if used correctly) is still light weight. But their product offering has become no different than that of IBM or Oracle.

To be honest, I think that Spring has had its best time in the community. Rod and investors made a lot of money, but Spring isn't going anywhere any more. Large frameworks are something of the past. Personally I think the future is with more flexible languages like Scala that reduce the need for heavy weight frameworks.

The same was true in the past when Java arised. New languages like Scala are cool and flexible today, but in the future there will also be many frameworks or extensions. IMO thats natural evolution of programming languages.

As long as Spring Source still advance the Spring Framework and dont switch to some commercial licensing, everything is fine to me.

I mostly agree with you Peter and for someone who has worked at JTeam your remarks really have some substance. The Spring model is lightweight, but so is EJB3 these days. Both in size and in complexity Spring is very on par with Java EE. It's just a different offering...

Occasionally I still catch people chanting the old mantra that Rod learned them : "Spring is lightweight, Java is heavyweight, Spring is lightweight, Java is heavyweight", but this is just insanity. Rod's offering is really quite equal to the JCP's offering. If fans of one of them calls the other a totally wrong direction, then it's just fools speaking...

That said, I do like the model offered by Spring and EJB3. Not saying it's necessarily the best for everyone, but personally I like it.

You are correct that it is a part of life. One of the 'selling' points of ruby for example was that there was a fixed set of tooling.. and see how many solutions you can find today for the same problem today.

But I think that with a more flexible language there is a lower need (so there is a need, but lower than with a fixed language like Java) for external libraries. It could be that I'm wrong.. who knows :)

I was more of expecting lightweight comparisons in terms of heap size requirements.
I want to develop simple website portal, and i am always thinking, is it worth to go through pain of learning mvc+webflow or just use stripes + hibernate.

MVC and Webflow is just a small subset of what the whole Spring Frameworks offers.

Is this article really about the spring framework, or the product line offerings of SpringSource? Who cares if they have their app server wanna be stuff. Don't use it if you don't like it (works for me). But don't say that because it exists that the spring framework is somehow bloated by this.

>Don't use it if you don't like it (works for me). But don't say that because it exists that the spring framework is somehow bloated by this.

Oh, yeah... sure... now it's suddenly okay to simply not use stuff that you don't use and stuff that exists now suddenly doesn't bloat anything just by its existence. But when you (you as in Spring fans in general) talk about Java EE then it's suddenly not okay to simply not use stuff??

I still use Spring for even projects that last only a few days. That qualifies as lightweight in my book. And no it didn't cost anything.

Spring isn't lightweight and neither are AspectJ and OSGi that SpringSource tries to impose on the world.

Looks like nobody has defined what "lightweight" actually means. You can't argue that Spring is or is not lightweight unless you actually define what it means. Here is my own take: http://chriswongdevblog.blogspot.com/2009/09/on-lightness-of-spring.html

I also came up with a bunch of criteria a little while ago for what lightweight means, ranging from resource usage to deployment time to complexity - see http://impalablog.blogspot.com/2008/05/what-makes-technology-lightweight.html. On the strength of these, I'd still argue that Spring itself is still lightweight, but some of the more recent innovations (such as their work around AspectJ and OSGi) is less so.

Remember Lightweight is relative to EJB. Still using EJB and having come from a spring shop, yes Spring is "lightweight". Compared to various other technologies/platforms... no it's a heavy enterprise software platform. I'd still kill to use it over EJB 3.0.

In terms of mental complexity, size of API, size on your HDD, Spring was more lightweight than EJB2.

With EJB3 it's the other way around. EJB3 is definitely lighter than Spring. I wouldn't mind working with Spring if I had too, but if there's a choice EJB3 would be my first choice and Spring only my second. (not using either one of them in any reasonable size project would barely be an option for me)

Don't be sure about not using Spring or EJB in real projects, even the big ones.
That's exactly what I have done for the last several years, I and would do it again for new projects. These so-called "application frameworks" are highly overrated; with good architecture and design, the typical technical problems can be solved effectively with just, say, JPA and GWT.

if only core EJB3 with annotations were enough. Techinically, I can get the same power using Annotations in spring, it just takes a bit more initial setup. The gain comes in when I have to add something *interesting* to my system (i.e. not just vanilla business logic), or when what I need to do doesn't fit one of the 4 boxes EJB gives me. That's when you notice *all* of EJB3's complexity. Comparatively, spring is lightweight. It does not rely on JNDI for lookup/injection, you don't have to make use of AOP if you don't want to, It works on raw classes, and you can control scope/lifecycle, etc.

Working in EJB3 now coming from Spring, I can see a lot of features lacking in EJB3. You tend to go to your container for these features, and they tend to still be just as strange as EJB2 (although some are getting better).

The biggest problem with EJB3 is not giving up control over features, but the inability to take back control when you need in the framework. EJB is a framework where you either live very high in the stack, or you live at the bottom of the stack. It doesn't really give you in-between options. Spring lets you dig in as much as needed to solve your issues (at least in my experience).

Also, EJB 3.0's dependency injection is anemic. You have to use something like Seam to make up the difference, or deal with strangeness and inefficiencies. Have you had to take back control of transactions from EJB? It's not fun.

"if only core EJB3 with annotations were enough. Techinically, I can get the same power using Annotations in spring, it just takes a bit more initial setup."

Which does make EJB3 lighter than Spring now. It used to be the other way around, but for a lot of common tasks, EJB3 is simpler to setup and it still gives you a LOT of power. A plethora of transaction types, incredible easy use of the entity manager, easy injection, etc.

>when what I need to do doesn't fit one of the 4 boxes EJB gives me.

Those 'boxes' are really powerful and seems to be fitting for the majority of the use cases.

When you want something not directly supported by the framework, it's difficult in ANY framework. Spring wraps a lot of other stuff that you must manually access when Spring doesn't give you the right amount of abstraction. Then you really get confronted with whatever Spring abstracts for you and which might have its own quirky API. THAT is the complexity of Spring.

Yes, when I wrote that article I wasn't really talking about 'lightweight' in terms of the actual programming model. The core spring framework is still pretty lightweight, you can pick the add-ons you like and ignore the stuff you don't.

I guess my issue is that it's getting hard to figure out the difference. Which of the extras being pushed by Springsource would be useful for my project, which are too heavy, expensive, or just not applicable for us? Figuring that out requires wading through loads of enterprise solution-speak, which is what sparked the original post.
,

What happens to Spring is natural (and absolutely normal). Once you get VC money in there are clear expectations on growth and they can't be met by simply "selling" Spring framework. They had to grow and all but exited the low end of the market and moved up market in the same time. Hence all the acquisitions and new products from Spring.

Yes, I don't believe Spring is lightweight anymore in the same sense it was 3 years ago. But Spring is targeting a different audience today and I'm totally expecting new crop of innovation come from something like Scala community. We'll have more "Springs" in the future...

the thing about spring is, it allows me to use the parts I want to.. for example I might use spring dao with hibernate, it's transaction support... most java projects done using spring uses aop only for transactions and a bit for security.

i might use jdbc or hibernate or anything else.. i dont have to build an abstract factory for dao layer, or some service locator for the service layer.. its all there for me with di.

that said, unless you have a project of reasonable complexity using spring/hibernate is not a good choice..

say u have a project with some 9 or 10 tables, with one to many, many to many relationships etc, and the largest table will have like 20K records, then you are dealing with a trivial application.. spring/hibernate will be too complex for it..




,the thing about spring is, it allows me to use the parts I want to.. for example I might use spring dao with hibernate, it's transaction support... most java projects done using spring uses aop only for transactions and a bit for security.

i might use jdbc or hibernate or anything else.. i dont have to build an abstract factory for dao layer, or some service locator for the service layer.. its all there for me with di.

that said, unless you have a project of reasonable complexity using spring/hibernate is not a good choice..

say u have a project with some 9 or 10 tables, with one to many, many to many relationships etc, and the largest table will have like 20K records, then you are dealing with a trivial application.. spring/hibernate will be too complex for it..

",the thing about spring is, it allows me to use the parts I want to."

The thing is, this is true for Java too. Java offers a lot of functionality in its standard API, but if you don't want to use it, don't use it. It's as simple as that.

In the past Spring zealots have discarded that argument and saying that it was nonsense. The mere fact that the Java API is so complete was bad to them; somebody else might take advantage of a part of the API that you choose to ignore. When you have to read or modify that code, you're still confronted with that part of the API.

In the past few years, the Java API has gotten way simpler. Granted, all the old cruft is still there (like home interfaces and bloated XML deployment descriptors), but they are clearly marked as deprecated and nearly ever Java book tells you what is deprecated and what is not. XML hasn't exactly been cleared up (it's still as needlessly verbose as ever), but it has been retrofitted as a means to override the new default mechanism: annotations. Since overriding is much less common than actually declaring stuff, most people get saved from coming in touch with the XML deployment descriptors.

During the same time, Spring has been enriched with more power and more functionality. Only now, all of a sudden, Spring zealots don't mind that there is extra power lurking in their API. The same argument they used to beat Java to death in the past is suddenly shrugged away when it applies to themselves. I find this quite hypocrite.

I think you worry more about what Spring zealots say. I think you should ignore them, for that matter any zealots.

Spring has its uses. It's good to learn and apply where it's required. But, if I'm given a Java EE server, then I don't think I'll consider Spring. To me, Spring value proposition is very high when you don't have a complete application server or you have it, but it's still J2EE standard, so Spring is an obvious better choice than EJB 2.x.

I don't understand these technology wars. Customers don't care why someone thinks EJB 3 still sucks more than Spring 2.5 etc. I think it's common to find developers without any objectivity these days, more so common in Java.

"I think you worry more about what Spring zealots say. I think you should ignore them, for that matter any zealots."

I agree with you. The problem is that Spring zealots have been VERY focal in the past. I heard stories where hordes of Spring zealots where instructed to build up a number of 'digital lives' in the blogosphere and post on blogs and forums about the merits of Spring and the badness of Java. I know other organizations do this too (mostly those obscure SEO ones), but it's an indication to what length those zealots went.

Now if nobody listened, then they would be just zealots. But at some point of time they got some critical mass in the blogosphere. I started to notice when more than a few developers who were new to Java, started using Spring for their projects. I asked them in all honesty why they choose Spring. After all, there definitely are good reasons for using it. They told me however that they googled around a little and that it was clear from reading blogs and forum posts that Spring was the best. I asked them why they didn't use Java EE and EJB3 and they immediately responded that they read that Java EE was bad. When I them asked them WHY, all they could say is that it was because Spring was lightweight and EJB3 was a container (???). When I asked them WHY a container is supposedly bad, they said it was because it wasn't lightweight. When I then finally asked what they thought lightweight actually meant they really couldn't give me an answer. After some lengthy debate it usually boiled down to them saying that lightweight means it's Spring.

At that point it became clear to me those people where falling in the traps of the Spring zealots.

Lately more people have become aware of this though, and the entire scheme is backfiring a little, but it did bring a lot of new people into the Spring camp up till a year orso ago.

"Spring has its uses. It's good to learn and apply where it's required."

Absolutely! Spring itself is not a bad platform at all. I initially loved it a lot, and technology wise I still do. It's just all this zealotry I don't like about it.

Anyone new to Java should never start with Spring/Hibernate. They will never learn a lot of important things about Java. For example, at the DAO layer, I would expect any developer to know how to code in JDBC, handle checked exceptions, close connections correctly and apply abstract factory pattern. All of this, and many more that Spring automatically does under the hood is cool, but people must learn the Java standards first. And people forget JDBC is a standard.

I think EJB 3 adoption will increase once companies upgrade their J2EE servers to Java EE versions. It's surely going to take time, and I'm not sure if the banks will do it in another 2 or 3 years, as they are very slow to take on new technologies.

Half of that list of things to expect developers to know disappears when you choose another language. Closing connections properly, Checked exceptions and abstract factories, those I don't find improving the code of my developer team. Closing connections properly is something that could be abstracted easily and usually isn't because it requires the use of inner-classes in Java. Because it's so easy to get wrong (even by the experts), why write it more than once?

Also, I think Spring is a good place to start learning Java, not because I'm a spring zealout, but because I believe composable/modular design are the way to begin teaching Java. You could also start with Guice or PicoContainer or Seam, if you wanted to describe how to compose your software. EJB is *not* very lightweight in this area (you need JNDI... it's not optional), and it's the main reason to choose Guice and/or Spring for teaching.

EJB can be used in this manner, but I've found some interesting issues. Basically, if spring does the wrong thing, it's easier to inject new functionality (same is true of any system architected on IoC). EJB is a Spec where each container does things differently under the hood. Therefore there's a mismatch between how I would do things in EJB or using the app servers mechanisms. This mismatch has been causing me many issues as of late, and is why I think EJB is heavyweight, and would prefer something where "diving in" is more incremental.

I don't totally agree. You can just pick one Java EE implementation and stick with that. You may get exposed to some AS specific stuff here and there, but it's not a lot these days, especially not with EJB3.1 which finally standardized some much needed unspecified stuff.

Don't forget that with Spring too you get confronted with implementation specific quirks and let's not forget the quirks of the API itself and the way it happens to be implemented in some specific version of Spring. No single API is perfect. Not Java's and not Spring's... you almost always come in touch with 'private implementation details' at some point or another. Springs wraps a lot of stuff (Hibernate, Quartz, a transaction manager) and there can be unforeseen interactions which force you to work a little outside the path Spring paved for you.

Saying that Spring is totally right and Java EE is totally wrong is just... wrong...

They both have their strong and weak points and in the end they solve a lot of things in similar ways.

"Half of that list of things to expect developers to know disappears when you choose another language"

Well, can you show me how many languages use DI, AOP?

Reg. design patterns, Spring itself uses many of them. Spring DAO uses factory pattern under the hood. Between Spring & Hibernate you have about half a dozen patterns you must know to effectively use the framework. How many languages have that requirement?

It is important to learn frameworks like Spring, but it is more important to learn the underlying core technologies.

i meant to saw medium sized application.. its not trivial.. for sure.. not big app as wlel.

Lightweight = tools + ioc + mvc + db + aop + tx < 800KB
Then check http://jodd.org :)