Weiqi Gao's Observations - spring tag

Dependency Injection Annotations To Come To A JVM Near You.

Tue, 05 May 2009 18:23:22 GMT

(Via Twitter, where else?)

Remember this (my blog reaction to Google Guice 1.0)? At the time I wondered:

Me:
Guice, Or Something Like It, Should Be In The JDK

About the only thing that makes feel a little bit uncomfortable is the use of Guice specific imports in my application code.

Wouldn't it be nice if I don't have to do a
import com.google.inject.*;
but do a
import java.lang.inject.*;
instead?

It's been 779 days since then, but Bob Lee and Rod Johnson have just made public a (work-in-progress) JSR JSR ?: Annotations for Dependency Injection "to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks."

Bob Lee: Five years ago, Spring 1.0 brought Java dependency injection into the mainstream. Three years later, Google Guice 1.0 introduced annotation-based dependency injection and made Java programming a little easier. Since then, developers have had to choose between a) writing external configuration or b) importing vendor-specific annotations.

Today, we hope to give developers the best of both worlds. Google Guice and SpringSource have partnered to standardize a proven, non-controversial set of annotations that make injectable classes portable across frameworks. At the moment, the set of specified annotations consists of:

@Inject - Identifies injectable constructors, methods, and fields

@Qualifier - Identifies qualifier annotations

@Scope - Identifies scope annotations

@Named - String-based qualifier

@Singleton - Identifies a type that the injector only instantiates once

One additional interface is specified for use in conjunction with these annotations:

Provider<T> - Provides instances of a type T. For any type T that can be injected, you can also inject Provider<T>.

Hey Rod, You Are Killing Your Company

Tue, 23 Sep 2008 15:02:57 GMT

(Via The Fishbowl)

Unnamed PR firm for SpringSource: After a new major version of Spring is released, community maintenance updates will be issued for three months to address initial stability issues. Subsequent maintenance releases will be available to SpringSource Enterprise customers. Bug fixes will be folded into the open source development trunk and will be made available in the next major community release of the software.

A lot of people have voiced their opinions about this policy, and an open revolt, a.k.a. a fork, is called for from open source advocates.

Rod Johnson and company is too smart to have not anticipated such reactions. The fact that they went ahead with the plan anyway indicates to me that they are pursuing some other goals. And the way words like "enterprise", "subscription" and "customers" are used indicates that it is money they are after.

I don't fault them for wanting to make money. It is wonderful to have paying customers for your software product, especially an open source one.

However, the policy of differentiating paying customers and community users by the releases that they may or may not receive simply goes against the grain of open source thinking. The community is rightfully "outraged." But we already know that they don't care.

The key here is the response from the paying customers. And I do think that they have some legitimate questions to ask:

The extra patched releases that I receive after three months (but within three years), are they still open source? Can I redistribute it, with source, to the world?
If what I receive is not open source anymore, have I been "bait-and-switched" into thinking that I'm going with open source when I selected Spring?
SpringSource has taken the first steps of abandoning the open source community. Will the product lose its luster?
Am I locked in? Will the subscription price go higher each year?

Once again, SpringSource is too smart to have not thought about these, and the effects on their open-source-oriented customers (that they will be gone).

That leaves only their paying customers who don't care about the open source thing that much.

Even for them, there are still some key questions:

I know we don't care about open source. But SpringSource ought to care, they are, after all, an open source company. Why are they alienating their own community?
They must be desperate for money. How long can they last?
What if my biggest competitor bought SpringSource?

I'm sure Rod Johnson and company has good answers to all of the above questions.

You Become What You Disrupt

Wed, 30 Apr 2008 13:16:00 GMT

SpringSource Launches New Application Server without Java EE.

It looks like the Spring guys want to get into the proprietary Java App Server business, exactly what they tried so hard to discredit a mere four years ago.