[TIMOB-26919] Android: Support d8 dexer.

[drauggres]

JIRA: https://jira.appcelerator.org/browse/TIMOB-26919

When property enableDesugar is defined on android tag in tiapp.xml and set to true,
build-script will use d8 tool to convert Java bytecode to DEX bytecode.

https://developer.android.com/studio/command-line/d8

d8 enables you to use Java 8 language features in your code through a compile process called
desugaring, which converts these useful language features into bytecode that can run on the
Android platform.

We need to update node-titanium-sdk version in package.json after this is merged.

[build]

	Messages
📖	🎉 Another contribution from our awesome community member, drauggres! Thanks again for helping us make Titanium SDK better. 👍
📖	✅ All tests are passing Nice one! All 1725 tests are passing.

Generated by 🚫 dangerJS against 38e45ac

[jquick-axway]

@drauggres , the master plan on our end is to switch to gradle. We'll then get this for free, along with some other goodies such as Kotlin support.

[drauggres]

It is good to know. Gradle would be really awesome.

[hansemannn]

@jquick-axway Is this a 8.1.0 or rather 8.x/9.x thing? If the latter, having this PR merged before would unblock many devs already as more and more native libs are shipped with Java 8 bytecode.

[jquick-axway]

The plan is to add gradle in the near future. If not 8.1.0, then 8.2.0... in case any unexpected surprises delay it.

Modules should already be able to leverage prebuilt Java 8 JARs now (ie: the JARs under the "libs" directory). We just restrict the module's own Java "src" code to Java 7. I'll double check this later, but that should work fine because the Titanium SDK itself builds this way (ie: SDK compiled with Java 7 and it references Google's Java 8 support JARs). The only thing you wouldn't be able to do is use classes that require Java 8 features such as Google's Lifecycle class. Although the Lifecycle class is another good example why we need gradle support, because Google's Java 7 solution involves using annotations that need to be processed by gradle.

Edit:
Hold on. We're talking about the dexer here, which happens after building the JARs (it merges the JARs to a DEX file). I haven't ran into any dexing problems with Google's own Java 8 built JARs. The only issue we had in the past was with an old version of proguard (it's part of the dexing/multi-dexing phase) that didn't understand the Java 8 JARs, but we solved it by updating to the newest proguard version. Interesting...

[hansemannn]

Sounds great, thanks for the insight @jquick-axway! And sorry for all those questions all the time :P

[drauggres]

We just restrict the module's own Java "src" code to Java 7.

Problem is exactly with third-party aar/jars written using Java 8 features (e.g. exoplayer).

[danimarin]

The patch presented by @drauggres works great for us. We are facing same issues with 3rd party libraries that use Java 8.

Gradle will be a real move forward in Titanium development. I think it is mandatory, because issues like this one (Java 8 / D8) or others like the duplication of classes, are making people to change to React Native, where they can code with Android Studio and resolve all these things with Gradle.

Thanks a lot @drauggres!

[garymathews]

Closing, as we will be using D8 through moving to Gradle builds.