ALEXIS MOUSSINE-POUCHKINE: Hi, everyone.
We're here at Devoxx in Antwerp, Belgium 2014,
and I'm here with the Guava team.
Can I call you guys the Guava team?
GREGORY KICK: Certainly members of it.
There are seven of us in total, but just the two today.
ALEXIS MOUSSINE-POUCHKINE: Just seven.
Not one more.
So do you guys want to introduce yourselves
and say what you focus on in Guava?
And there's more to Guava.
I introduced you as Guava, but you're the Java Google team.
You do a number of projects.
Define what you do, really.
KURT KLUEVER: Sure.
GREGORY KICK: We are officially Google's Java Core Libraries
Team, but even that's becoming a little less
than what we do these days.
We work on tools and all sorts of things.
I'm Greg Kick.
Been a member of the Java Core Libraries Team
for two or three years now and a Googler for six,
and been contributing to Guava since even
before I worked there.
KURT KLUEVER: I'm Kurt Kluever.
I'm the sole member New York, and I've
been on the team for about the same time as Greg, two or three
years, and at Google also for six years.
ALEXIS MOUSSINE-POUCHKINE: A lot of people
use Guava because it seems to fit a need that innovates
and creates things that people could not
find in the default class libraries.
Eventually, Java evolves.
Tell me more about why people use Guava today,
and maybe with Java 8 being out, lambda streams,
how things might be changing.
KURT KLUEVER: Guava is going to pretty drastically change
when we eventually switch to Java 8.
A lot of stuff has been obsoleted and a lot of stuff
needs to change.
Actually, we haven't even made the jump to Java 8
yet at Google, so we've got a lot
to work on to restructure all the libraries
and get rid of stuff that's been obsoleted and whatnot.
There's going to be a lot of change coming.
GREGORY KICK: There's two sides to that coin.
For Android specifically and supporting legacy platforms,
we are going to be in a pre-Java 8 world for a very long time.
ALEXIS MOUSSINE-POUCHKINE: You still have a Java 6 requirement
today and you'll keep that for a long while.
GREGORY KICK: Right.
We're not going to drop our Android users on the floor
anytime soon.
We plan to support them for as long as practical.
But on the other side of that, looking towards Java 8,
the library as it stands, a lot of the things that
are included-- the function interface,
the predicate interface-- those are all single method
interfaces that are perfectly compatible with lambdas
and those types of things, and that's no accident.
Java 8 was designed with some of those legacy
compatibilities in mind.
A lot of the things will just work straight out of the box,
but we have another teammate, Louis Wasserman,
who's been doing nothing but working on figuring out
how to make streams fit into Guava and lambdas fit
into Guava and make sure that all of the collections that we
provide are compatible.
I believe that those are available in the open source?
KURT KLUEVER: Yeah.
I think he has a project on Git Hub already
that has Guava building with Java 8
and actually has a lot of inter-op working already.
GREGORY KICK: Right.
So I'm sure that some combination of "Louis Wasserman
GitHub Guava," that Google search
will get you to some new content if you're interested.
ALEXIS MOUSSINE-POUCHKINE: Just use your favorite search tool.
I read somewhere that you guys are actually
removing deprecated methods, which
seems very awkward and different for people that
are used to the classic Java libraries.
Tell me more about how it's working for you and your users.
KURT KLUEVER: Sure.
At least internally, we are pretty
aggressive about removing bad APIs or legacy APIs.
And actually, with a lot of the stuff that's
going into Java these days with Java 7 and Java 8 especially,
there's a lot of stuff that's been obsoleted.
So we do pretty aggressively remove stuff.
At least our policy in the open source Guava
is if it's a non-beta API, we give it
18 months to just leave it in the deprecated state
to get users to switch off of it.
If it's a beta API, the beta annotation
really just means non-frozen.
So if it's a non-frozen API, we typically say one release,
but it typically ends up being two or three that
will give you time to move off of it.
ALEXIS MOUSSINE-POUCHKINE: And have you
had people complain about it?
How does it work for your users, really?
GREGORY KICK: This isn't, oh, we decided
we don't like this thing.
We're deleting it.
The best example that I can think of
is we used to have for a long time a class called char sets.
People work with char sets to read files into text
all the time, and we made it convenient to have
constants for things like UTF 8.
Java 7, I believe, introduce standard char sets,
and now the exact same equivalent functionality
was in the JDK, so it didn't make sense for us
to keep our entirely functionally equivalent version
around in Guava if the JDK is already providing it for you.
So that was a case where it was clear to start the removal
process just to give people one option rather than two.
Decisions like that are usually pretty uncontroversial.
KURT KLUEVER: Actually, one of the more controversial
decisions we've had is all the static factory
methods for collections.
We have list.newArrayList, which people
love to use to thwart the necessity for generics
on the right hand side of the assignment.
Of course, that's been obsoleted with the dot operator,
so we've had this really tough decision
to make internally whether we just leave those methods there
and let people continue to use those
or if we just force them to use the diamond
operator with the collections.
I think that's still in flux.
I don't know what the final decision there is.
ALEXIS MOUSSINE-POUCHKINE: Cast your votes.
GREGORY KICK: But we always try to listen to user feedback,
whether it's internally or externally,
and make the decisions that make people happiest.
ALEXIS MOUSSINE-POUCHKINE: Let's switch gears a little bit.
So Guava is lots of different things
for lots of different people.
Let's not get into how we modularize Guava discussion.
There's plenty of things you can read online about it.
Dagger.
So Dagger and dependency injection, not something new.
The concept has been around for a long time,
whether it's Pico, Spring, and Dagger now,
Dagger 2, even, I hear.
Tell me how we got to this and why
did we have all these generations,
and what is the problem you're trying to solve?
GREGORY KICK: First of all, kudos
for remembering PicoContainer.
ALEXIS MOUSSINE-POUCHKINE: I'm sorry.
GREGORY KICK: Not too many people do these days.
I just recently gave a presentation.
There's a good history on how we arrived.
Dependency injection is great, and we've
used it to great effect.
Juice is probably one of the most widely used frameworks
within Google, has tons of adoption
and lets us make very large apps very effectively.
But the chief complaint has always
been that because you do all the configuration
of your dependency injection at runtime,
it can be a bit of a mystery how your application lays out.
When you build up very, very large applications,
like Google Docs and things like that,
debugging can be a bit of a trick.
When you see an issue in production
and you don't really know why things were configured
the way that they are, reasoning about why that may or may not
be from your code can be difficult
if all your configuration happens at runtime.
So Dagger 1 was a step in the right direction where
it used code generation rather than reflection to statically
configure some of these different dependency injection
options, and you could start to inspect more and more, just
in your code base at compile time, rather than at runtime.
Dagger 2 is the next evolution.
Dagger 1 was originally developed by Square
with contributions from Google.
Now Dagger 2 is mostly developed at Google
with contributions from Square, and it is a fully compile time
solution.
Everything about your dependency injection graph
is all written down statically.
From the very high level entry point
to your application, all the way through the graph to the very
lowest level node, you can navigate
using things like find usages and open declaration
in Eclipse.
So for the first time ever, we've
gotten rid of all the dynamism that
was causing a lot of issues, and we now
have an entire application laid out
at compile time that survives things
like ProGuard in your mobile environments and obfuscation
because you have the entire application written down
as just pure, simple Java code.
ALEXIS MOUSSINE-POUCHKINE: So from a developer
perspective, does that change anything?
You have injection points.
Do you have additional features, or do you actually
have less features, maybe?
Maybe compare that with Juice.
GREGORY KICK: Absolutely, there is a trade off.
We don't have a lot of features that
were solely reflection based.
We're viewing that is a good thing because there's
a lot fewer places where you might get a little confused,
but some people that used heavy use of AOP,
the aspect-oriented programming, where you could dynamically
change behavior at runtime, there's no support for that.
Anything where you were changing the shape of your dependencies
based on a runtime flag, there's no support for that.
We've got a lot of work alike solutions
for many of the patterns that people found that they needed,
and we've been able to run large search applications.
Large portions of the search stack
have been fully implemented using Dagger 2,
so we're confident that there are
solutions to all of the problems.
They might just not look exactly the same
as they did with Juice.
ALEXIS MOUSSINE-POUCHKINE: You mentioned Square
as the initial writers and developers
of the first version of Dagger.
Is this whole thing really mobile driven and mobile only
as a solution, or could you see Dagger 2
specifically elsewhere, and maybe supporting
things like servlets?
Does it make any sense.
GREGORY KICK: Absolutely.
ALEXIS MOUSSINE POUCHKINE: I mean, fast startup
is one of the things you also get.
Because of that, you're not doing all that class
scanning and generating code at startup or at runtime,
so I'm sure that works well in the cloud, too.
Everybody likes fast startups.
GREGORY KICK: Yeah, nobody ever complains
about good performance.
While we have, certainly within Google,
a lot of mobile applications running Dagger, like I said,
Dagger 2 specifically powers a pretty large portion
of the search stack.
When we transitioned from Dagger 1 to Dagger 2,
we actually saw a 13% improvement on per request CPU.
Fast search results is what we do,
and Dagger 2 is now part of that solution,
and that's been pretty rewarding.
ALEXIS MOUSSINE POUCHKINE: Where's Dagger 2 now?
Can you give us a status?
GREGORY KICK: Dagger 2 is still building
from head for the most part.
We haven't had quite the 2.0 release yet.
We expect to have a feature complete, bug more or less free
beta version coming soon, but right now, you just
have to pull it down from GitHub and built from head.
ALEXIS MOUSSINE POUCHKINE: Sounds good.
Switching gears once again, how about we talk about something
called Truth?
I've heard about it, but really, you
need to tell me and probably everybody
else what this is about.
KURT KLUEVER: Sure.
So it's a fluent assertion library based on JUnit
that we've been using for a couple years now inside
of Google.
We've been focusing on it for about six months now,
and we've really been driving the adoption and change
in the API from a bunch of legacy assertion libraries
that we had inside of Google.
So we had this one, maybe 200 different static assert
methods, assert blasts or all these different assert methods.
It was just a big grab bag of assertion methods
that users just couldn't navigate
because it was just way too big and complex.
So we have evolved the Truth library
to fit the needs for these users.
We've been, like I said, focusing on it for probably
about six months now, and driving the adoption of Truth
by migrating those legacy users to this API.
ALEXIS MOUSSINE-POUCHKINE: OK.
So that's yet another project that you're working on.
Where is that at today?
KURT KLUEVER: That's open source is well.
We haven't really even set goals for when
we're going to do a 1.0 release or anything like that,
but we've been doing snapshot releases and stuff like that.
It's all being synced up to GitHub as well.
ALEXIS MOUSSINE-POUCHKINE: Any external committers,
external interest?
KURT KLUEVER: There's certainly interest out there.
I don't know that we've had a whole lot
of external committers, but--
ALEXIS MOUSSINE-POUCHKINE: Any call to action?
What should people expect and look at?
KURT KLUEVER: I mean, they can certainly test it out,
and if they have any feature requests,
submit those as issues.
We've had a handful of good ideas come
from external contributors as well.
ALEXIS MOUSSINE-POUCHKINE: So just ideas and you
implement, right?
You do the work.
KURT KLUEVER: Typically, that's--
GREGORY KICK: And I'm going to give a little sales pitch
on Kurt's behalf.
A lot of people will ask, assertion libraries
have been around forever.
Why don't I just use JUnit to search?
Why don't I use AspectJ or--
KURT KLUEVER: AssertJ.
GREGORY KICK: AssertJ.
That's the one.
AssertJ or Fest or Hamcrest or whatever it may be.
The big selling point of Truth is that its fluent assertion
library is also very pluggable, very modular.
For Dagger, we've been using Truth
to be able to test our annotation
processors because we were able to build in,
just spun a quick little project called Compile Testing that
lets us now hook into the fluent chain assertions
about annotation processors and the results
of your compilation.
And because you can very quickly and easily add new bits
to the chain for your specific types,
we found Truth to be really powerful.
So whether it's things like protocol buffers,
or your new fancy collection, the Guava collections
like Multimap and Multiset, we can now
build in extra assertions as we go
rather than having to recompile a whole new version
of the library and make a new static method somewhere.
KURT KLUEVER: And those custom assertions, like Greg
alluded to, people on their own smaller projects,
they can make these domain specific languages
and make the assertions exactly how they
would read it in fluent English.
So we've had teams all over Google
making their own plug-ins to Truth
to make their assertions read a lot better.
But inside of core Truth, we basically
have assertions about a lot of the JDK types,
and also a lot of the Guava types as well.
It has a dependency on Guava, so we're
adding custom subjects for all those Guava types as well.
ALEXIS MOUSSINE POUCHKINE: Sounds good.
Before we close-- we only have so much time.
We could go on.
I have a lot of questions, but maybe one final question.
You've been living and breathing Java for years, it seems.
Where do you see Java in five years?
GREGORY KICK: That's a tricky question
because, at least as far as the things
we've seen, the things that I've personally worked on,
we've been very satisfied with the state of the libraries.
We've settled to a pretty decent, steady state
with just contributing new libraries
and having people consume them that way,
but a big increase in tool driven pseudo libraries.
Dagger 2 is entirely annotation processor based.
AutoValue, which is a great project,
and some of the other Auto projects
that generate code based on annotations for you
and take out a lot of that boilerplate, that's
been very quickly becoming the go to solution
for a lot of problems that were left unsolved previously.
So I see more and more people writing less and less code,
and lambdas and streams seem to be in that vein,
too, where you used to have to write
big, bulky anonymous inner classes, where
now nice, convenient cheap lambdas.
KURT KLUEVER: Java is no longer this ceremonious language.
GREGORY KICK: Less and less of that.
So I frankly expect that in five years,
we will be writing the same type of code, just much less of it.
ALEXIS MOUSSINE POUCHKINE: Sounds
like a bright future to me.
Thanks, guys, for doing this, and enjoy the conference.
GREGORY KICK: Excellent.
Thanks.
KURT KLUEVER: Thank you.