Open locke-chappel opened 2 years ago
Thanks for the report. We just added the dependency on jspecify in https://github.com/google/closure-compiler/commit/33bf62ad769c4915c734bcf31387e4fbf972ea8a on July 27, so that seems a likely candidate for when this started.
Since we are one of the early users of the jspecify annotations, I'm not clear if this is an issue with how we are pulling them in or if the annotations themselves are set-up overlooking this particular use-case.
@cpovirk, do you have any idea what the issue here might be?
Hmm, thanks. I'll poke around with your build configuration to see if I can figure out how it's getting pulled in. It would be a little surprising for a built-in rule like java_binary
to be including it, but that's a possibility, or there may be something in the extra Starlark you use to generate your final artifacts.
(The java_binary
target definitely has it. I haven't looked at what might contribute to that, and I likely won't get to the bottom of it before I'm done for the week shortly. But I'll come back to this.)
Thanks Chris!
The
java_binary
target definitely has it.
@cpovirk, by this do you mean that java_binary
already includes a dependency on org.jspecify
and our extra dependency is unnecessary, or that using the java_binary
rule automatically generates these module-info.java
files that are causing issues?
Sorry, the latter, or at least something like that? Building a java_binary with jspecify in the deps results in getting its module-info.class in the deploy jar.
But I'd tried Monday to reproduce that with a smaller example, and it didn't reproduce. So something is going on; I just haven't gotten back to it :(
Sorry again. Finally back. But not having much luck.
It looks to me like module-info.class
shows up in a deploy jar under Bazel (5.3.0) but not under its Google-internal variant. I thought maybe I just needed to supply the right flags to Bazel, but my attempts so far (--java_language_version=11 --java_runtime_version=remotejdk_17 --tool_java_runtime_version=remotejdk_17
) haven't helped.
I'm additionally confused that https://bazel.build/docs/user-manual#java-language-version suggests that the default is Java 11, but I see errors if I try to build a module-info.java
unless I pass --java_language_version=11
or explicitly set javacopts = ["-source 11 -target 11"]
on the target... I think? Updating to 5.3.1 doesn't change anything, and rules_java
appears to already be on the newest version.... But -source 8 -target 8
is getting in as a default from somewhere. I see that even in a fresh workspace I created from scratch. Could the docs simply have gotten ahead of the actual behavior?
Getting back to module-info
: It doesn't appear to matter whether the module-info
comes from sources in the repo, from a jar imported from within the repo, or from a jar from another repo (maybe my terminology is wrong—@org_jspecify_jspecify//:jspecify-0.2.0.jar
, that kind of thing).
Anyway...
It's possible that Bazel could be made to automatically omit module-info
files from deploy jars. (As noted above, I found that it's apparently doing so already inside Google, and I see a similar claim in the description of internal CL 325114973.) However, it's also possible that Bazel won't want to make changes to its existing behavior (since any change could break someone) until they figure out the long-term plan in https://github.com/bazelbuild/bazel/issues/11930.
My suggestion would be to use a genrule
or similar to produce a new jar with the module-info.class
file removed (roughly cp old.jar new.jar && zip -d module-info.class new.jar
).
Thanks for looking into this. I'll also follow along on on https://github.com/bazelbuild/bazel/issues/11930
Since we tend to use bazel and the Google-internal variant interchangeably, any improvements to make them behave the same way for the deploy jars would be a nice improvement.
Hello, has there been any update on this or an ETA?
And thank you very much for looking into it 😄 👍
Starting in v20220803 the release jar now contains an erroneous module-info.class file. Pre-v20220803 releases contain no such file and allow Java to use automatic modules. Starting in v20220803 a module-info.class file in included, seemingly from org.jspecify causing java to recognize the jar as containing only the org.jspecify.nullness package rendering closure-compile unusable in module enabled projects as the downstream project is now unable to specify the appropriate
requires closure.compiler.v20220803;
in it's module-info.java file.Affected Versions
v20220803 and later
Module Description for v20220803 and later
jar --file=closure-compiler-v20220803.jar --describe-module
Module Description for v20220719 and prior
jar --file=closure-compiler-v20220719.jar --describe-module
Edited for better readability