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" <[email protected]> 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. > > On Thu, Jan 22, 2009 at 1:08 AM, nimbus <[email protected]> wrote: > > > 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. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
