Guice could become, as important, as JSF.
Actually no one was really interested in JSF ...until it became a part of Java EE 5. The same can happen with Guice, the lean, opensource Inversion Of Control framework.
Java EE 6 will be probably extended with WebBeans (JSR-299) - which should simplify not only web, but also desktop applications. WebBeans JSR was initially intended to connect directly JSFs with EJB3 and reduce the boilerplate code, but meanwhile it's lot more. Guice is doing the work here behind the scenes - so it will become indirectly a part of Java EE 6 - it can be even used with Struts 2. Guice is not only important, from the strategic point of view, but it's also very interesting from the developer perspective.
I became curious seeing the "fluent" configuration:
binder.bind(Service.class).to(ServiceImpl.class).in(Scopes.SINGLETON)
and noticed, that it is easy to maintain ...and typesafe. After using it for a while, I find out it is also DRY (no repetition of the same information across classes and XML) and provides a notion of Convention Of Configuration - so you can rely on conventions instead of configuring everything. The most important thing - it is really lean, so you can understand how it work in few minutes - in worst case hours :-).
Please check out the whole tutorial (only 22 pages, as lean as the framework...).
Check out also the comparison to spring.
To me Guice has a feel of a me-too vanity effort.
Is it really so different from Spring that the Guice developers couldn't of have joined an existing succesful, high quality project?
They have, of course, the right to do whatever they like, just like we others have the obligation to assess just how much sense it makes, before making our own small investment into the area.
It's just puzzling to me why Sun can continuously screw up with politics, like with their logging system which just made the logging mess worse, or now by thinking that the THIRD time they develop their own date/time solution it's going to work, instead of just adopting Joda-Time as it is, as everyone else is begging them to do.
The best JSR expert groups are those that don't succumb to the need to show their expertise, but instead concentrate on negotiating with parties who have developed technology which is used by everyone, and adopting it directly into their JSR.
Posted by Mikael Gueck on June 13, 2007 at 03:10 PM CEST #
To me Guice is a DI container of the new generation which leverages the features of the language, provides type-safety and reduces! itself to one main point: dependency injection. It is refreshing that a framework can concentrate and solving only one task and not trying to be a one size fits all approach.
So Guice could be used in nearly every scenario in contrast to Spring which represents IMHO a very intrusive programming model and therefore restricts itself.
If someone is interested, I have translated the User Guide of Guice as part of my work into german and published it here:
http://docs.google.com/Doc?id=dc6m4mdd_0c6vgxx
Posted by 212.190.217.253 on June 13, 2007 at 04:40 PM CEST #
Mikael,
1. Stephen Colebourne (the creator of Joda-Time) is the Spec-Lead of JSR-310 (Date And Time). So it already happens, what your are suggesting here. Btw. If you have interests, just come and help us.
2. I personally like Guice, because it's very lightweight - and there is no XML :-).
3. Actually: Why you are writing about Sun and Date here? It has nothing to do with Guice :-).
thanks for your comment,
adam
Posted by Adam Bien on June 13, 2007 at 06:53 PM CEST #
Adam, I was up late yesterday reading the <a href="http://wiki.java.net/bin/view/Projects/DateTimeAPI">JSR-310 wiki</a>, and formed the impression that Stephen's involvement with the JSR is a great thing but there is a great risk that the same thing that happened with Hibernate and JPA will happen with Joda-Time and JSR-310.
Your blog post described how Guice could become the basis for a JSR for IoC. My point was that if there is to be a JSR for IoC, the objective for it should be to succeed in producing a good standard solution the first time around, and that it's hard for me to understand how this could happen with a project such as Guice that hasn't seen much real-world use, compared to an existing project which has had years and years of massive real-world use, such as Spring.
I hope that this time I expressed myself more clearly.
Posted by Mikael Gueck on June 13, 2007 at 07:19 PM CEST #
Mikael, you should try Guice first (or at least read the user's guide), and then pass judgement.
Posted by Bob Lee on June 13, 2007 at 09:02 PM CEST #
Bob, the last time I read through the available Guice materials, I missed the point where they described how they discovered the silver bullet of how to jump over the part of the process which everyone else everywhere has had to go through - refining a good idea into a product through a prolonged period of real-world exposure.
From the documentation, I took away the opinion that Guice is a wonderful idea which has the potential to some day become a great product.
However, and this is important, the thing I want from the JSR process is that they search far and wide for something much more rare than a good idea - a tangible implementation that has been proven to be succesful in real world scenarios, and which has been adopted by a large part of the Java developer base.
Posted by Mikael Gueck on June 13, 2007 at 09:15 PM CEST #
Mikael, Guice has had plenty of real world usage. Guice powers one of the biggest and most important applications at Google and it has done so for over a year. Guice has the benefit of my experience as well as that of everyone else who has touched it.
What I want from a JSR is an API we can all live with for the next 10+ years. I'm sorry, but Spring doesn't have that, nor does it even come close.
Posted by Bob Lee on June 14, 2007 at 01:21 AM CEST #
Well, I imagine we have different needs for basic survival, but we have been living happily with the Spring API since we met it, 3 years ago: I can't imagine any major problems that could make my life worse, in the next 7.
It can maybe be improved, but saying that it does not "even come close" to something that can last for 10 years is frankly too disrespectful for such a great piece of work, IMO.
Posted by Davide Baroncelli on June 15, 2007 at 05:10 PM CEST #
I would agree that ultimate Guice will be more important than Spring. Not only is it, in my opinion, a better model than Spring, but the Guice guys are taking an active role in the development of future Java standards. As great as I think our Seam ideas are for WebBeans, there's no denying that the spec will be significantly better for their contributions.
Posted by Norman Richards on June 16, 2007 at 01:21 AM CEST #
You can use JSF with Guice also, see:http://cagataycivici.wordpress.com/2009/02/11/lightweight-jsf-with-guice/
Posted by Cagatay Civici on February 12, 2009 at 02:35 PM CET #
I don't get this. Guice will not implement JSR-299 instead it is working with the Spring folks on JSR 330. So how will Guice become a part of Java EE 6 if JSR 299 becomes a part of Java EE 6? Also: With the little backing JSR 299 has - why should it even become part of Java EE 6?
Posted by Eberhard Wolff on June 29, 2009 at 11:04 PM CEST #
@Eberhard,
Guice will (probably) not become a part of Java EE 6. But JSR-299 will probably support the bootstrapping part of JSR-330 - it would be nice at least.
I actually really like Guice AND JSR-299. Had no time to read the JSR-330 - but it will be probably as good as Guice :-).
Posted by Adam Bien on June 29, 2009 at 11:15 PM CEST #