Skip to content

Add support for compile-time input files in java_binary and java_library #245

Description

@brianantony456

Description of the feature request:

Introduce a new attribute, tentatively named java_compiler_inputs, that would specifically hold references to compile-time input files. Additionally, provide support for expanding these file paths using $(location) or similar mechanisms, either within the existing javacopts attribute or a potentially new, toolchain-flag-specific attribute.
Example: Code snippet

java_library(
    name = "dummy_library",
    srcs = ["src/abc.java"],
    java_compiler_inputs = ["compile.properties"],
    javacopts = [
        "-properties",
        "$(location //:compile.properties)",
    ],
) 

Which category does this issue belong to?

java rules

What underlying problem are you trying to solve with this feature?

I am working with a custom Java toolchain (specifically, ECJ https://github.com/salesforce/bazel-jdt-java-toolchain) that supports compile-time options like -properties to consume configuration files during compilation. Currently, there is no dedicated way to provide such files to the Java compiler within Bazel's Java rules. Including these files in the srcs attribute works in some sandbox environments but leads to failures with the processwrapper sandbox.

This feature would improve flexibility when using custom Java toolchains and ensure compatibility across different sandboxing strategies within Bazel. It would be valuable to draw parallels with a similar mechanism already present in Bazel's C++ rules for linker inputs (additional_linker_inputs and user_link_flags).

Which operating system are you running Bazel on?

RHEL7

What is the output of bazel info release?

7.0.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

Discussion on providing -properties file, no answers: salesforce/bazel-jdt-java-toolchain#19

Any other information, logs, or outputs that you want to share?

[Sandbox Error]: with processwrapper sandbox

  exec env - \
    LC_CTYPE=en_US.UTF-8 \
    PATH=/bin:/usr/bin:/usr/local/bin \
  /usr/lib/jvm/java-17/bin/java --module-path external/ecj/ecj.jar -jar external/bazel_jdt_java_toolchain/compiler/export/JdtJavaBuilder_deploy.jar @bazel-out/k8-opt/bin/bin-SystemLoggerApi-class.jar-0.params @bazel-out/k8-opt/bin/dummy_library-class.jar-1.params)
# Configuration: b958e1a85833ddcf110c5efdbae2648181c90445ef232e2d460d4a581e0c3ee6
# Execution platform: //:linux_gcc_x86
Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
properties file compile.properties does not exist

Activity

  1. hvadehra commented on Mar 20, 2024

    @hvadehra
    Member

    We filter out non-.java files from srcs and files with the .properties extension are specially handled as resources. The problem here seems to be that we create a separate jar for resources and aren't on the classpath, so those aren't available as inputs to the compile action. This explains why things work with local execution. I'm surprised that it works for you with linux-sandbox, I would expect it to fail there as well.

    From what I can tell, ECJ doesn't care about the file extension and parses it as a properties file no matter what. Horrible workaround for now would be to name the file as foo.jar and add it to the deps attribute. This should have it on the classpath and in the inputs to the action, so javacopts = ["-properties $(location foo.jar)"] will work with sandboxing as well. Although that being said, .jar files in deps is legacy and should be avoided.

    I'm keeping this open as the spirit of this FR sounds reasonable to me and will revisit this soon.

  2. added
    P2We'll consider to work on this in future. (Assignee optional)
    on Mar 20, 2024
  3. hvadehra commented on Nov 29, 2024

    @hvadehra
    Member

    (moving this to rules_java, as the rules now live there)

  4. transferred this issue frombazelbuild/bazelon Nov 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2We'll consider to work on this in future. (Assignee optional)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions