Guice 3.0 Release?

[Sam Berlin]

All,

The Guice SVN trunk is significantly improved since the Guice 2.0 release.  It incorporates support for JSR 330, it solves various OSGi issues, it has a ton of bug fixes, and the extensions (AssistedInjection, Multibinder, Servlet, etc..) are all improved.  I propose that we release the next version of Guice as 3.0, primarily because of the JSR 330 support.  "2.1" wouldn't quite capture that monumental achievement.  (I actually kind of want to name it Guice 3.30, to highlight JSR 330 support, ha!)

I'll be glad to do what's needed to get Guice ready for a release (add proper @since tags, cleanup javadocs, wiki, etc..).

Please take some time to look through the changes below.  I believe that Guice SVN is ready as-is for a 3.0 release, but if you are all able to glance at any open issues and point out major ones that can be solved, it would be appreciated.  It would be amazing if we were able to do this by JavaOne.

There's been approximately 200 commits to SVN since 2.0, so listing all bugfixes isn't possible, but below is a list of large/logical changes (in order of reading the SVN commit history)...

 - Added support for toConstructor bindings.

 - Consider toInstance bindings 'eager singletons' for scoping SPI purposes.

 - Many, many servlet extension fixes.

 - Added Multimap support to the multibinder extension.

 - Added ability to multibinder to permit duplicates.

 - Added a scope checker utility.

 - Updated AssistedInject to use FactoryModuleBuilder, actually faster performance-wise than way old implementation.

 - Added JSR 330 support.

 - Properly handle overridden @Inject methods (both with & without subclass annotating @Inject).

 - Fix circularly dependent singletons so that two singletons aren't created sometimes.

 - Add with(instance) API for servlet bindings.

 - Add ability to make @Inject methods as @Toolable, so they are called during Stage.TOOL (for extensions).

 - Add InjectorBuilder, and ability to forcibly disable JIT bindings and circular proxies.

 - Update Multibinder so dependencies can be retrieved in Stage.TOOL.

 - Allow duplicate bindings to be silently ignored (instead of blowing up).

 - Fix combination of Multibinder & Modules.override().

 - Proper OSGi support.

 - Fixed Provider methods that request a Logger so named loggers are used instead of anonymous loggers.

 - Fixed to remove residue JIT bindings left in the parent injector when child injectors fail creating JIT bindings sometimes.

 - Fixed multibinder to work properly when based on marker (parameterless) annotations.

Below is a list of API changes for core guice (not extensions) currently in trunk since the 2.0 release, found using the jdiff tool, excluding the 'internal' package:

com.google.inject -

  added: InjectorBuilder class

  deprecated: Guice.createInjector(Stage, Module{})

  deprecated: Guice.createInjector(Stage, Iterable<Module>)

  added: Injector.getAllBindings

  added: Injector.getExistingBinding(Key<T>)

  added: Injector.getScopeBindings()

  added: Key.hasAttributes

  added: Key.ofType(Type)

  added: Key.ofType(TypeLiteral<T>)

  added: Key.ofType(Class<T>)

  added: Key.withoutAttributes()

  modified: Provider [extends javax.inject.Provider]

  added: Scopes.isSingleton(Binding<?>)

com.google.inject.binder -  

  added: LinkedBindingBuilder.toConstructor(Constructor<S>)

  added: LinkedBindingBuilder.toConstructor(Constructor<S>, TypeLiteral<? extends S>)

  modified: LinkedBindingBuilder.toProvider(Key<Provider ? extends T>>) [using javax.inject.Provider now]

  modified: LinkedBindingBuilder.toProvider(TypeLiteral<Provider ? extends T>>) [using javax.inject.Provider now]

  modified: LinkedBindingBuilder.toProvider(Class<Provider ? extends T>>) [using javax.inject.Provider now]

