[Xamarin.Android.Build.Tasks] Give a proper warning when JDK 1.8 is required but not installed

[dellis1972]

Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=51507

If a user has an older verison of Java installed they currently get
this kind of helpful error message.

"Unsupported major.minor version 52.0"

While for the experienced user this might mean "Ah I need Java 1.8".
For the new users this is confusing.

This commit adds a new property in the Xamarin.Android.Common.props
called

`$(MinimumRequiredJavaVersion)`

This will define the Minimum required version of Java we need.
It can be overridden on the command line or in the project is needed.

If this mimimum version is NOT met, we will error out. While it
might be nicers to issue a warning, this will eventually end up with
the above error anyway. So we might as well tell the user exactly what
is wrong.

[jonpryor]

This fixes a problem, but isn't elegant.

For example, see the System Requirements section of our release notes:

• JDK 1.8 - up to API 24+
• JDK 1.7 - up to API 23
• JDK 1.6 - up to API 20

We know this.

The problem with this PR is that it adds a new $(MinimumRequiredJavaVersion) property that nobody is going to know about. Sure, we provide a default value, but the result is this: if someone has a development environment today which:

1. Has JDK 1.7 installed, and
2. Writes a project which Targets API-23 or earlier

then their currently working system will no longer work after upgrade. We will instead flag an error.

This is, shall we say, not desirable. :-)

What should instead be done is we should do in code what we currently have in the release notes: associate a minimum required JDK version which each $(TargetFrameworkVersion), and check the current java -version output against the associated minimum version. This will allow existing development environments to continue working as they have been.

---

There is one problem with the above approach: It is entirely plausible that, at some point in time, Android's build-tools SDK component (or whatever) will require JDK 1.8 in order to execute. Should that happen, we'll need a "global" java version anyway, and the approach of this PR may be more appropriate.

[jonpryor]

This doesn't Dispose() of the Process instance. You should wrap the new Process() in a using block to ensure we don't keep a process handle open longer than necessary.

[jonpryor]

Additionally, in the case of Bug #51507, this PR is not relevant at all.

...probably because the commentary is wrong or otherwise non-sensical. :-/

The original issue in that bug is:

java.lang.UnsupportedClassVersionError: com/android/dx/command/Main : Unsupported major.minor version 52.0

This error isn't coming from javac, nor is it coming from java. Checking the java version number will not help in any way with this error.

This error is coming from the dx.jar invocation in the <CompileToDalvik/> task, because an older build-tools version is being used -- a version which doesn't support Java 1.8 bytecode (back in the days that the Jack & Jill toolchain seemed like a good idea).

I forget which build-tools version is required to support JDK 1.8 bytecode. :-(

Given that, it seems that it might be a reasonable idea (?) to associate a build-tools version alongside a JDK version for each API level, to ensure that we can reasonably handle the project.

[jonpryor]

Just so we don't lose track, the <ResolveSdks/> task needs to gain a JavaToolExe property so that java/java.exe isn't hardcoded.

[jonpryor]

This and the following line should not be present.

[jonpryor]

Perhaps this should be using MonoAndroidHelper.RunProcess()? That should be a bit simpler.

[jonpryor]

Why default to Java 1.7 if we can't parse buildToolsVersion? Shouldn't we default to LatestSupportedJavaVersion?

[dellis1972]

where is LatestSupportedJavaVersion defined? I can't see it anywhere?