Guice is still very immature at the moment. I've been trying to stay under the radar until I get the API right, etc. What's the timeline for your article? I can try to give you an idea of what parts of the API will be mostly squared away by then.
Right now, the Java API is the preferred method for configuration. I just checked in a big change which makes it more palatable. For example, instead of calling overloaded factory() methods, now you can say something like this:
containerbuilder.bind(Foo.class).named("myFoo").to(FooImpl.class).in(SESSION);
Translation: if someone needs a Foo named "myFoo", inject an instance of FooImpl from the session.
Binding a constant looks like this:
containerBuilder.bind("thread.pool.size").to(5);
Guice also supports full blown generic types now. For example, you can bind List<String> and List<Integer> separately. Supporting this feature will make it difficult to use anything but a Java API because I don't really want to implement an API which will enable me to create a generic type from a String just yet,
i.e. the generic equivalent of Class.forName(). For example:
Type t = Types.forName("List<String>");
It's easier to just let the Java compiler handle this stuff at the moment, and I suspect we'll be getting some better support for this sort of thing in Java 7.
Next up on my agenda is reworking the scope handling. I'm going to make it so you can easily define custom scopes (i.e. business process scope, transaction scope, etc.).
I'm trying to finish all the API-related tasks up front so people can code against it without me constantly breaking them. Then I'll follow up and improve error reporting, performance, etc.
In the mean time, you can follow what I'm doing using FishEye:
http://fisheye3.cenqua.com/browse/google-guiceThanks for being an alpha tester, ;)
Bob