You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bazel includes the ijar tool, which strips regular JAR files down to their interfaces. Target hashes are computed based on the resulting ijars, ensuring that only the necessary targets are rebuilt when changes do not affect public interfaces (e.g., modifications to implementations or private method signatures).
However, this approach often falls short in practice. For Scala 2, as noted in this issue, scalac adds a ScalaSignature annotation to classes, causing cache misses and unnecessary rebuilds.
For Scala 3, ijar generation is explicitly disabled.
Is the situation with ijars similar for Scala 3?
If ijars are not a viable solution, would analyzing TASTy files for interface-level changes be a feasible alternative?
The text was updated successfully, but these errors were encountered:
I agree that it would be great to improve ijar support for Scala or to use some other mechanism to improve detection of interface vs private implementation changes.
We have a discussion started in #1658 that includes a proposal for ijar (as well as many other things). Our current thoughts are to improve the ijar tool to be more Scala aware. If the Bazel folks are not interested in that, then we could explore other alternatives - perhaps there is some way to leverage the Zinc analysis file to accomplish this? Haven't thought much through that.
Bazel includes the ijar tool, which strips regular JAR files down to their interfaces. Target hashes are computed based on the resulting ijars, ensuring that only the necessary targets are rebuilt when changes do not affect public interfaces (e.g., modifications to implementations or private method signatures).
However, this approach often falls short in practice. For Scala 2, as noted in this issue, scalac adds a ScalaSignature annotation to classes, causing cache misses and unnecessary rebuilds.
For Scala 3, ijar generation is explicitly disabled.
Is the situation with ijars similar for Scala 3?
If ijars are not a viable solution, would analyzing TASTy files for interface-level changes be a feasible alternative?
The text was updated successfully, but these errors were encountered: