The Pathfinder

I think spring rock!

Regarding 1/2/3

You don’t have to use XML configuration there are multiple options to configuring Spring. Annotations, XML, JavaConfig or use the Spring low-level-api yourselves. When you leave the realm of XML configuration you will be able to have strong typed back, no large xml files.

Regarding 4
Depends on what you want to use of Spring, if you want to use only DI and maybe some utility classes Spring is quite lightweight, if you want to use something more Spring becomes a bit more heavy. The only lag we experience is the 30 seconds startup time of tomcat, however this is mainly due to our database connection setup.

Regarding 5
Which features are you talking about? We use Spring transactions, aop support, without any hard reference to Spring? If you use Spring MVC your web-layer is referencing Spring, however you lower service/business/dao layer can stay clear of Spring.

Also as of Spring 2.0.x it is recommended that if you use Hibernate/JPA that you don’t use the Hibernate-/JPATemplate approach anymore. But the normal recommended approach (for Hibernate that is the currentSession approach), this doesn’t tie your dao layer to Spring in any regards.

>Well Id say I don’t like Spring Java Config and Spring XML
>Config in such a fashion because those configuration is
>bloated !!!. Spring Java config is another reincarnation of
>Spring XML config. The different part is in spring java config
>you use Java so the type checking does apply, but not
>reducing the amount of code that you should create ! no
>large xml files but you still found mountain of java config
>code.

What about annotations? More precise: What do you really expect? There has to be some configuration, stuff won’t happen by magic.

>:) im just saying Spring is not light weight anymore there
>are other framework does perform much much better than
>spring.

Name one, up to now you’ve just been hinting about that super fast and easy to configure framework.

>If you mention 30 seconds, that is too subjective, if other
>framework can perform in only 5 seconds instead. Ill
>choose other, the reason is simple … I need good
>performance application. In mission critical application a
>second means a lot.

He was talking about startup time… besides, I don’t think you can cut down on DB connect time by using another framework.

Hoogla Boogla

Hoogla Boogla,

Guice has been described as MUCH faster than Spring. Of course, all it does is DI, so it may not be appropriate everywhere Spring is, but if all you need is DI…

Jason Lee

I think you’re absolutely right. Spring adds too much complexity to application configuration.
All spring evangelists talk about unit test and the power of DI for testing your classes. But IMHO a simple straight java code easily readable by human is much more effective to decrease maintenance cost than any junit testing.
Often people that work on a project change and complexity causes the learning path for new developers too slow.

This post has the fascinating title!

It’s clear from your arguments, that you don’t have very much experience using spring and are speaking out of pure ignorance.

I’m not sure if I agree with your logic in this post… but I think it is a good idea to carefully consider whether Spring is right for your project or not, as I described in my blog on Dependency Injection

Spring isn’t just about IoC. Its a full stack for writing web and client applications.

However, if you only want to compare the IoC capabilities of Spring, then you are simply talking about the spring-core library, not the spring-full library which is enormous and includes a ton more features. Thanks to the care and effort that the spring developers put into code organization you can use only the modules that you require for your software.

Compare Spring IoC to other frameworks. Specific frameworks, and write a new post.

Regarding #5, I am agree to BlogReader. Spring team has done a good work in modularizing their library. Beside, I don’t mind to ‘tie my code’ to Spring (or some other libraries) as long as it gives value to me. It’s analogous to every java code which is ‘tied to JDK libraries’. If we can put aside the fact that these codes are coming from JDK, than we’ll be faced to the decision whether it gives value to us.

Spring will always be a controversy, because of its initial statement that we can have Java EE without EJB. People will always remember that and will come to Spring team to ask for their promise that Spring is lightweight. It’s like they have set the “high” bar that they need to fulfill.

