What are some of the most useful yet unknown Google Java libraries?

If we would stop someone during an intense hackathon and ask her to name a popular Google Java library, the answer would probably be Guava. It’s no wonder, since its main focus is improving developer productivity. But what about other Google libraries? Have you had a chance to check them out?

In the following post we’ll go over some interesting Java libraries from Google, and give you a peek as to what you can do with them.

Adding another library to the mix

First, let’s be clear: we love Guava. It contains some of Google’s core libraries for Java based projects, such as collections, caching, common annotations, I/O and others. These are useful not just for Google developers, but for the wider community as well.

Although it’s not the only cool thing that came out of Google. We’re not talking about driverless cars, Google fiber or project Ara (and we’re still waiting for that last one) – we’re talking about more libraries.

The good news are that there’s no need to comb through every available library in order to find the right one, since we did that for you. We chose 5 Google libraries that could make your life easier and code a little bit nicer. Check them out:

1. Dependency Injection – Guice

Guice is a lightweight dependency injection (DI) framework for Java, performing a similar role to Spring’s core Inversion of Control (IOC) library. It’s almost as popular as Guava. If you’re not familiar with it, Guice eases the need for factories and simplifies the use of ‘new’ in your code. In Google’s own words, Guice @Inject is the new new.

While this library won’t absolve you from writing factories, it will help make sure your code is not directly dependent on them. That way, it will be easier to change, unit test and reuse your code.

The cool factor

This library aims to make development and debugging easier and faster. The documentation even claims to help you get a better understanding of your code. Another cool feature Guice offers is generating helpful messages when errors occur, so you’ll have an idea of what happened and how you can solve it.

2. Static Analysis – Error Prone

This open sourced library is a static analysis tool for Java, allowing you to catch common programming mistakes at compile-time. You can be the best developer in your team, but you or one of your colleagues might be pre-occupied by the latest Game of Thrones episode, and make a mistake.

In other words, this tool will help you catch mistakes before they become bugs in production and mess up your application.

For example, one of the bug patterns it can detect is CannotMockFinalClass – which indicates that Mockito cannot mock final classes:

The cool factor

On the official library page you’ll find a list of common errors and their suggested fixes. This means that each error has a solution that someone already thought of, and you can implement it easily in your own code. By the way, if you’re interested in common production errors, check out our analysis on the top 10 exception types in production.

3. Meaningful Errors – Truth

Truth is a testing framework, made to help your test and error messages be more readable and discoverable. It generate meaningful error messages that report on why tests fail, while being extensible to new types of objects. Oh, and it comes with the awesome catch phrase “We’ve made failure a strategy”.

You can use Truth in place of JUnit’s assertions, FEST, or Hamcrest’s matchers classes, or simply use it the way you see fit for your code. It presents you with a test verb that asserts on a subject, the value or object under test.

You can use Truth in order to declare JUnit-style assumptions (and skip test on failure), assertions and exceptions.

4. Language-Agnostic Protocols – Kythe

Kythe provides and supports tools and standards to encourage interoperability (sharing, exchanging and using information between systems) among programs that manipulate source code. An easier way to explain it is to say that this library gives an ecosystem for building tools that work with source code.

The main goal of this library is to provide a standard, language-agnostic interchange mechanism, that will work on any source code. It includes build systems, compilers, interpreters, static analyses, editors, code-review applications and more. That way, you’ll be able to share information with any other system you’d like.

The cool factor

Kythe comes with a rich community that will answer any question you have. Need help with Kythe on Python, JavaScript or Java? Want to know how to model Python modules? Or do you simply want to know how to pronounce Kythe? Just ask the community.

5. Serializing Structured Data – Protobuf

Protobuf, the library that’s also known as Protocol Buffers is Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data. If you’re not sure what it means, Google explains that it’s like XML, only smaller, faster and simpler.

