Use @argument files in the Java binary wrapper script

[cushon]

The Java binary wrapper script works around command line length limits by creating a jar file with a Class-Path manifest entry containing the long classpath (related: bazelbuild/bazel#6289).

JDK 9 adds support for flag files using the @argument-file syntax, see "java Command-Line Argument Files" in https://docs.oracle.com/javase/9/tools/java.htm.

We should use that instead of the manifest jar hack when targeting JDK 9.

We could back-fill support for that syntax for older --javabase versions by adding logic to the wrapper script.

[petroseskinder]

@cushon will this change resolve the long classpath issue documented in bazelbuild/bazel#6289?
Additionally, is there anything we can do in the ensuing time period to stop the bleeding?

We have ran unused_deps and have removed all obviously unnecessary dependencies.

[cushon]

(previous bug about @argfiles: bazelbuild/bazel#1392)

[cushon]

@petroseskinder I filed this as a reminder to look at @argfiles if/when it's worth adding features that only work for JDK > 9. I think we need a different short-term fix for bazelbuild/bazel#6289.

[petroseskinder]

I see. Thank you. Does the suggestion by @brown suffice for the short term (pre-JDK >9) fix?

[cushon]

I actually didn't realize there was a patch there because github mangled the formatting :/
I left a comment: bazelbuild/bazel#6289 (comment)

[laszlocsomor]

bazelbuild/bazel#6471 was pushed on 2018-10-29, and IIUC it fixed bazelbuild/bazel#6289. According to GitHub this patch is included in Bazel 0.20.0.

@petroseskinder : did this Bazel version "stop the bleeding" with older JDKs?
@cushon : with bazelbuild/bazel#6289 fixed, what's the motivation to resolve this bug, is it just to avoid writing a classpath jar if we can get away with writing an argument file?

[cushon]

what's the motivation to resolve this bug

I don't see any reason to prefer the current approach over @argument files, aside from supporting legacy JDK versions? @argument files are a standard solution to the same problem that probably performs better and won't need maintenance in the future.