com.google.inject.tools

  added: Toolable annotation

  changed: DefaultElementVisitor.visit(InjectionRequest<?>) [added <?> to parameter]

  changed: ElementVisitor.visit(InjectionRequest<?>) [added <?> to parameter]

  added: InjectionPoint.forConstructor(Constructor<T>)

  added: InjectionPoint.forConstructor(Constructor<T>, TypeLiteral<? extends T>)

  added: InjectionPoint.getDeclaringType()

  added: InjectionPoint.isToolable()

  changed: InjectionPoint.forStaticMethodsAndFields(TypeLiteral<?>) [added <?> to parameter]

  changed: ProviderKeyBinding.getProviderKey() [return type is now Key<Provider? extends T>>, where Provider is now javax.inject.Provider]

com.google.inject.util

  added: Jsr330 class

  added: ScopeChecker class

Sam

[Bob Lee]

Great summary, Sam! I'll send feedback soon.

Thanks,

Bob

[Dhanji R. Prasanna]

Sam, 

Sounds awesome! I would love to also include the cleaned up guice-persist extension as well as the fixes to Servlet module to properly support multiple servlet pipelines in one app (potentially useful for app containers like Tomcat).

Dhanji.

PS: we should also think about getting a blog post on the google OSS blog.

--
You received this message because you are subscribed to the Google Groups "google-guice-dev" group.
To post to this group, send email to google-g...@googlegroups.com.
To unsubscribe from this group, send email to google-guice-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-guice-dev?hl=en.

[Max Bowsher]

On 29/06/10 01:27, Sam Berlin wrote:
> I believe that
> Guice SVN is ready as-is for a 3.0 release, but if you are all able to
> glance at any open issues and point out major ones that can be solved,
> it would be appreciated.

I made a suggestion on this mailing list some time ago entitled "Move
internal utility code to separate package?" to which the response was
somewhat lukewarm, and included some measure of "not until a major release".

Given that you're now heading into a major release, I'd really like
someone to give me the answer I'm looking for, namely either "Yes, it's
worth you working up a patch for this" or "No, we're not doing it."

Max.

=========== Original email copied below ===========

I've recently been attempting to understand how Guice works. My initial
impression on looking at com.google.inject.internal is "Wow, what a lot
of classes, this is quite daunting!".

On further inspection, it turns out that about a third are general
utility common code. I would like to propose that such classes move to
com.google.inject.internal.util (or similar) to render the package
containing the core internal logic of Guice less crowded.

My initial list of candidates to move is:

AbstractIterator.java
AbstractMapEntry.java
AsynchronousComputationException.java
Classes.java
Collections2.java
ComputationException.java
CustomConcurrentHashMap.java
ExpirationTimer.java
FinalizablePhantomReference.java
FinalizableReference.java
FinalizableReferenceQueue.java
FinalizableSoftReference.java
FinalizableWeakReference.java
Finalizer.java
Function.java
Hashing.java
ImmutableCollection.java
ImmutableEntry.java
ImmutableList.java
ImmutableMap.java
ImmutableSet.java
Iterables.java
Iterators.java
Join.java
LineNumbers.java
Lists.java
MapMaker.java
Maps.java
NullOutputException.java
ObjectArrays.java
Objects.java
Preconditions.java
Sets.java
SourceProvider.java
StackTraceElements.java
Stopwatch.java
Strings.java
ToStringBuilder.java
UnmodifiableIterator.java

The vast majority of these can be moved with nothing more than package
and import statement changes. The exceptions are:

* Classes and Stopwatch would have to change from package-private to
public - I'd classify that as an acceptable compromize for more readable
code, given that all of the others mentioned above are already public
anyway.

* Finalizer and FinalizableReferenceQueue have string literal and
javadoc references to classnames that need fixing up.

You would expect that there would be no dependencies from the utility
package to the rest of Guice. With the above moves, this is nearly the
case: the exception is that StackTraceElements and LineNumbers refer to
some methods in MoreTypes. Proper separation could be attained by
separating MoreTypes into the parts that deal with Guice TypeLiterals
and the parts which deal with pure JDK classes.

Please let me know what you think of this idea, so that I know whether
it's worth me working up an actual patch.

[Sam Berlin]

This sounds like a great idea.  I think it'd be worth doing, with one caveat:  It's only worth it if no more classes become public.  It's already a shame that the internal package needs to expose some things as public in order for other packages to use them, which leaks some internal bits of Guice... a number of projects are already using the internal classes, and I'd hate to expose even more of them.