My opinion about Spring is it’s a framework that helps you to code in a right manner (although still many people doesn’t get that), makes it look more elegant. It tries to make a common approach on the way we use various library (ORM, JMS, etc) in various layer. Isn’t that good compared to each company has its own unstructured/unmaintained/untested/undocumented/single-person-owned library. (Note that you can always choose not to use these “bloated” extensions if you decide to only use Spring IoC, and make your own integration code)

In reply to HRM:

1. Is it ‘Spring based app’ or is it ‘Your app’ that is hard to debug. Many thought that they won’t get problem if they use spring in ANY way. So they use spring in the “wrong” way and expect it to return good results. Like always, you can choose not to use XML, if only you know about that.

2. It’s a problem of “non-documented application”. Irrelevant.

3. Yes, it is. It requires so because it tries to carry you to a higher level (abstraction) thinking.

4. Yes, if you don’t know how to do things. Beside, Spring has a large community which you can share and learn with.

5. Yes, that’s why Spring now came with JavaConfig. Domain Specific Language is also an alternative. But IMO there’s a limit in the way we reduce complexity, because complex business model will somehow reflect in your code. If it’s so simple than it will mostly be a “hello world” application .

6. Agree. Library switching is not an easy decision. No body seems to care a lot about these when they decide to choose Spring as their framework, at least I don’t.

7. You can always choose other mechanism instead of XML.

This is so lame.

IoC is just a small part of Spring. The rest is AOP and integration with lot of different technologies.

Spring is slow? Mind elaborating on this one? In my experience, what’s really slow is the hibernate initialization. The rest comes up really quickly.

Also I don’t see how Spring forces your code to be depending on Spring. The whole point of IoC is to reduce this dependency.

I’m not very fond of xml. In fact, since had to write wsdl files by hand, i can say that in general I strongly dislike writing xml. Fortunately the xml config of spring is rather sane and I can live with it.

The author’s profile says:

Passion: To Simplify Java Development

1. Spring configuration is bloated.

Things that used to end up in code are now externalized in configuration. Not a bad thing.

Application context files can be broken up into pieces, just like the rest of your app can be layered.

You’ve got to say it somewhere, whether it’s a call to “new” or configuration of the bean factory.

2. Putting configuration into XML is painful.

I don’t find it to be so. This is simply your opinion. Interface 21 has put effort into responding to this admittedly
common criticism by using more annotations in Spring 2.0 and 2.1.

An IDE like IntelliJ not only makes it easy to maintain XML configuration files, it’s smart enough to cross-check it with the classes in your app. Maybe you just need to get a better IDE.

You don’t say what your preferred alternative is. Do you like hardcoding everything in your source more?

3. You loose Java Strong Type Checking if using XML configuration

I don’t agree. Spring encourages the use of interfaces, which is also a Java best practice. When you inject a particular implementation behind a Java interface, you’re taking advantage of the best of object-oriented programming (encapsulation and information hiding). Why do you have to know the runtime type of the implementation class? Why isn’t the compile-time
interface type sufficient?

4. Spring is not light weight container.

Not fastest? Data, please.

Do you mean “fastest to start up”? Personally, I don’t care. I find that using Spring with Tomcat, Jetty, or WebLogic with
IntelliJ is more than adequate. I never find myself saying “It’s already been five seconds – why does Spring take so long to start?”

“Fastest in production”? Compared to what? Data, please.

If it’s Guice or another DI framework, that’s fine. I think Spring is providing a lot more value that just being
the fastest to start.

Spring has always been heavier than PicoContainer. But Spring is more than DI – it’s AOP and a library of exceptional
plumbing classes that you can use. I get to leverage the crystalized experiences of a team of top-notch, experienced
consultants and developers. Their best practices tend to mean no memory leaks, no dangling resources, no lost database connections, and well-layered code.

5. Spring is a Container that promise us to build loosely coupled application.

What? Is this a criticism? Do you find that Spring makes your apps tightly coupled?

You can write bad code in any language, with any framework. I’m sure it’s possible to make a huge mess with Spring. I just haven’t seen it yet.

