should a single argument taking constructor be allowed as an injection point without requiring @Inject?

[GoogleCodeExporter]

There's a ton of legacy Java code out there where folks have written a single 
argument taking constructor.

For refactoring reasons (as folks might add new constructors with arguments 
later on), its advisable for new code to use @Inject to pick the one 
constructor the IoC framework should use. 

Should the @Inject spec make it mandatory for classes with a single argument 
taking constructor (and maybe a zero argument constructor) to 
not be injected by default?

For purely tactical reasons (to avoid end users having to write more provider 
methods than are really required or forcing folks to hack the 
source/bytecode to add @Inject in), I'm tempted to allow objects with no 
@Inject annotation which have a single argument taking constructor 
which will be used by the IoC container. If there are 2 argument taking 
constructors then it would fail. If folks add another constructor with 
arguments to a class already having a non-zero argument constructor then it 
breaks the IoC - unless folks add an explicit @Inject.

I know this has always gone against the grain with Guice folks :) What do 
others on the EG think?

Note I'm not in favour of clever rules to 'pick the right one' if there are 
multiple argument taking constructors. I'm just in favour of folks being 
able to write a Java class with exactly one argument taking constructor and for 
that to be enough for the class to be instantiated by JSR330; 
while at the same time we know it makes sense to add the @Inject going forwards.

Original issue reported on code.google.com by james.st...@gmail.com on 28 Jul 2009 at 9:42

[GoogleCodeExporter]

I guess this is a duplicate of 
http://code.google.com/p/atinject/issues/detail?id=4, 
but I really like your suggestion of the single constructor-taking used 
automatically and without @Inject as the injection point.

Original comment by thiag...@gmail.com on 28 Jul 2009 at 3:55

[GoogleCodeExporter]

Sorry, I got a typo: it should read "single argument-taking constructor".

Original comment by thiag...@gmail.com on 28 Jul 2009 at 3:56

[GoogleCodeExporter]

You already noted that Guice wouldn't support this, but I should probably give 
some reasons:

1) I think we have too many rules already. This adds yet another exception that 
users must learn. Its value 
doesn't outweigh its costs. On the balance, I think it does more harm than good.

2) You said yourself that this feature supports legacy code. Our spec is 
forever. We haven't let legacy concerns 
hamper it so far, and this doesn't seem like a good reason to start.

3) I don't want this feature to unduly influence users' design decisions. For 
example, "if I can somehow avoid 
adding a second dependency to this class, I can avoid explicitly using 
@Inject." I can imagine users creating 
context objects that compose several dependencies, one of the patterns DI aims 
to replace.

Other injectors can support this feature, but Guice will not, so it shouldn't 
be required by the standard.

Original comment by crazybob...@gmail.com on 28 Jul 2009 at 4:09

• Changed state: WontFix
• Added labels: Type-Enhancement
• Removed labels: Type-Defect