If it's doable without these things becoming public, I think our best bet is to try and solidify a 3.0 and *then* make the change, similar to how 2.0 got pushed last time and then the internals were refactored.

sam

[Sam Berlin]

How close do you think the guice-persist extension is to a stable release?  (I tried setting it up in my Eclipse instance the other day, but it couldn't compile due to missing some jar files.)  If you're able to write (or can find someone who can write) a failing test for the servlet extension, I can take a stab at fixing it... without a test, though, I'd be flailing around in the dark.

sam

[Max Bowsher]

On 29/06/10 16:10, Sam Berlin wrote:
> This sounds like a great idea. I think it'd be worth doing, with one

> caveat: It's only worth it if *no more classes become public.* It's

> already a shame that the internal package needs to expose some things as
> public in order for other packages to use them, which leaks some
> internal bits of Guice... a number of projects are already using the
> internal classes, and I'd hate to expose even more of them.

Two classes (Classes and Stopwatch) need to become public. I agree this
is suboptimal, but given Java lacks any kind of hierarchical or "friend"
package access, it's inevitable that if you want to have a utility
package, it will have to be public. I consider that having .internal. in
a package name is a stern warning to any developer foolish enough to try
depending on it.

> If it's doable without these things becoming public, I think our best
> bet is to try and solidify a 3.0 and *then* make the change, similar to
> how 2.0 got pushed last time and then the internals were refactored.

Could do, I guess, but I don't really agree that this makes sense. It
makes most sense to do this in a major version number release. *This*
release is already going to be one, but the next one might otherwise
turn out to be 3.1.

Unlike the post-2.0 refactor, the change I'm proposing is very simple,
just renaming things with pretty much zero functional change, so should
be quick to do, and safe.

Having it happen before the release would ease the work of anyone who
wants to backport fixes from trunk onto the current release.

Max.

> <mailto:google-g...@googlegroups.com>.

> To unsubscribe from this group, send email to
> google-guice-d...@googlegroups.com

> <mailto:google-guice-dev%2Bunsu...@googlegroups.com>.

[Dhanji R. Prasanna]

On Wed, Jun 30, 2010 at 1:14 AM, Sam Berlin <sbe...@gmail.com> wrote:

How close do you think the guice-persist extension is to a stable release?  (I tried setting it up in my Eclipse instance the other day, but it couldn't compile due to missing some jar files.)  If you're able to write (or can find someone who can write) a failing test for the servlet extension, I can take a stab at fixing it... without a test, though, I'd be flailing around in the dark.

Not too far. Jesse and I were working thru the kinks the other day, when I was in MTV. The servlet thing is tricky to fix, it's not as simple as a broken test. I'm on top of it though, there is plenty of internal clamor for it to be fixed and plenty of external clamor for guice-persist. So Im pretty keen to do it soon.

However, that said, I guess there's no reason I have to hold back the release for that. But IMO a neat package with all of these features will make the community much happier than simply a version number increase with loads of (albeit awesome) bugfixes =)

Dhanji.

[Pascal-Louis]

Sam,

I would very much like to see just-in-time providers in Guice 3.0
http://groups.google.com/group/google-guice-dev/browse_thread/thread/30f5acafb96744ae

The feature is close to production quality and I can guarantee
bandwidth to complete it.

PL

[Bob Lee]

On Tue, Jun 29, 2010 at 4:56 PM, Pascal-Louis <pascallo...@gmail.com> wrote:

I would very much like to see just-in-time providers in Guice 3.0
http://groups.google.com/group/google-guice-dev/browse_thread/thread/30f5acafb96744ae

Thanks for the effort, Pascal-Louis, but JIT providers are a bit to controversial for 3.0. These are something we've considered since day 1. You can certainly do clever things with them, but they also make code harder to maintain since you can arbitrarily change the behavior of Guice. While this isn't a 100% complete alternative, we prefer developers to use custom injections (see TypeListener) for this purpose.

Thanks,

Bob 

[Sam Berlin]

A small status update on releasing a new version...

Still needs to be done:

 - Bob needs to spend some time reviewing the changes.

 - Wiki needs to be updated to reflect a Guice 3.0 world.

 - @since tags need to be added or modified.

 - Dhanji wants to include the new guice-persist & a servlet fix, but they aren't true blockers for a release (just awesome additions).

 - some recent issues: 507, 508, and 509.

 - audit old issues to make sure there's nothing blocking (I don't think there is). 

Decided:

 - Everyone is OK (so far) with a version number of 3.0.

 - JIT providers / autobinders / etc.. will not be in the 3.0 release.

 - Refactoring the internal package is shelved, in favor of a solution that will hide the package from IDE autocompletions (at which point we can refactor at will in internal).

That sound about right?

sam

[Dhanji R. Prasanna]

SGTM

Fwiw I think we should add a performance section too your list. Each release so far, our pride has come from the fact that we stay ahead of the competition with significant leads in performance. Guice 2 nearly rolled back a lot of those gains coz we had so many badass features and internal refactorings that we forgot to be diligent about performance. 

Luckily, I was running a random perf bench and showed Bob and Jesse, and Bob made the important call to hold back the release until we had fixed it. Even more luckily for us Jesse did some awesome magic to turn Guice back into a slick speedmachine. =)

