Future Guice: More aggressive error detection
For the past month, I've been cataloging the various changes since Bob & Kevin released version 1.0 back in March 2007. For a 1.0, it's held up remarkably well. We've been using it on my team without many problems and we've quite enjoyed it.Good News!
Guice has improved since 1.0. There's new features, bugfixes, performance improvements and tools for Guice users to enjoy.
Bad News
The latest snapshosts of Guice are not 100% backwards-compatible with version 1.0. For example, Guice had a bug where it quietly ignored some bindings that it couldn't fulfill. This test case gives a false-positive result: it succeeds even though there's no binding for interface
A: public void testBindProvidersOrder() {
Injector injector = Guice.createInjector(new AbstractModule() {
protected void configure() {
bind(String.class).toProvider(new Provider<String>() {
@Inject A a;
public String get() {
return "hello world";
}
});
}
});
assertEquals("hello world", injector.getInstance(String.class));
}Today's Guice is better - when this test runs it prints an error at Injector-creation time:
com.google.inject.CreationException: Guice configuration errors:
1) Error at com.google.inject.BinderOrderTest$1$1.a(BinderOrderTest.java:31):
Binding to com.google.inject.BinderOrderTest$A not found. No bindings to that type were found.
1 error[s]
at com.google.inject.InjectorBuilder$ConfigurationErrorHandler.blowUpIfErrorsExist(InjectorBuilder.java:281)
at com.google.inject.InjectorBuilder.validate(InjectorBuilder.java:181)
at com.google.inject.Guice.createInjector(Guice.java:59)
at com.google.inject.BinderOrderTest.testBindProvidersOrder(BinderOrderTest.java:26)This particular problem is easy to recognize and fix. It's a net win, even though it breaks backwards-compatibility. There's more similar changes, and I intend to post about them in the coming weeks...