If we had to choose a slogan for this library, it would probably be “structure once, use anywhere”, and that’s the best way to describe it. Once you define how you want your data to be structured, you can use special generated source code to read and write from a variety of data streams and using a variety of languages.

The cool factor

Full disclosure is in order here: protobuf is one of our favorite libraries here at Takipi, and we can guarantee it will help you make complicated elements a little bit easier.

Did we forget anyone?

We know what you’re thinking – so many libraries and not a single word about GWT. GWT is a development toolkit for browser based applications, enabling the creation of high performance web apps even if JavaScript is not your strong suit. It’s basically a Java to JavaScript compiler.

This free, open sourced library became popular due to the many Google products that used it. That list included Google Inbox, AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet and Blogger, all very known and powerful products that came out of Google.

There are a few well known companies beside Google that use GWT, such as Ruxit, Go Grid, Whirled and others.

Additional Google Libraries

Following a comment on twitter we’ve decided to add 2 more useful libraries that weren’t mentioned here, thanks @joschi83!

1. AutoValue – A collection of code generators that automate generation of repetitive Java code.

2. GSON – The popular Java serialization/deserialization library that can convert Java Objects into JSON and back.

Final thoughts

There are a lot of Java libraries that can help your code and make it smarter and easier to use. All you have to do is understand what you’re looking for, and see how a certain library can help.

If you’re a hardcore Guava fan and couldn’t find anything useful in these other libraries, you should check out some of the lesser known features of Google Guava that every developer could use.


Join over 30,254 Java developers

Get new posts directly to your inbox about Java, Scala and everything in between

