The Future of Guice - BOF-6400

DISCLAIMER:
These are the tidied up notes I took from the session at the JavaOne 2008 conference in San Francisco, California. There may well be mistakes and ommissions. I will come back and correct them once the conference has completed. However my first priority is to get the information published before the backlog gets too large and swamps me. All comments welcome. Enjoy!

"Crazy" Bob Lee, Kevin Bourrillion andJesse Wilson (of Glazed Lists fame)

Guice 1.0
- it was v. popular
- it recently won a jolt award
- there are two books already available

Philosophy
- back to basics
- @inject is the new "new" - it has the brevity of "new" but the flexibility of a factory
- Fail early but not too early (validate all your dependencies at startup.)
- Make it easy to do the right thing
- Types are the natural currency of Java - do everything with types (early versions were String based) which means that your existing IDE (without plugins) still work
- Prefer annotations to convention - i.e. it's not just a naming convention
- Singletons aren't bad, but the typical implementations are
- Focus on readability over writeability
- Maximise the power-to-weight ratio - the Guice API is very small. If you'll never use it, the API does not expose it. Thus it is simple to maintain compatibility between versions
- Balance - just because you can doesn't mean you should

Goals for 2.0
- Releive pain points - implementing custom factories (maintainability)
- Compatability with 1.0 -but we may break where you want us to, e.g. they forgot about inner nested classes
- Extensibility - 1.0 made it easy to build a "Guicy" app. Now it's easier to extend it
- Tool support - There was an Eclipse plugin developed last year by a Google intern. They will provide all the hooks a tool needs to have
- Shooting for a summer 2008 release

Guice 2.0 Core
- Mirror API - SPI for Guice. If you want deep integrations with Guice to extend it or to hook it into a third party tool. Deep access to what's going on in Guice
- Tool stage - a mechanism to create injectors for tools to use. Possible since Guice uses Java code to specify its injection but in a shallow way - it won't start your singletons etc.
- Binder.getProvider()- if your module needs a binding to another module. This is an API so your module can get at other dependencies in other modules
- Class/Constructor Listeners - if you build an arbitrarily complex system (EJB 3.0) you can use Guice as a hosting environment. You will be able to do all the cool APOO reflection without all the weight. Powerful way to write aspect code. Its not APO, but it allows you to get a handle on a newly created object befiore its returned from construction
- Multibindings - lets you bind the same type n times which allows Guice to do another job in your system
- Constant Type Converters - you can already take a file of properties; but unless your properties are booleans or integers etc. you inject Strings. now you can register a converter for e.g. HTML converters and inject actual colour objects from a properties file.
- @Nullable - Now you can inject null
- Enhanced Error Reporting - it was really really good. It's now even better
- Specified exception reporting - whatever you throw from provider.get() method is a ProviderException.
- Module Overrides - Someone else gives you a module which has a dependency which you don't want. Whenever it binds to this type, you can swap out the pieces you don't want

Provider Methods
- These are all tidied up now. Now they're all beautiful and terse

Hierarchical Injectors
- A building block for power features
- Private bindings
- capability based security a la
- Just think robot legs
- Struts 2 plugin
- Business Logic vs. View Layer - one injector for each, ensuring the injectors for one area don't pollute the namespace for the other

Beyond 2.0
- Compile-time Guice - if you hate reflection (i.e. Mobile and embedded ot GWT) then you can take a Guice module and compile it to code which you can use
- Third party extensions
- Warp
- Guiceberry - Useing Guice to inject unit, functional, and integration tests
- Peaberry OSGi
- Platform support