Salesforce Spring Rules for Bazel

In Bazel, setting neverlink = True on a java_library specifies that the library should be used for compilation purposes but should not be included in the runtime classpath.

This is useful when the library is provided by the runtime environment (e.g., tools.jar in a standard JDK or IDE APIs for plugins).

Important Considerations:

• Inlining: Setting neverlink = True does not prevent the Java compiler from inlining material (like static final constants of String or primitive types) into dependent compilation targets.
• Compatibility: The preferred use case is when the runtime library is identical to the compilation library. If the runtime library differs from the compilation library, you must ensure they only differ in ways that the Java Language Specification (JLS) forbids compilers from inlining.

java_library(
    name = "lib3_neverlink",
    neverlink = True,
    ...
)

The behavior of the rule depends on which dependencies are included in the deps_to_exclude_transitives list:

1. Exclude all transitives for all listed deps: If deps_to_exclude_transitives contains all items in deps, only the direct dependencies are included; their transitives are removed.
2. Partial exclusion: If deps_to_exclude_transitives only contains a subset of deps, only those specific dependencies will have their transitives excluded. Other dependencies in deps will retain their transitive dependencies.
3. No exclusion: If deps_to_exclude_transitives is omitted, all dependencies in deps and runtime_deps will include their transitive dependencies as normal.

### Example 1: Exclude all transitives for both deps
deps_filter_disable_transitives(
    name = "filtered_deps_disable_transitives_case_A",
    deps = [
        "@maven//:org_springframework_spring_jdbc",
        "@maven//:org_springframework_spring_web",
    ],
    deps_to_exclude_transitives = [
        "@maven//:org_springframework_spring_jdbc",
        "@maven//:org_springframework_spring_web",
    ],
)

### Example 2: Exclude transitives for only one dep
deps_filter_disable_transitives(
    name = "filtered_deps_disable_transitives_case_A",
    deps = [
        "@maven//:org_springframework_spring_jdbc",
        "@maven//:org_springframework_spring_web",
    ],
    deps_to_exclude_transitives = [
        "@maven//:org_springframework_spring_web",
    ],
)

### Example 3: No exclusions (standard behavior)
deps_filter_disable_transitives(
    name = "filtered_deps_disable_transitives_case_A",
    deps = [
        "@maven//:org_springframework_spring_jdbc",
        "@maven//:org_springframework_spring_web",
    ],
)

If you cannot remove a dependency, you can influence which version of a duplicate class 'wins' by controlling the classpath order. In a Spring Boot executable jar, the order of entries determines which class is loaded first by the JVM.

Method 1: BUILD file dependency order

Spring Boot writes dependencies into the jar based on Bazel's depset order, which is influenced by the order in your deps list. Earlier entries in the deps list are generally loaded first.

Note: If you encounter errors with very large dependency sets (command line length limits), you can disable this ordering behavior by setting deps_use_starlark_order = False in the springboot rule.

To verify the order in your jar, use: jar -tvf {springboot_jar_name}.

Method 2: Spring Boot Classpath Index

You can provide a deps_index_file to the springboot rule to instruct the Spring Boot loader to load specific jars in a specific order.

⚠️ Caveat: This only works if you explode the executable jar and invoke the JarLauncher manually:

jar -xf helloworld.jar
java org.springframework.boot.loader.JarLauncher

springboot(
    name = "helloworld",
    boot_app_class = "com.sample.SampleMain",
    java_library = ":helloworld_lib",

    # if you have conflicting classes in dependency jar files, you can define the order in which the jars are loaded
    deps_index_file = "helloworld_classpath.idx",
)

The deps_filter rule allows you to filter Java dependencies in Bazel projects. It is used to remove specific JARs or dependencies from the compile-time and runtime dependency graphs. This is particularly useful for:

• Excluding dependencies with known vulnerabilities.
• Resolving classpath conflicts (e.g., duplicate classes) by excluding unfavored versions.
• Managing complex classpaths in Spring Boot applications.

To use it, you define a deps_filter target and then reference that target in the deps or runtime_deps attribute of your java_library or other Java targets instead of the original dependency list.

load("@rules_spring//springboot/deps_filter_rules_legacy:deps_filter.bzl", "deps_filter")

deps_filter(
    name = "filtered_deps",
    deps = ["@maven//:some_dep"],
    deps_exclude_labels = ["@maven//:unwanted_dep"],
)

java_library(
    name = "my_library",
    deps = [":filtered_deps"],
)

When you run a springboot target, Bazel executes a 'wrapper script' that coordinates the launch. You can find these scripts in bazel-bin/ under your target's path. For a target //examples/demoapp:demoapp, the components are:

• Wrapper script (bazel-bin/examples/demoapp/demoapp): A shell script (without a .sh extension) that coordinates the launch. It is generated from the *_bazelrun_script_template in springboot.bzl.
• Env script (bazel-bin/examples/demoapp/demoapp_bazelrun_env.sh): Contains environment variables, including those from bazelrun_data and bazelrun_env_flag_list.
• Launcher script (bazel-bin/examples/demoapp/demoapp.runfiles/_main/springboot/default_bazelrun_script.sh): The script that actually executes the java -jar command. This is the script you replace if using bazelrun_script.

# Direct invocation of the wrapper script for troubleshooting
./bazel-bin/examples/demoapp/demoapp