Tag: guice

If you come from a large Java shop, you’ve likely heard of or encountered Guice — Google’s lightweight dependency injection framework; analogous to Spring.

First time users of Guice will usually be starry eyed amazed at the ability to get type safe dependency and the seemingly modular way in which to bundle up your dependencies into Modules.

Much of the tutorials, guides and best practices found online though are targeted towards smaller codebases, and anyone in large Java shops will have likely hit the spaghetti of configuration and AbstractModule dependencies to get your code to boot up — seemingly ruining the modularity of using a dependency injection framework.
This post is aimed at some best practice I’ve found for keeping AbstractModule composable and easy to understand.

If you don’t want to read to the end just checkout my project on solving Guice deduplication — guice-dedupe

Composition

The biggest hurdle large projects will face in Guice is that you’ll want to keep Modules resuable and more importantly self-contained.

Consider the following example where I have a JSON class that is bound in a module, and two other modules want to make use of it.

Guide binding duplication example

Java

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

publicclassExample{

publicstaticclassJsonSerializer{

//Implementation not important

}

publicstaticclassJsonModuleextendsAbstractModule{

@Override

protectedvoidconfigure(){

bind(JsonSerializer.class);

}

}

publicstaticclassModuleAextendsAbstractModule{

@Override

protectedvoidconfigure(){

install(newJsonModule());

}

}

publicstaticclassModuleBextendsAbstractModule{

@Override

protectedvoidconfigure(){

install(newJsonModule());

}

}

}

We’d like to make use of the install option, so that a consumer can either use ModuleB or ModuleA and the necessary bindings are self-contained. The problem arises if ModuleA and ModuleB are used — you’ll be treated with a Multiple Binding Exception.

Many codebases, simply remove the installation of Module dependencies and move the mess of figuring out the right set of final modules you need at moment you try to create the injector. What a mess!

The way to solve this is to use Guice’s built-in de-duplication code. For the most part it works out of the box, unless you are using @Provides in your modules.
Simply change all your existing AbstractModule to SingletonModule from the library guice-dedupe and you’ll get modules that are fully self-contained now even with providers.