PS – It’s “You lose Java Strong Type Checking if using XML configuration” Both your spelling and arguments leave a
great deal to be desired.

You must check Mentawai: http://www.mentaframework.org/

I agree with you. It all comes to a matter of how simple you want to be and how big is your system. Many, many systems are using Spring but they really do not need Spring.

-Sergio

HRM If you are not the one who was developing it, and there is no up-to-date documentation, the whole Spring based architecture is a lot of pain to understand.

You can s/Spring/whatever/g and the statement will still be true, which means that this point means nothing.

Perhaps it would be better if you could explain exactly what’s wrong and how other ways of doing it are better. Do you think a homegrown framework is better? Good luck interviewing people with experience in the FooBar framework.

Interesting reasons for “why not to use it”, but he is not saying “i use X framework because it solves my problems”.

On the other hand “1500 classes in that project, and separated to more than 11 modules” … exposing 1500 classes sounds a bit strange, i cannot comment as there is no description of the problem being solved, but putting a hand up in the air, i think there is over-engineering and/or scope creep from the techies !

1. Spring configuration is bloated.
My team develop enterprise application using Dependency Injection framework. There are more than 1500 classes in that project, and separated to more than 11 modules….

Which framework can do the stuff for you? If you have naming conventions in your project (and team) then you can use autowiring easily, and if you don’t then that’s a shame for a team developing a huge project.

2. Putting configuration into XML is painful.

XML configuration is painful, the context painful is not something concerning how top coder you are, but more on maintenance…

Use the tools! and good documentations (even with Spring’s BeanDoc)

3. You loose Java Strong Type Checking if using XML configuration

When you start using XML configuration, you will loose the power of java. When you lucky the object that you inject into the bean is not what the bean wanted…

The same problem with annotations, and other stuff, or you can hard wire your classes and don’t use any DI!

Some Configuration not using XML but in Java class, in GUICE you use module, If we want flexibility, we still can achieved by separate the business logic jar into another archive, and in the core jar we just put Class.forname(”the module class”). Thats all

Can’t you do that with Spring!? and what does GUICE do for you then?

4. Spring is not light weight container.
Unfortunately spring is not light weight anymore. Today Spring performance is not the fastest anymore, there are more lightweight container exist out there where the performance is better.

Use only the DI and compare it with other frameworks! Please give the benchmarks, otherwise all you said are just bullsh.t!

5. Spring is a Container that promise us to build loosely coupled application.
Spring is a container that just promise us to build loosely coupled technology, spring does not really concern that much about tightly coupled….

If you understand Spring you don’t need any coupling to it except for the Web MVC!

And if I write an application using Hibernate my application is tied to Hibernate lol
if I write an application using Struts my application would be tied to Struts lol
if I write an application using Servlets my application would be tied to Servlets! lol

Yawn…

point 1 – Use decent IDE. Both Idea and Eclipse + SpringIDE cover that “extra very careful” refactoring challenge.
point 2 – Use spring 2.0 namespace support and put your configuration in some other format, don’t use xml, etc. This is not a reason in my book. See point 1 above and write some brain dead unit tests that load your config and alert you to the problems BEFORE production.
point 3 – see point 1. USE DECENT IDE already
point 4 – Ah? Are you going to switch between IOC frameworks any time soon? This is not making sense at all
point 5 – What are you talking about?

All in all, ask around to learn better strategies in dealing with your chosen frameworks/tools before making immature remarks

Dmitry

I would like to know from Arif on the alternative solution he recommends using in place of Spring container.

One than I definitely hate about spring is that the inagility it causes. It discourages frequent refactoring.
Refactoring java-code would require you to reflect to the configuration. The best you can do is by find-replace. It uses ad-hoc technique, and obviously, not too robust and efficient. There’s no compile-error as well. Developer tends to hesitate doing refactoring when dealing with spring.
This remains true whether you use javaconfig, xml, properties-based, or annotation.

