bazel-contrib / bazel-contrib/rules_scala

Do not provide default_javac_opts for `java_common.compile`

Open
#1,685 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Starlark
Stars
384
Forks
292
Avg merge
2d 21h
Merged PRs (30d)
46

Description

I've noticed a very odd thing where the javacopts are **duplicated** if any `javacopts` are provided for a `scala_library`.
**This only affects if there are Java files in the target**

Looking at the code, I can see that the `default_javac_opts` are being provided to the compile method (https://github.com/bazelbuild/rules_scala/blob/a8ae50ef8c6f9b4bf551e9d6ccf0b796dd07539d/scala/private/rule_impls.bzl#L160)

I can confirm this by looking at the _params_ file (_bazel-out/k8-fastbuild/bin/liba_java.jar-0.params_)
) created for each JAR and I notice that the default javacopts are duplicated.

**example**

I created a `scala_library`
```starlark
scala_library(
name = "liba",
srcs = [
"LibraryA.scala",
"LibraryB.java",
],
javacopts = [
"--release 21",
],
)
```

You can see the duplicate here.
```
--javacopts
-source
17
-target
17
-XDskipDuplicateBridges=true
-XDcompilePolicy=simple
--should-stop=ifError=FLOW
-g
-parameters
-Xep:ReturnValueIgnored:OFF
-Xep:IgnoredPureGetter:OFF
-Xep:EmptyTopLevelDeclaration:OFF
-Xep:LenientFormatStringValidation:OFF
-Xep:ReturnMissingNullable:OFF
-Xep:UseCorrectAssertInTests:OFF
--release
21
-source
17
-target
17
-XDskipDuplicateBridges=true
-XDcompilePolicy=simple
--should-stop=ifError=FLOW
-g
-parameters
-Xep:ReturnValueIgnored:OFF
-Xep:IgnoredPureGetter:OFF
-Xep:EmptyTopLevelDeclaration:OFF
-Xep:LenientFormatStringValidation:OFF
-Xep:ReturnMissingNullable:OFF
-Xep:UseCorrectAssertInTests:OFF
```

If I remove the `javacopts` from the `scala_library` we get (_notice no duplicate_)
```starlark
scala_library(
name = "liba",
srcs = [
"LibraryA.scala",
"LibraryB.java",
],
javacopts = [
],
)
```

```
--javacopts
-source
17
-target
17
-XDskipDuplicateBridges=true
-XDcompilePolicy=simple
--should-stop=ifError=FLOW
-g
-parameters
-Xep:ReturnValueIgnored:OFF
-Xep:IgnoredPureGetter:OFF
-Xep:EmptyTopLevelDeclaration:OFF
-Xep:LenientFormatStringValidation:OFF
-Xep:ReturnMissingNullable:OFF
-Xep:UseCorrectAssertInTests:OFF
```

How I am very stumped, is that given the code I linked, I would expect the duplicate javacopts to _always be duplicated_, yet if the list is empty, it's only present once.

> I suspect this has something to do with depsets and strings but I'm not sure quite yet. 🤷

I've fixed it locally by removing the default inclusion. I think that's a worthwhile fix but I would sure love to understand what's causing this. `java_library` doesn't suffer from the same symptom but it's calling into the same code in `rules_java`.

**Why is this all a problem?**
By duplicating the default javacopts, we are having trouble overwriting toolchain values.

I think there is some similarity to https://github.com/bazelbuild/rules_scala/issues/1550 but the duplication seems to be new/different.

Contributor guide

Open the contributing guide

Research direction

Start at scala/private/rule_impls.bzl around line 160 and reproduce the issue with a scala_library containing both Scala and Java sources plus javacopts. Compare the generated liba_java.jar-0.params file with and without javacopts; done means the default javacopts appear only once and toolchain values can be overridden.

Written by the indexing model from the issue text.

Assessment

Tech stack
java, scala
Domain
build-system
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
49/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.