"Last year, we used Guice in order to implement an Android solution for LeapFactor. It was my first Guice project, so I didn't had experience with the framework. On the other hand, I have had experience on many projects using Spring.

A crucial difference is the default scope: Spring beans by default are singleton, while Guice beans are prototype. I realized this when a server-communcation service (which at that moment contained session state) started losing connection.

My first approach was annotating the communication service as singleton. But when I tried to inject prototype beans inside such singleton, Guice refused to do it..."

Continue reading at... http://blog.oxen.com.ar/2011/05/scope-strategies-spring-and-guice.html

Spring beans, Guice beans? Rally? DI was a hype. Now it's just a joke. Start real programming instead of juggling configuration options to tame your self-produced DI complexity. 

I have felt this way for a while. The frameworks (Spring,Guice) are popular because, the offshore guys,

yes, I said it. Are clueless about robust OO design and development. So. The mashup thing emerges.

 

I have felt this way for a while. The frameworks (Spring,Guice) are popular because, the offshore guys,

yes, I said it. Are clueless about robust OO design and development. So. The mashup thing emerges.

 

Hmm. VMWare/Spring, Google, Oracle/JBoss/Resin (CDI implementors, off the top of my head) - all offshore guys? Clueless about OO design? I  don't think so.

I know so. Yes. Offhore guys. I have worked with some guys from India over the years, that don't

even have the slightest idea of what Polymorphism is. So. Again. I know so.

I know so. Yes. Offhore guys. I have worked with some guys from India over the years, that don't

even have the slightest idea of what Polymorphism is. So. Again. I know so.

I feel a bit of xenophobia here <irony> Good for you! </ irony>?

By the way, India and Argentina are different countries :)

The fact that you know, or worked with, guys from India that weren't proficient OO developers does not mean that all developers from India don't know what polymorphism is, or how to use polymorphism properly.

However, I believe that you did have a bad experience, and that the developers from India weren't very good (I don't know you, so I'm assuming you are not a liar and are not given to exagerrating).  It just doesn't mean that all developers from India don't know what polymorphism is.

You might as well say that all accountants are small nebbish men who tend to be possessed by evil spirits (specifically possessed by Vinz Clortho from Ghostbusters fame), because you saw it happen once back in the '80s.

This is the logical fallacy by way of anecdotal evidence.

http://en.wikipedia.org/wiki/Anecdotal_evidence

Last time I enter this portal.

I've been visiting for so long.

Quality is unbelivable low. Fake posts (adds).

And many unpleasant people.

Good Luck

Last time I enter this portal.

I've been visiting for so long.

Quality is unbelivable low. Fake posts (adds).

And many unpleasant people.

Good Luck

You are being unpleasant saying that my post is too low level for you. If you don't like it, just don't read it. Or better yet, use your time to write something better and share it with the community instead of critizing other people. I do my best to use the little free time I have when working to share little things that seems curious to me, but almost all the comments I get are negative. People like you and Jeff Winston discourage other people from sharing knowledge.

Spring beans, Guice beans? Rally? DI was a hype. Now it's just a joke. Start real programming instead of juggling configuration options to tame your self-produced DI complexity. 

I don't agree. Saying "never use DI" is almost so extremist as saying "always use DI". Sometimes it can be useful, sometimes it could be solved bettr with other approach or pattern. Old-style lookup using JNDI is a better strategy?

The Spring myths have long been overdue for debunking. There is no need to introduce additional levels of complexity (using Spring). Just because you can doesn't mean you should. YAGNI!

The Spring myths have long been overdue for debunking. There is no need to introduce additional levels of complexity (using Spring). Just because you can doesn't mean you should. YAGNI!

I would partially agree with this statement. There are people who like the cool and fancy stuff, and they decide what framework to pull into the project even before even figuring out the requirements.

I also recall http://www.theserverside.com/news/thread.tss?thread_id=38021 (can you believe, 6 years from then we are still talking about Spring).

Now, I would partially disagree with this statement for the very same reason - you can't tell whether you'll need DI or spring without knowing  context of specific project and organization. Spring can make applications way better than some very special and unique designs by allegedly smart in-house architects.

I'm not sure what you mean with "YANG" (english is not my native language), but our project requires running inside an OSGi environment, so we decided using Sprign DM (and migrating to Gemini in a future) in order to make dynamic service handling a little easier (Spring DM handles connection/disconnecting references via proxies, manages timeouts when a service is donw, etc. in a declarative way). I think that this stuff adds value.

We evaluated Peaberry too (http://code.google.com/p/peaberry/) but Spring DM seems to be more mature and was used as the basis for OSGi Blueprint specification.

Spring beans, Guice beans? Rally? DI was a hype. Now it's just a joke. Start real programming instead of juggling configuration options to tame your self-produced DI complexity. 

 

I don't agree. Saying "never use DI" is almost so extremist as saying "always use DI". Sometimes it can be useful, sometimes it could be solved bettr with other approach or pattern. Old-style lookup using JNDI is a better strategy?

 

Maybe he's saying, don't use Spring, et. al.  DI works fine in plain Java too.

My biggest problem with Spring based DI is that many times it exposes the guts of your application when a configuration switch works just fine.  You don't want users hard coded to implementation details.

Spring beans, Guice beans? Rally? DI was a hype. Now it's just a joke. Start real programming instead of juggling configuration options to tame your self-produced DI complexity. 

 

I don't agree. Saying "never use DI" is almost so extremist as saying "always use DI". Sometimes it can be useful, sometimes it could be solved bettr with other approach or pattern. Old-style lookup using JNDI is a better strategy?

 

Maybe he's saying, don't use Spring, et. al.  DI works fine in plain Java too.

My biggest problem with Spring based DI is that many times it exposes the guts of your application when a configuration switch works just fine.  You don't want users hard coded to implementation details.

I agree with your two points.

Using DI with plain Java with plain Java can be useful too. In fact, we used it years ago in a GWT project (Google GIN wasn't available at that moment). We wrote factories that have the responsibilty of doing the DI.

It is important to keep (where possible) the code decoupled form the container (for example, avoid implementing Spring interfaces), so you can use your classes with Spring, Guice, plain Java DI, etc.

It is correct  that using Spring can expose the internals of your system. In order to mitigate the problems that could arise from such issue, we have used property placeholders or JNDI (depending the project) in order to keep separated things that should be changed by programmers from things that should be changed in runtime (by an administrator).