Guice 2 Private Constructor Change

[nimbus]

Hi,

The change in Guice 2 that was made in order to prevent Guice 2 from
instantiating objects with private constructors is causing us some
issues (i.e. the change described at http://code.google.com/p/google-guice/issues/detail?id=72
).
Essentially, it is preventing us from using Guice 2 as a "drop in"
replacement for Guice 1 in our product. Suspect this may also be the
case with some other codebases out there too.

In order to ensure maximum backwards compatibility with code developed
using Guice 1, would it be possible to have a means of switching off
this check ? i.e. So that the new behaviour would be the default in
Guice 2, but could be disabled for maximum compatibility with code
bases developed against Guice 1.

Some more background to this request:
I came across the new check when testing the codebase for the product
I'm working on against guice-snapshot20081123. There are several
public classes with private constructors in the codebase that are
instantiated using Guice. So, this new check means that Guice 2 is not
a "drop-in" replacement for Guice 1 in the codebase - i.e. to use
Guice 2, the codebase would have to be changed so that the
constructors are annotated with @Inject.

While this change to the product codebase could be made, there is
another issue for us. Guice is also used as part of an extension
mechanism for the product, so that customers can extend and customize
it to meet their own requirements. So, some customers also have public
classes with private constructors that are instantiated via Guice 1.
We would like to move the product on to Guice 2 in a forthcoming
release in order to take advantage of some of the great new Guice 2
features. However, it will greatly complicate the product upgrade
process if we have to ask our customers to make changes to their
codebase (i.e. add the @Inject annotation to private constructors) in
order to take the upgrade.

Note that I've also added a note on this to the issue itself (i.e. at
http://code.google.com/p/google-guice/issues/detail?id=72).

Thanks,

Eoin.

[Dhanji R. Prasanna]

An optional off switch is undesirable. We should either remove this change and be fully compatible with Guice 1 or break backwards compatibility and document clearly.

Dhanji.

[nimbus]

Hi Dhanji,

Understand that adding the option may not be the most desirable course
of action at this stage. Also, saw the recent message from Jesse (in
the thread on the Guice 2 release schedule) that the API should now be
considered as frozen,.

Obviously, my preference would be to remove the change in order to
preserve contract compatibility with Guice 1. Also note that the
request was originally closed with status "WontFix" for this reason,
and was only later re-opened and implemented.

So, is there any possibility of removing the change now ?

thanks and regards,

Eoin.

On Jan 26, 9:57 pm, "Dhanji R. Prasanna" <dha...@gmail.com> wrote:
> An optional off switch is undesirable. We should either remove this change
> and be fully compatible with Guice 1 or break backwards compatibility and
> document clearly.
> Dhanji.
>

[limpb...@gmail.com]

On Jan 27, 9:00 am, nimbus <nimbus4...@gmail.com> wrote:
> Understand that adding the option may not be the most desirable course
> of action at this stage. Also, saw the recent message from Jesse (in
> the thread on the Guice 2 release schedule) that the API should now be
> considered as frozen,.
>
> Obviously,  my preference would be to remove the change in order to
> preserve contract compatibility with Guice 1. Also note that the
> request was originally closed with status "WontFix" for this reason,
> and was only later re-opened and implemented.
>
> So, is there any possibility of removing the change now ?

If we were to permit this, it would probably take the form of a Java
system property, like we did to allow 'null' before we had the
@Nullable annotation.

That approach is quite clumsy because it means we have to test
everything twice, once with the flag and once without it. Sometimes
you forget to set the property, or don't set it soon enough in the
execution of the program, and things don't work the way they should.

So I prefer to avoid system properties when I can. It seems like using
a patched .jar would probably be easier. You eliminate the runtime
configuration hassle of setting the property, and it's much more
obvious from the classpath that you're not using the standard Guice
behaviour.

If you'd like, I provide the patch and instructions for using it to
build a .jar.

[nimbus]

Hi Jesse,

Thanks for the update. Didn't realise that there was a precedent for
using a Java system property to configure the behaviour of Guice.
If it's not possible to include this in the public GA release, would
very much like to take up your kind offer of a patch providing the
ability to disable this check via a System property (or similar).
We can then use this as an interim solution until all of our customers
have been able to change their code to add the @Inject annotation to
private constructors.

Incidentally, worth noting that this issue has come up in the Spring
community too, as Spring does support construction of objects with
private constructors - see, for example
http://forum.springframework.org/showpost.php?p=92418&postcount=7 .

Many thanks,

Eoin.