Month: May 2016

Some Thoughts About the Big Trial

I’ve been following with interest the second trial between Oracle and Google, thanks to excellent coverage on ArsTechnica by Joe Mullin. I am not a lawyer, but I have seen some apocalyptic hyperbole about this trial which seems misplaced. And I’m not sure to what extent Google’s victory in this round is a win for the Java programming community, as Google has announced.

Intellectual property is part of software development, whether we like it or not (and we humans tend to like the idea of property a lot more when we are its owners), no matter what the ultimate outcome of this trial (Oracle has vowed to appeal, so it’s not really over).   It can be a pain to have to deal with copyright for what seems like a minor part of one’s creation – just ask Men at Work – but it also allows people who create things to make money. And just because Google has thus far been able to resist a legal assault based on copyright doesn’t mean your little startup will.

As software developers in the world of commercial software, we are for the most part paid by companies which tell their investors that they are investing in intellectual property.  Without that investment, our field might not exist outside of some obscure corners of universities.

There is of course a trade-off between freedom from restrictions, which attracts development activity, and restrictions, which attract investment.  In our industry, it seems like a majority companies end up failing, and so developer salaries have probably come more from investment than from consumer purchases or ad revenues.

Sun Microsystems tried to have it both ways, touting Java as free to use while assuring investors, including ultimately Oracle, that they had intellectual property protections. This is the gray area where Android was created. Oracle’s lawyers thought they had a smoking gun in their case with Google’s internal email from 2010 (PDF file), but the issues around open source and licensing are complex, and this jury didn’t see things the way Oracle’s lawyers do. In 2006, Sun announced Java as being free and open – as summarized by the Free Software Foundation. Note that the announcement by Sun linked to in the FSF article is no longer functional on Oracle’s web site, but I think I have found it in Oracle’s blog archives.

Android seems to be good for Java usage.  Java usage was in decline until late 2013.  It has sharply risen since then.  The release of Java 8  and the decline of Objective-C after Apple’s switch to Swift probably contributed to this rise, but I think that Android is a big factor.

TIOBE index graph in 2016 showing recent rise of Java
TIOBE index graph showing the decline and rise of Java usage


A Testing Toolbox for Java 8

A few months ago, I presented interface-it, a java-8 tool to generate mixin interfaces. In case you don’t know what that means or why mixins could be useful to you, I wrote a short article which explains it.

One of the key motivations for the interface-it tool was to be able to generate mixins for the latest versions of unit-testing libraries like Mockito and AssertJ. Now you no longer have to worry about that, because I’m doing it for you. And more.

I now have several more projects to present to you.

Presenting tdd-mixins-junit4

Working backwards – if you want to have a great test fixture by adding only one dependency in your build configuration (your Maven Pom, Ivy xml, Gradle, or just a fat jar added to your classpath), use tdd-mixins-junit4. It gives you all the basics you need to do mocking and assertions with fluidity, simplicity and power.

Normally, that’s all you should need for your tests. Mockito allows you to to set up collaborating objects and verify behavior, and the extensions I added make it even easier to handle cases where, for example, you want to mock behavior based on arguments passed to the mock which are generated by your unit under test. As for verifying returned results, AssertJ and JUnit assertions allow you to verify any data returned by the unit under test.

Presenting tdd-mixins-core

If you do not want to use JUnit 4 (maybe you want to use TestNG or an early version of JUnit 5), then you can use tdd-mixins-core, which has everything that tdd-mixins-junit4 has, except the mixin for JUnit assertions and JUnit itself.

Presenting extended-mockito

So these tdd-mixins libraries notably give you mixins for the aforementioned libraries Mockito and AssertJ. As for Mockito, they use my extended-mockito (TODO: link to project) library, which not only provides mixins for classes like Mockito and BDDMockito, but it also provides extra matcher methods to simplify specifying matching arguments for mocked methods. For example:

when(myMockSpamFilter.isSpam(containsOneOrMoreOf("Viagra", "Cialis", "Payday loan")))

See the project’s home page or the unit tests for more details.

Presenting template-example

As for AssertJ, it’s already quite extended for general purpose use, so there is no extended-assertj project, but if you want to take things farther, I did create a project called template-example, which shows how, with a little tweaking, you can use a Maven plugin to auto-generate custom assertions for your own JavaBeans which are combined with the AssertJ mixin from tdd-mixins-core. These custom assertions allow you to do smooth, fluent assertions for your own data types, allowing this sort of validation call:


With these tools, you can more productively write unit tests with powerful assertions and mocking. They give you a fixture that you can set up in any test class by implementing an interface or two – for example:

public class MyTest implements ExtendedMockito, AllAssertions {

Not Included

What’s missing from these tools? I wanted to keep the toolset light, so there are some excellent but more specialized tools which are not included. For example, I have generated a mixin for Jsoup, which is very useful if you need to validate generated HTML, but unless I hear a clamoring for it, I will leave it out of tdd-mixins-core because it adds a dependency that lots of people may not need. Same for extensions to AssertJ – I generated mixins for AssertJ-DB  and for AssertJGuava (UPDATE: also added one for Awaitility), but did not include them in tdd-mixins (you can copy and paste the generated mixins’ source files if you want to use them).

Another library which is useful but which does not lend itself to mixins (because it uses annotations rather than static calls) is Zohhak it simplifies testing methods which return results that depend on a wide variety of possible input values (such as mathematical calculations or business rules).

The What and Why of Mixins in Java 8

A mixin is a type which can be mixed in to (i.e. included in) other types via multiple inheritance. This allows the encapsulation of certain behaviors which cut across the main type hierarchy. In C++ this is fairly standard, though it’s sometimes discouraged because of the potential for the “diamond problem”. In Java 8, mixins can be created using interfaces with default methods.

Why use mixins in Java?

Mixins give you design options which you did not have before. A class can inherit behavior that isn’t in its superclass. For example, you can have Goose implements Honker and Car implements Honker – with no need to implement honk() more than once. Some more practical uses include test fixtures (which I will address in more detail in my next article), and logging.

Default methods in mixins are also very useful for wrapping static method calls, especially in legacy code. This is what my interface-it tool automates. So you can replace static calls with calls to interface methods that can be mocked in tests, and/or overridden for special cases. It allows you to make a procedural design more object-oriented and pull hidden dependencies out into the open. It also lets you avoid using static imports, which can make the code less readable.

Finally, a benefit of mixins is polymorphism.  You can override or extend the default behavior in special cases, which is something you can’t do with static calls.

API is Legacy

Now that I’ve released version 1.1 of interface-it, I understand better why so many projects decide to do a big 2.0 release which includes breaking changes to API’s.

Once you’ve decided to support backwards compatibility for all the exposed API (all public and protected methods in the public classes, normally), minor releases hit a lot of technical debt because you can’t refactor everything you want to. TDD doesn’t save you from this .

With interface-it, I made a few assumptions about the API which changed very quickly when I discovered new requirements. For example, before the 1.0 release, I thought about encapsulating some of the arguments to key methods, but I didn’t see clear affiliations or behavior related to these arguments. It was just data needed for generating a mixin. For version 1.1, where you can generate a hierearchy of mixin types (just parent-child via the command-line interface, but the code API is more flexible), it was no longer data but behavior that I needed, because I had to manage multiple classes in the same call. Despite having excellent code coverage thanks to TDD, the change was a bit painful to implement, and I had to leave in place some methods which I would have preferred to delete.