Improve consistency on how unit tests are run.

[evant]

Right now this is kinda a mess. The java plugin runs all test code through retrolambda and then forces unit tests with an older java version. The android plugin, however, does not run test code through retrolambda and ensures the tests are run with java 8. Just to be clear, this is only for test code. Code under test will always be processed with retrolambda. I see two options:

1) Run all tests with java 8. This would be fastest since it doesn't require the retrolambda processing step. Downside is that by running with java 8 you might hide some accidental java 8 features/api usage not available on older versions. However, using some of the java 8 api in tests my actually be convenient. For android, this matters less since even with java 6 you are still removed from the actual platform you'd be running on.

2) Process all tests with retrolambda and run with older java version. A bit slower but should catch more issues. Another downside is that you need to actually have a previous version of the jdk installed just for tests.

Alternatively, I could provide an option to let you choose between these two, though that does come with additional implementation complexity.

I'm posting this here for feedback, any upsides/downsides I missed? Any particularly strong arguments for one over the other?

[jbrunton]

Personally, I'd prefer to keep the test execution time as fast as possible. At the very least, there should be an option to enable retrolambda for tests if the client so wishes, but which can be disabled. I'm not keen on anything which slows test cycle times across the board.

[Alexander--]

I have just stumbled upon this issue when trying to set up code coverage in my pure java project. Do you know, how to implement approach №1, mentioned in the issue description? I am getting UnsupportedClassVersionError because of tests being run with older Java version.

[Alexander--]

Note: I am getting it after disabling Retrolambda for tests by passing

exclude 'Test', 'TestReport', 'test', 'testCompile'

to retrolambda configuration block.

[zline]

I second the 2-nd option. Because it's more correct to run tests in the environment closest to production. As for speed, the main objective of tests is to catch bugs, not to be fast. Fast tests are great, but they are useless unless they catch bugs.

[Dunemaster]

I vote for the second option, too @zline is right. Desktop (HopSpot) JVM 7 is not android, but still closer than desktop JVM 8

[evant]

The more I think about this the more I'm leaning towards option 1 for two reasons:

1. 2 requires that you have an older version of the jdk installed to run your tests. This can really be a pain to set up. Even without retrolamba I've been using java 8 to compile and run tests because it's easier to deal with a single up-to-date version of the jdk.
2. The non-android java ecosystem has clearly moved on to java 8. Option 2 would mean you can't use the latest and greatest for unit testing. No junit 5 for example.

I think those downsides outweigh the benefit of sometimes catching accidentally importing api's that aren't available on android.

[evant]

Note: if api compatibility is something you are really concerned about, https://github.com/xvik/gradle-animalsniffer-plugin might be a better solution.

[zline]

1. 2 requires that you have an older version of the jdk installed to run your tests. This can really be a pain to set up. Even without retrolamba I've been using java 8 to compile and run tests because it's easier to deal with a single up-to-date version of the jdk.

Is't it as easy as apt-get install openjdk-7-jdk or run windows installer?

2. The non-android java ecosystem has clearly moved on to java 8. Option 2 would mean you can't use the latest and greatest for unit testing. No junit 5 for example.

I agree that java 8 is great, but are't we using retrolambda in the first place because there are situations where we can't go java 8.

Note: if api compatibility is something you are really concerned about, https://github.com/xvik/gradle-animalsniffer-plugin might be a better solution.

Interesting, but it can't check dependecies.

[ZacSweers]

Option 1 is the best option here, and the SDK is moving to java 8 as well natively. If people don't want to update, then they should tools like retrolambda to hack in new language features anyway ¯\_(ツ)_/¯.

[evant]

I've taken the first step towards option 1 in version 2.6.0. If oldJdk is not defined (or JAVA6_HOME etc.), it will use the current java version instead. There properties are deprecated but will still work the way they were before.