My 2c.

Dhanji.

--

[Max Bowsher]

Doesn't _have_ to be done before the release but would be nice:
* get some Maven2 pom.xml files sorted, and ideally into trunk this time.

I'd be happy to work on that and suggest we simply aim to have minimal
POMs suitable for submitting the built jars to the maven repository -
punt on any thoughts of making the POMs good enough to assist in
generating Eclipse or other IDE projects for now.

Oh, and also:
* Can we include a guice-grapher jar in the 3.0 release?

Max.

[Isaac Shum]

My vote

http://code.google.com/p/google-guice/issues/detail?id=366

[Sam Berlin]

I believe there is a pom.xml in guice trunk, but boy is it old... (referencing 1.0-RC2).  As much as I hate dealing with maven, a lot of people do use it.. so a working pom that can be submitted to a repository would be great.  If you're able to clean it up & make it stable, that would help with submitting it.

I know nothing about the grapher extensions, so can't really speak for it... anyone else know the state of it?

Sam

On Wed, Jun 30, 2010 at 6:25 PM, Max Bowsher <ma...@f2s.com> wrote:

[Dhanji R. Prasanna]

That pom is only a distribution pom. I think if we change it we should make it a proper build pom. Greg Kick is the right person to talk to because he handles our (Google's) official maven repo.

Dhanji.

[Max Bowsher]

On 02/07/10 06:23, Dhanji R. Prasanna wrote:
> That pom is only a distribution pom. I think if we change it we should
> make it a proper build pom. Greg Kick is the right person to talk to
> because he handles our (Google's) official maven repo.

I don't think just before a release is the right time to be
contemplating changing the build system from Ant to Maven.

I propose that we should stick with distribution-only poms through 3.0,
and reassess matters after the release.

The first thing we should do is to merge the 2.0-maven branch to trunk
(should be a trivial job for a committer), which just adds the
distribution poms which were actually used for the 2.0 release.

Then, I'd be very happy to write a patch bringing them up to date for 3.0.

> On Fri, Jul 2, 2010 at 1:43 PM, Sam Berlin <sbe...@gmail.com
> <mailto:sbe...@gmail.com>> wrote:
>
> I believe there is a pom.xml in guice trunk, but boy is it old...
> (referencing 1.0-RC2). As much as I hate dealing with maven, a lot
> of people do use it.. so a working pom that can be submitted to a
> repository would be great. If you're able to clean it up & make it
> stable, that would help with submitting it.
>
> I know nothing about the grapher extensions, so can't really speak
> for it... anyone else know the state of it?

It works.

For reasons which were never explained, it was not included in the Guice
2.0 release in jar form.

Max.

[Dhanji R. Prasanna]

I didn't say anything about changing the build system to maven, just make them proper build poms. Our ant build scripts are in need of some attention themselves.

Dhanji.