Skip to content

Guice600

Jump to bottom
Googler edited this page May 13, 2023 · 3 revisions

Guice 6.0.0

Released May 12th, 2023.

Maven

Guice:

<dependency>
  <groupId>com.google.inject</groupId>
  <artifactId>guice</artifactId>
  <version>6.0.0</version>
</dependency>

Extensions:

<dependency>
  <groupId>com.google.inject.extensions</groupId>
  <artifactId>guice-${extension}</artifactId>
  <version>6.0.0</version>
</dependency>

Downloads

Docs

Changes since Guice 5.1.0

JEE Jakarta Transition

Guice 6.0 adds support for jakarta.inject, the new namespace for the JSR330 spec (after the javax -> jakarta JEE transition). The following links talk more about the jakarta transition: Jarkata EE blog post, Eclipse Foundation blog post, Jakarta EE Wikipedia article, Oracle blog post

Guice 6.0 is being released alongside Guice 7.0 and is intended to help users migrate their code to the jakarta namespace. Guice 6.0 continues to fully support the javax.inject namespace while also mostly supporting the jakarta.inject namespace. The only part of Guice 6.0 that doesn't support jakarta.inject are the bind(..).toProvider methods. Those methods still require javax.inject or com.google.inject Providers.

The Guice 6.0 servlet & persist extensions only support the javax.servlet and javax.persistence namespaces respectively. If compatibility with jakarta.servlet or jakarta.persistence is required, use Guice 7.0.

Guice 7.0 removes support for javax.inject, javax.servlet and javax.persistence. Other than the namespace changes, Guice 6.0 & Guice 7.0 are identical.

Guice 6.0 can help with incremental migrations to the jakarta.inject namespace, by incrementally replacing javax.inject references to jakarta.inject. This works everywhere, except for code where a jakarta Provider is passed to bind(..).toProvider. Any one of the following options can be used to workaround the toProvider issue.

  1. Update to Guice 7.0 instead. Guice 7.0 fully supports jakarta.inject (but does not have support for javax.inject anymore).
  2. Change the provider implementation to instead implement com.google.inject.Provider (which works in both 6.0 & 7.0).
  3. Change the provider implementations to instead be @Provides methods, or add a wrapper @Provides method that delegates to the actual provider.
  4. Call bind(..).toProvider(Providers.guicify(myJakartaProvider)). The guicify method will adapt a jakarta provider instance to a com.google.inject.Provider. This only works if binding a Provider instance. It will not work for binding provider classes, type literals, or keys. If using this approach, it's best to revert the guicify calls when later updating to Guice 7.0, because they otherwise mask the actual provider implementation (which can be accessed through the Guice SPI's ProviderInstanceBinding.getUserSuppliedProvider).

Note that even though Guice 6.0's toProvider methods don't support jakarta providers, Guice 6.0 can inject jakarta.inject.Provider.

Details

See https://github.com/google/guice/compare/5.1.0...6.0.0 for a complete list of changes.

Guice Core
  • Adds jakarta.inject support. (#1630, #1679, #1490, #1383, with significant advice & help from many people)
  • Support Java 21 (via updating ASM to 9.5 and other changes). (#1671, #1657, #1654)
  • Improve AOP support on JVMs such as Azul. (#1672, with significant help from @mcculls and @alsemenov)
  • Fix a deadlock or crash associated with recursively loading just-in-time bindings. (#1633, #785, #1389, #1394, with significant help from @swankjesse and @PaulFridrick)
  • Make PrivateModule.binder() non-private, to allow subclass customization, such as calling skipSources. (#1569, #1525, by @visi)
  • Fix an endloop loop (that can OOM) in singleton lock cycle detection. (#1635, #1510, with significant help from @trancexpress and @gvisco)
  • Fix tests to pass on Windows, despite the different line separator. (#1213)
  • Improvements to OSGi metadata. (#1173, #1050, #1049, #1708 by @mcculls, @kenwenzel, and @HannesWell)
  • Mark the JSR305 dependency as optional (since it's not required at runtime). (#1172, by @mcculls)
  • Fix Binder.requestInjection(TypeLiteral<T>, T) to use the TypeLiteral. (#1071, by @jedediah)
  • Honor scoping annotations on concrete types when provisioned by their @ProvidedBy annotation (#251, #1319)
  • Add a way to tell if a class is "enhanced" by Guice, and retrieve the original class. (#1340, #187)
  • Ensure the order of bind(...) statements does not matter when referring to JIT bindings. (#700, #1650, with significant help from @nineninesevenfour)
  • Implement Matcher.and and Matcher.or as default methods directly in Matcher, so that the AbstractMatcher subclass isn't required. (#1716, #1177, by @kashike)
  • Mark the error_prone_annotations dependency as optional. (#1739, by @HannesWell)
Servlet
Persist

Persist had a number of changes, some of which are backwards incompatible. Notably: injection of EntityManager no longer implicitly starts a unit of work (because this led to leaks). Users can opt-in to the legacy behavior by constructing the JpaPersistModule with a JpaPersistOptions that sets setAutoBeginWorkOnEntityManagerCreation to true.

Clone this wiki locally