# Google Guice: a Java DI container for code that avoids new and factories
> Guice is Google's Apache-2.0 dependency injection framework for Java 11 and above. It replaces direct constructor calls with @Inject, and the 6.0.0 and 7.0.0 lines differ only in whether they target javax or jakarta packages.
**google/guice** — Guice (pronounced 'juice') is a lightweight dependency injection framework for Java 11 and above, brought to you by Google.
- Repository: https://github.com/google/guice
- Website: https://github.com/google/guice
- Stars: 12,731 · Forks: 1,676
- Language: Java
- License: Apache-2.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-guice
## The problem Guice removes: new, factories and hard-wired constructors
The README states the goal plainly: Guice "alleviates the need for factories and the use of new in your Java code," and frames @Inject as "the new new." That is the whole pitch. Instead of a service constructing its own collaborators, or a hand-written factory assembling them, the class declares what it needs and a container supplies it.
The audience follows from that. This is for Java 11 and above, and it is aimed at developers who want dependency injection without adopting an application framework. Guice's own README describes the API as deliberately narrow: "Guice is not a kitchen sink. We justify each feature with at least three use cases. When in doubt, we leave it out." That sentence is the most useful thing in the document, because it predicts both what you get and what you will not get.
It is not a new project. The README says Guice has been running in mission critical applications since 2006, which is why the API feels settled and why so much third-party writing about it assumes you already know the vocabulary.
## How Guice wiring actually works: modules, bindings and injectors
Guice's model has three moving parts, and the repository layout reflects them. The core/ directory holds the container, extensions/ holds optional integrations, and examples/guice-demo/ holds a runnable demonstration.
A module is a class that extends AbstractModule and declares bindings: interface to implementation, annotation to value, instance to scope. An injector is built from one or more modules and is the object that resolves the graph. @Inject marks the constructors, fields and methods that the injector is allowed to populate. The README's summary of the benefit is that "your code will not depend directly on" factories, which is what makes it easier to change, unit test and reuse.
Two design choices are worth calling out. First, Guice is type-safe by construction: bindings are expressed in Java types, so a mismatch is a compile-time or startup-time error rather than a string lookup that fails at runtime. Second, the README claims Guice "steers clear of surprises and magic" and that "when errors do occur, Guice goes the extra mile to generate helpful messages." In practice that means errors tend to surface when the injector is created, not on the first request that touches the missing binding. That is a good property for tests and a mildly annoying one for large graphs, because an unrelated broken binding can stop the whole injector from starting.
## Installing Guice with Maven and writing a first injection
The README gives the Maven coordinates for Guice core. The version placeholder is documented as being able to be 6.0.0, 7.0.0, and so on. Add this to your pom.xml:
```xml
com.google.inject
guice
{version}
```
Optional integrations live under a different groupId. The README lists the extension names as assistedinject, dagger-adapter, grapher, jmx, jndi, persist, spring, testlib and throwingproviders, and states that the extension version must match the Guice core version:
```xml
com.google.inject.extensions
guice-{extension-name}
{version}
```
For build systems other than Maven, the README points to Maven Central, which it says publishes snippets for Gradle, Ivy, sbt and others. It does not reproduce those snippets itself, so treat the Maven Central page as the source for them.
Once the dependency resolves, the first real use is a module plus an injector. The repository ships examples/guice-demo/ as a working reference; read that before inventing your own structure. The shape to expect is a class whose constructor is annotated with @Inject, a module that binds an interface to that implementation, and injector creation from the module list. The README's user guide, linked as the Motivation page, is where the annotated examples actually live; the README itself stops at the dependency block.
## The javax and jakarta split is the first thing to get right
Guice 6.0.0 and 7.0.0 were released on the same day, 2023-05-12, and the README is explicit that they are "equivalent except for their javax/jakarta support." 6.0.0 supports javax.{inject,servlet,persistence} and only "mostly supports" jakarta.inject. 7.0.0 supports jakarta.{inject,servlet,persistence}.
This is a genuine migration hazard rather than a marketing distinction. If you pick 7.0.0 while any dependency in your graph still expects javax.inject annotations, the annotations will not be seen by the container, and the failure will look like an unbound dependency rather than a package mismatch. The README links a wiki page, Guice600, whose anchor is literally "jee-jakarta-transition", which tells you the maintainers consider this the notable difference between the two releases.
My read: for a new project on Java 11 or above with no legacy javax dependencies, 7.0.0 is the straightforward choice. For anything carrying older servlet or persistence code, 6.0.0 exists precisely so you do not have to do the package rename in the same change as your DI adoption.
## Where Guice is the wrong tool
Guice is a dependency injection container and the README says it is not a kitchen sink. Nothing in the README suggests it routes HTTP requests, manages transactions, reads application.yml, or gives you a component-scanning convention. If your requirement is "one dependency that also serves my web endpoints and my configuration," Guice is the wrong layer and you will end up assembling several libraries yourself.
The second limitation is scope of support. The README's extension list is finite: assistedinject, dagger-adapter, grapher, jmx, jndi, persist, spring, testlib, throwingproviders. If your integration is not on that list and not covered by the core API, the README offers no path other than extending Guice yourself, which it describes as an intentional design position rather than a gap.
Third, the release cadence visible in the release list is slow. The most recent releases listed are 7.0.0 and 6.0.0 from 2023-05-12. The repository's last push was on 2026-09-10, so work continues, but a team that expects frequent version bumps with migration notes should look at what the release list actually shows rather than at the commit activity.
## Guice against Spring and Dagger: same problem, different trade-offs
Spring is the comparison the README's own ecosystem invites, and the difference is scope. Spring is a framework with a DI container inside it; Guice is a DI container and the README is explicit that features are omitted when they lack three use cases. Choosing Spring means accepting a larger surface in exchange for configuration binding, web integration and lifecycle management arriving together. Choosing Guice means writing or assembling those pieces yourself, and getting a container whose binding rules you can hold in your head.
Dagger takes a different route again, and the repository acknowledges it directly: one of the listed extensions is dagger-adapter. Dagger resolves the graph at compile time through annotation processing, so wiring errors appear during the build. Guice resolves at runtime when the injector is created. That single difference decides a lot: Dagger suits environments where reflective startup is unwelcome, while Guice keeps the module API direct and does not require an annotation processor in the build. Guice also ships a grapher extension, which is a runtime-graph tool with no compile-time equivalent.
Neither comparison is a verdict. If you already run Spring, adding Guice to the same application means two containers and two mental models, which the README does not discuss.
## Licence, upgrade cost and what maintenance looks like
Guice is Apache-2.0, per the README's license link and the COPYING file at the repository root. That is a permissive licence, and the practical consequence is that you can ship it inside a closed product. It is not a legal opinion and does not cover what your own dependencies require; read the licence text and your organisation's policy rather than this paragraph.
The upgrade cost is dominated by the javax/jakarta decision. Because 6.0.0 and 7.0.0 are otherwise equivalent, moving between them is not a feature migration, it is a package migration across your own code and your dependency graph. The README's Guice600 page is the reference the project itself points at for that transition.
Extensions add a second constraint: their versions must match the core version, so an upgrade is not just one version property. On maintenance, the facts are that the repository is not archived and the last push was on 2026-09-10, while the newest releases listed are from 2023-05-12. Those two facts together describe a project that is still receiving changes but is not cutting releases often, which matters if your policy is to track upstream releases rather than commits.
## Conclusion
Adopt Guice if you have a plain Java application or library where constructor wiring has become repetitive and you want the container to stay out of the way: no classpath scanning, no XML, no application server. Do not adopt it if you need transaction management, HTTP routing, configuration binding and a DI container from one dependency, because Guice deliberately is not a kitchen sink, and its own README says features are left out when in doubt. Before committing, verify which of the two release lines matches your stack: 7.0.0 supports jakarta.{inject,servlet,persistence} while 6.0.0 supports javax.{inject,servlet,persistence} and only mostly supports jakarta.inject, and the README states the two releases are otherwise equivalent. Then check whether the extension you need exists under com.google.inject.extensions, because extensions are versioned separately from core and their versions must match.
## FAQ
### What is Google Guice used for?
It is a dependency injection framework for Java 11 and above. The README says it removes the need for factories and direct use of new, so classes declare their dependencies with @Inject and a container supplies them.
### How is Guice pronounced?
The README states it is pronounced "juice". The project name is spelled G-u-i-c-e.
### How do I use Guice in a Java project?
Add the com.google.inject:guice dependency from Maven Central, define a module that declares your bindings, and build an injector from that module. The repository includes examples/guice-demo/ and the README links a user guide, the Motivation wiki page, for the annotated walkthrough.
### What is Guice in Java?
According to the README, it is a lightweight dependency injection framework brought to you by Google, aimed at Java 11 and above. It embraces Java's type system rather than relying on configuration files.
### Guice vs Dagger: how do they differ?
Guice resolves bindings at runtime when the injector is created, while Dagger is a compile-time annotation processor. Guice also publishes a dagger-adapter extension under com.google.inject.extensions, and a grapher extension for inspecting the runtime graph.
### Guice vs Spring: which should I pick?
The README describes Guice as not a kitchen sink, with features left out when in doubt, so it covers injection rather than the surrounding framework concerns Spring bundles. If you need configuration binding, web integration and lifecycle management from one dependency, the README offers no equivalent.
## Sources
- [google/guice on GitHub](https://github.com/google/guice)
- [License: Apache-2.0](https://github.com/google/guice/blob/master/LICENSE)
- [Project website](https://github.com/google/guice)
- [README](https://github.com/google/guice/blob/master/README.md)
- [Releases](https://github.com/google/guice/releases)
---
Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-guice