DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0

[cushon]

Bazel's embedded JDK 9 has a bug (JDK-8184940) in its zip implementation which causes it to reject zip files where the modified day or month is 0.

This affects JavaBuilder when processing source jars, and prevents it from compiling archives where the timestamps are normalized to 0. That is the default behaviour of the golang zip implementation and also protoc: https://github.com/protocolbuffers/protobuf/blob/50aa4febaffa6a6f168ec3f9afc6fbdd40e4d31f/src/google/protobuf/compiler/zip_writer.cc#L157

I encountered this trying to compile Android Studio while using the embedded JDK as the default --host_javabase.

The bug is fixed in JDK 10.

Repro: https://gist.github.com/cushon/78820b65fc63760eba475c81f494ca02

bazel build :all
...
Building liblib.jar (1 source jar) failed (Exit 1)
java.time.DateTimeException: Invalid value for MonthOfYear (valid values 1 - 12): 0
        at java.base/java.time.temporal.ValueRange.checkValidValue(Unknown Source)
        at java.base/java.time.temporal.ChronoField.checkValidValue(Unknown Source)
        at java.base/java.time.LocalDate.of(Unknown Source)
        at java.base/java.time.LocalDateTime.of(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipUtils.dosToJavaTime(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.cen(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getEntry(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipPath.getAttributes(Unknown Source)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(Unknown Source)
        at java.base/java.nio.file.Files.readAttributes(Unknown Source)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(Unknown Source)
        at java.base/java.nio.file.FileTreeWalker.visit(Unknown Source)
        at java.base/java.nio.file.FileTreeWalker.next(Unknown Source)
        at java.base/java.nio.file.Files.walkFileTree(Unknown Source)
        at java.base/java.nio.file.Files.walkFileTree(Unknown Source)
        at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.setUpSourceJars(SimpleJavaLibraryBuilder.java:184)
        at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.prepareSourceCompilation(SimpleJavaLibraryBuilder.java:58)
        at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.compileJavaLibrary(SimpleJavaLibraryBuilder.java:98)
        at com.google.devtools.build.buildjar.SimpleJavaLibraryBuilder.run(SimpleJavaLibraryBuilder.java:117)
        at com.google.devtools.build.buildjar.BazelJavaBuilder.processRequest(BazelJavaBuilder.java:105)
        at com.google.devtools.build.buildjar.BazelJavaBuilder.runPersistentWorker(BazelJavaBuilder.java:67)
        at com.google.devtools.build.buildjar.BazelJavaBuilder.main(BazelJavaBuilder.java:45)

[cushon]

I forgot that we fixed protoc in 3.4:

https://github.com/protocolbuffers/protobuf/blob/4426cb573356c5ff710bff8ac8a1170baac7dcf0/src/google/protobuf/compiler/zip_writer.cc#L75

That might downgrade the priority a bit, and it explains why the protos in Bazel itself don't run into this problem. But moving from JDK 9 to 10 (or 11, which is going to be released tomorrow) is still a good idea.

@lberki are there any blockers for that now that cc96464 has landed?

[lberki]

As discussed in private, I'm mostly afraid of doing another possibly-breaking change without a flag.

[cushon]

Update: we're preparing to make JDK 10 the default --host_javabase. The change will be guarded by the flag --incompatible_use_jdk10_as_host_javabase (see 825c049).

[davido]

We are building gerrit like this with JDK 9:

  $ bazel build \
      --host_java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 \
      --java_toolchain=@bazel_tools//tools/jdk:toolchain_java9 \
      :release

And we are building gerrit with JDK 10, with vanilla toolchain:

  $ bazel build --host_javabase=:absolute_javabase \
    --define=ABSOLUTE_JAVABASE=<path-to-java-10> \
    --define=USE_ABSOLUTE_JAVABASE=true \
    --host_java_toolchain=//:toolchain_vanilla \
    --java_toolchain=//:toolchain_vanilla \
    :release

where :toolchain_vanilla is defined as follow:

# TODO(davido): Switch to consuming it from @bazel_tool//tools/jdk:toolchain_vanilla
# when my change is included in released Bazel version:
# https://github.com/bazelbuild/bazel/commit/0bef68e054eccecd690e5d9f46db8a0c4b2d887a
default_java_toolchain(
    name = "toolchain_vanilla",
    forcibly_disable_header_compilation = True,
    javabuilder = ["@bazel_tools//tools/jdk:VanillaJavaBuilder_deploy.jar"],
    jvm_opts = [],
)

How we can build gerrit with JDK 10 from Bazel master using this option --incompatible_use_jdk10_as_host_javabase and avoiding using vanilla toolchain, with full JavaBuilder support (with Error Prone integrations and other stuff)?

Just saying this:

  $ bazel build --incompatible_use_jdk10_as_host_javabase --host_javabase @bazel_tools//tools/jdk:remote_jdk10 java/com/google/gerrit/server:server

works, and Java 10 is downloaded as expected, but the target java version is still 52 (as expected):

  $ javap -verbose -cp bazel-bin/java/com/google/gerrit/server/libserver.jar com.google.gerrit.server.util.LabelVote | grep "major version"
  major version: 52

[cushon]

#6661 will make JDK 10 the default --host_javabase.