Java protos are not JDK 1.7-compatible

[cgrushko]

Motivation: Using Java protos in Android.
http://stackoverflow.com/questions/43354237/how-can-you-get-1-7-compatible-output-for-a-java-proto-library

java_xxx_proto_library rules use flags from the (undocumented) java_toolchain.compatible_javacopts attribute.
In particular, it reads the "proto" key from that map.

As far as I can see, Bazel's default java_toolchain is [1], which does not have a compatible_javacopts attribute nor a "proto" key.

@cushon is my analysis correct? is this as easy to fix as adding an compatible_javacopts attribute?

[cushon]

I think @kchodorow's answer is a better approach: http://stackoverflow.com/a/43414404/4297386

compatible_javacopts hacks around a different problem. If the build needs to produce Java 7 compatible output it should be using a Java 7 toolchain, not adding -source 7 -target 7 to individual targets.

[cushon]

This is going to be an issue for Java 8 - I learned that --experimental_desugar_for_android deliberately doesn't desugar proto targets, because it expects them to always be Java 7 compatible. Adding compatible_javacopts is probably still going to be necessary, sorry.

[aj-michael]

I'd like to enable --experimental_desugar_for_android by default. What is the right solution here?
@kevin1e100, can we make desugar run on proto targets?

[aj-michael]

Actually, is this still a problem? I just tried a build with an android_binary > java_library > java_lite_proto_library with incremental dexing and --experimental_desugar_for_android, and it succeeded.

[kevin1e100]

Proto targets can be made subject to desugaring, yes, but doing so will require a Bazel change. Note that generated proto source code is Java 7 compatible (i.e., doesn't use lambdas or other Java 8 features), so it's more efficient to just compile it with -target 7 and skip desugaring. Either solution should work though and should lead to (basically) the same bytecode.

[aj-michael]

If the generated proto source code is Java 7 compatible, then I think DexBuilder will handle it just fine, right? No need to desugar, even if the class file says 52

[kevin1e100]

Not necessarily, it would depend on how exactly the generated source code looks like. Specifically, javac will sometimes emit default methods into version 52 bytecode even if there are no default methods in the source code.