Context: #5468 (comment)

Commit 380e95e inadvertently broken @(JavaSourceJar) and @(JavaDocJar) support.

Steps to Reproduce

1. Try the repro at Issue [Xamarin.Android.Build.Tasks] build error JavaSourceJar xxxx.stamp not exist #2745:
   a. Create a new Binding project.
   b. Download glide-3.7.0.jar, set its Build action to @(EmbeddedJar).
   c. Download glide-3.7.0-javadoc.jar, set its Build action to @(JavaDocJar)
2. Build the project.

Scratch.Gxa2745.zip

Expected Behavior

The build should use the @(JavaDocJar) file. (Not necessarily "build successfully", but "do something with" the @(JavaDocJar) files.

Actual Behavior

The @(JavaDocJar) file isn't used.

Issue #2745 makes for an interesting comparison point: if the file were used, the build would fail with an MSB3375, unless the underlying bug was fixed (PR #4406?!), which hasn't happened.

Discussion

However, this is a regression introduced by the introduction of JDK 11 support in 380e95e, due to buggy JDK 1.8 detection.

If we build the project, we get binding-related errors:

$ msbuild /v:diag
…
BINDINGSGENERATOR : warning BG8604: top ancestor SupportRequestManagerFragment not found for nested type Com.Bumptech.Glide.Manager.SupportRequestManagerFragment._1.
…
obj/Debug/generated/src/Com.Bumptech.Glide.Load.Resource.Gif.GifResourceEncoder.cs(10,70): error CS0535: 'GifResourceEncoder' does not implement interface member 'IEncoder.
Encode(Object, Stream)' 

Sure, it errors, but at least we got to the point of building the binding!

However, if we "manually work around" the broken JDK 1.8 detection support by setting the $(_JavadocSupported) property to True, we in fact reproduce Issue #2745:

$ msbuild /p:_JavadocSupported=True /v:diag
…
…/Xamarin.Android.Bindings.Documentation.targets(31,5): error MSB3375: The file "obj/Debug/javadocs/glide-3.7.0-javadoc.stamp" does not exist. 

This proves three things:

1. Commit 380e95e broke "out-of-the-box" $(JavaDocJar) support.
2. Issue [Xamarin.Android.Build.Tasks] build error JavaSourceJar xxxx.stamp not exist #2745 has not actually been fixed
3. generator output remains "less-than-ideal"