Hey Bob - I definitely imagined lifecycle features on Guice as being an opt-in. In fact, I'd like to see a lot more of Guice decoupled so features that can be expensive are opt-in, or behavioural defaults can be opt-in. But certainly, lifecycle needs to be built with support/integration from Guice, but it could be layered on top, with hooks exposed. Regardless, yes - the performance impacts need to be evaluated in any solution. And real use-cases are definitely what we want to work from.
Christian. On Mar 14, 2012, at 1:08 AM, [email protected] wrote: > > Comment #73 on issue 62 by [email protected]: Lifecycle support > http://code.google.com/p/google-guice/issues/detail?id=62 > > This issue is still open? :-) > > I'd recommend against adding a sophisticated service lifecycle management > framework to Guice. This could be a framework in and of itself. Of course, > such a framework could integrate with Guice. > > 5 years ago, I didn't want Guice to depend on @PostConstruct and @PreDestroy > because this would have created a dependency from Guice on Java EE. This > would have been unacceptable because core Guice needs to run on platforms > like Android. > > Today, these annotations are part of core Java (since Java 6). Functionality > that depends on these annotations could fail fast when the annotations aren't > present (Java 5, Android, etc.). For example, Injector.shutDown() would throw > a runtime exception. > > Simple support for @PostConstruct and @PreDestory might make since. > > It wouldn't make sense to support @PostConstruct alone. It exists because > @Resource supports only fields and methods. Guice supports constructors and > does not need something like @PostConstruct. However, if we support > @PreDestroy, we should almost certainly support @PostConstruct, too, to avoid > confusion. > > Do we need @PreDestroy support? If so, how exactly should it behave? What > level of flexibility do we need with regard to concurrency (asynchronous, > parallel), exception handling, invocation ordering, etc.? Does it apply to > only objects instantiated by Guice or all objects? What's the compatibility > story? > > To answer these questions, *we need concrete, real world use cases (examples) > for @PreDestroy*. We need lots of examples, and in each case, @PreDestroy > should be the best way of addressing that use case. > > Finally, when it comes to the implementation, we need to take care not to > introduce performance regressions, even if that means making this an "opt-in" > feature. Performance is already bad enough on Android. > > > > > -- > You received this message because you are subscribed to the Google Groups > "google-guice-dev" 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-dev?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-guice-dev" 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-dev?hl=en.