Watch a live demo
I write about Java, Scala and everything in between. Lover of gadgets, apps, technology and tea.
  • Caleb Cushing

    I like error prone as it’s the only tool I know that will tell me when @Override is missing. I use it to complement checkstyle and findbugs.

    After reading Truth, I can’t figure out why I would use it over hamcrest, it’s not clear that it gives better messages than hamcrest, and certainly doesn’t look as easy to extend (by writing your own typesafe matcher). Hamcrest output isn’t always perfect, but it’s usually better than straight junit, and for long string comparison is far superior.

    • NonPlusUltra

      You should try Eclipse, it’s not only warn you about missing @Override annotations, but can be configured to even automatically add where it’s needed.

      For Hamcrest and Truth you need to type too much, I would avoid where I can. And it’s not very readable.

      • Caleb Cushing

        I’ve tried Eclipse, I dislike it strongly, I prefer Intellij Idea. I do not believe IDE warnings are strong enough because they won’t fail the build if missing. IDE’s making the typing a non issue… as far as readability I find that fine. Hamcrest is the only comparison where I can tell when string comparison is failing to line endings (CRLF vs LF) (haven’t tried truth). Also the output for list comparisons is much better. Lastly I can write my own matchers, can’t do that with straight junit. Also assertEquals and such are procedural not OO or Functional, that may sound like purism, but it’s why you can’t write your own matchers. YMMV, not trying to sell you.

        • NonPlusUltra

          If you use a good IDE, you could even configure which issue should be just a warning, or a compilation failure. You don’t need to believe in anything, it’s just works. Yes, you can add additional checks during your CI build, but it’s generally a waste of time and resources, waiting ~15 minutes for a whole build (in a reasonably sized project).

          For assertions, I would follow the KISS principle:

          1, one assertion should only fail for one reason – so no need for fancy strings to figure out, what went wrong – the expected, and the actual value must be enough
          2, it’s much simpler to write one or two simple function, that to dive deep into one of the frameworks, to figure out, where a new class could be added / registered, etc.

          YMMV, but I hate complexity, I’m too old, and seen too much, to easily fall in the tempation for using some fancy buzzword 🙂

          • Caleb Cushing

            1. So the assertion fails when 2 strings aren’t equal, if they are long, like paragraph long, try figuring out where they failed. junit assertEquals is *really* terrible at this. I’ve found hamcrest assertThat( string, is( “string” )) to be much better, especially if it’s a whitespace difference, because the latter will point that out where the former just renders whitespace (visually they would look identical)

            2. I believe in encapsulation, you shouldn’t poke at the internals of your frameworks. It’s a good way to ensure you’ll be rewriting functionality in a few years too.

            I don’t understand what you mean by “buzzword” here, I see no buzzwords.

          • NonPlusUltra

            1, just click on the stack trace – in a good IDE – thrown from an assertEquals(…) method, and you would see a nice comparison dialog about the expected and the actual value, colored, etc – it works with TestNG and JUnit AFAIK.

            2, for more concise and readable checks you will need to customize the matchers, I imagine, I would want an assertion in hamcrest/truth like assertThat(user).isAdminOrModerator(), then what can I do? How fluent can it be? Or if instead of assertThat(string, is(something)) I would like to have a case-insensitive contains check? I guess, for this some poking will be needed, especially if a nice error messages are expected. As opposed to a simple POF (plain old function), which can be written in 2 minutes.

            3, buzzword : “fluent”, “functional”, etc

            Of course, you can pick a new, fancy testing framework to compensate the deficiencies of your fancy IDEa, but I always prefer to stick with less framework, less unnecessary classes, objects, more concise code, which simply do, what it seems to do. YMMV.

          • Caleb Cushing

            1, that really doesn’t always work with the newline problem, CRLF’s and LFs often show the same, which is just the “newline”, it requires that junit actually print n or rn for the IDE thing to work. Also you’ll only really see this issue if you work on a team that uses more than one OS. If everyone is using unix, or has everything set up correctly to convert all the time, you won’t see this, it’s a very stealthy bug, resulting from incorrect IDE, SCM, and often, hardcoding the newline output into multiline strings instead of using %n with String.format or some other method.

            2. Not sure about case insensitive but I think you can do assertThat( string.toLowerCase(), containsString( “myString” )); I don’t need containsString often, I largely use hamcrest for just is( … ) or for matching complex “Iterables” since I can match them in order in a single statement in a way that’s largely readable.

            3. Those have actual meanings in how something is coded, and the caller style. I’m guessing you don’t like fluent api’s. To be fair fluent is largely syntactic sugar, and sometime going out of your way to be fluent gets in the way (Hence my skepticism about Truth being extensible because it’s fluent and chaining… where hamcrest doesn’t chain)

            all this said I’m still very tempted to implement my own thing, because even though hamcrest has better output for strings, and more flexible matching for things like lists, or writing my own matchers, I’m not always happy with it’s output or static method names, (e.g. contains being order sensitive and needing containsInAnyOrder, to do the set like operation)

  • Csaba

    As I see it, currently Guice is dying, and getting deprecated, since CDI 1.1 …

    • Marouane

      Forget about Guice, thik about Dagger.
      Dagger is a fully static, compile-time dependency injection framework for
      both Java and Android. It is an adaptation of an earlier version
      created by
      Square and now maintained by Google.”

      • Yannick Majoros

        For Android, you’re stuck with ad-hoc stuff like this. Otherwise, on a real jdk, it’s a niche, non-standard product that I’d never swap CDI for.

        • Igor Ganapolsky

          It is ad-hoc? I thought Google is developing it for multiple projects…

  • gacl

    Protobuf?!? I thought Avro has mostly replaced Protobuf? Not even a mention of Avro? Avro is simpler, requires no version numbers. Avro is natively integrated into Kafka, Hadoop, and Spark where Protobuf is not.

    • Vitor Vezani

      Is Avro a Google Library?

      • gacl

        Is the article “5 google libraries that every Java developer should use if they were stranded on some bizarre desert island where they had to develop software with only google libraries?”

      • gacl

        The article is “5 Google libs Java devs should know”. Java devs should generally pick the best library for the job, and only pick a Google lib if that happens to be the best lib for a given goal.