Who ever said that you have to use DI on every bean in your application. Of course if you do that, your configuration will get bloated, but that doesn’t mean that Spring is definitely bad, perhaps you need to rethink your design and modularization. Perhaps it would be wiser to have a nice separation of concerns between your application parts/modules, each module having a clearly defined interface, and then try to link only those interfaces with spring. That would probably bring more value out of the DI that spring has to offer and also keep your configuration clearer and easier to maintain.

could you guys decide on one good framework.. damn java development..

good old legacy days..

Number 6:

#6- Is a copy of others wel-know frameworks … like JSF

Tapestry 5 is the answer to Spring these days :-d

like everything Spring started a good idea and now is bloated.

the best approach to building large scalable j2ee apps is I believe

struts for the presenation layer

Stateless Session Beans – to manage business services, transaction mgmt and as an entry point for web layer

hibernate – persistant layer

appropitate patterns to seperate these three layers.

Extracted from http://www.springframework.org/about

“J2EE should be easier to use” why? distributed processing and large scaled systems are not easy to develop, are they? Unless you want use JEE’s advanced features to develop even a helloworld web app. Which is a common practice among Spring developers. Hehehe…

“It is best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero” why it is best? what cost? yeah… Eclipse can “extract interfaces” if you want…. in compile-time!

“JavaBeans offer a great way of configuring applications” agreed! Great for anything involving pure data, indeed.

“OO design is more important than any implementation technology, such as J2EE” as pholosophy is to building houses. At some point, you have to deliver your software, so forget your idea of modeling the universe in your application… yeah, sorry guys, that’s impossible.

“Checked exceptions are overused in Java. A framework shouldn’t force you to catch exceptions you’re unlikely to be able to recover from” what??!!!! What’s next?”So frameworks should know how to divide by zero”. I think you will want to know what happened. This is worst than catching to e.printStackTrace(). Please, keep throwing and catching! Remember that try-cath-finally sentences are as important as if and for sentences for program semantics!!

“Testability is essential, and a framework such as Spring should help make your code easier to test” yeah, it is essential. Any framework should!

Bye! Keep keeping it simple, guys!

for me, i use spring with minimum config xml… i use spring context xml + spring Tx interceptor + CGLib enhancer + Service locator pattern…

in this way instead of having to list 1000 DAO + 200 Service beans + 300 bizz objects all in xml ( what a hell it will be), only Tx mgr + myDataSource + superDao is required to list in the xml…. all my 1000 DAOs are subclassed from this superDao.

thanks to great CGLib / AOP…….

I wish the day Sun can make the java.lang.Object having the similar method of CGLib enhancer….

Java programming can be fun! I don’t like frameworks, spring or hibernate. They just seem to slow things down – many things. Performance, the application to be delivered to customer and myself.

All of you spring fans, have fun with spring! (Seriously! If it’s your way, it is…)

All of you java programmers, who don’t like spring/hibernate: they are not for speeding things up. While people is investing in learning frameworks (actually learning to deal with framework-specific Exceptions), I’ve already written the thing required for the customer. With plain old java objects. And it was fun! Done it my way with my existing self-explanatory java code library. I think it’s more fun to write java, than study the latest framework trend.

All the best,

Johnny

Yep. Oracle bought out Sun. Sun has been looking for a buyer for quite some time after the .com bust. apparently their j2ee technologies really suck. They have gotten to the point of being so cheap (since their whole array of technology sucks hardware etc). Good luck to all Java/J2ee/framework delusioned evangalists.

I agree, Spring is too complicated.

For people who favour XML configs & complexity – Go figure out other world of programming.

No RAD with spring, too complex for simple applications & too becomes too complicated for big applications. The result – spend more money maintaining it & get worse.

A framework should make life easy & faster development time. If you have complex items, you can use plugins to overcome.

Look at springframework.org, you guys will love it. I use Spring + Hibernate for medium sized apps – its fairly straight forward & very easy to work with. We develop modules like piece o cake.