Upgrade OpenSUSE Java version in CI workflow to 25#77
Conversation
📝 WalkthroughWalkthroughBazel now targets Java 25 and registers ChangesJava 25 toolchain configuration
Platform Java package alignment
Estimated code review effort: 2 (Simple) | ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/ci.yml (1)
619-619: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick winPin these workflow actions to commit SHAs.
actions/checkout@v7,actions/cache@v6, andactions/setup-java@v5are mutable tags; replace them with full commit SHAs and keep the version in a comment if needed. This applies to the remaininguses:entries in.github/workflows/ci.ymlthat still reference major tags.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml at line 619, Update every remaining major-tagged uses entry in the workflow, including actions/cache@v6, actions/checkout@v7, and actions/setup-java@v5, to use its full immutable commit SHA; preserve the referenced action version in an inline comment where useful.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/ci.yml:
- Line 619: Update every remaining major-tagged uses entry in the workflow,
including actions/cache@v6, actions/checkout@v7, and actions/setup-java@v5, to
use its full immutable commit SHA; preserve the referenced action version in an
inline comment where useful.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 9b4d41e3-da60-4734-a5a2-cfd312ec1b34
📒 Files selected for processing (1)
.github/workflows/ci.yml
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@MODULE.bazel`:
- Around line 42-60: Update the Bazel runtime selector settings in .bazelrc to
use remotejdk_25 instead of remotejdk_21 for both runtime selectors, while
preserving --java_language_version=21 and --tool_java_language_version=21.
- Around line 50-51: Update the Windows JDK repository references in
MODULE.bazel from remotejdk25_windows and remotejdk25_windows_arm64 to the
rules_java 9.7.0 names remotejdk25_win and remotejdk25_win_arm64, including both
use_repo and register_toolchains declarations.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: eb835393-bf35-45f9-b075-069f4b042601
📒 Files selected for processing (2)
.github/workflows/ci.ymlMODULE.bazel
fd3d70e to
e5ffe7d
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
MODULE.bazel (1)
43-62: 🎯 Functional Correctness | 🟠 MajorUpdate the Bazel runtime selectors to activate JDK 25.
.bazelrc:531-533still selectsremotejdk_21for both runtime flags, so these newly registeredremotejdk25_*toolchains will not be selected. Change both selectors toremotejdk_25; retain the language version 21 if source compatibility is intentional.This repeats the prior review finding, but the supplied current cross-file context still shows it unresolved.
Proposed selector update
-common --java_runtime_version=remotejdk_21 +common --java_runtime_version=remotejdk_25 common --tool_java_language_version=21 -common --tool_java_runtime_version=remotejdk_21 +common --tool_java_runtime_version=remotejdk_25🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@MODULE.bazel` around lines 43 - 62, Update both Bazel runtime selectors in the relevant configuration from remotejdk_21 to remotejdk_25 so they select the newly registered JDK 25 toolchains, while retaining the language version 21 setting.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@MODULE.bazel`:
- Around line 43-62: Update both Bazel runtime selectors in the relevant
configuration from remotejdk_21 to remotejdk_25 so they select the newly
registered JDK 25 toolchains, while retaining the language version 21 setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 3ca970eb-3794-4748-8970-6b622101ba50
📒 Files selected for processing (2)
.github/workflows/ci.ymlMODULE.bazel
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CMakeLists.txt`:
- Line 160: Update the RPM runtime dependency configuration in CMakeLists.txt so
the java-headless requirement specifies Java 25 instead of Java 21, while
preserving the existing dependency format and other package requirements.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 7bab9d07-fdb3-43b4-a49d-f95f51de2178
📒 Files selected for processing (6)
.bazelrc.github/workflows/ci.ymlCMakeLists.txtDockerfileMODULE.bazelQUALITY_DECLARATION.md
There was a problem hiding this comment.
♻️ Duplicate comments (1)
CMakeLists.txt (1)
160-168: 🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick winRaise the RPM runtime requirement to Java 25.
The FreeBSD dependency and CMake compiler requirement now target Java 25, but Line [168] still emits
java-headless >= 1:21. RPM installation can therefore succeed on a Java 21-only system, followed by a runtime failure for the Java 25 bytecode. (raw.githubusercontent.com)Proposed fix
-set(CPACK_RPM_PACKAGE_REQUIRES "apache-commons-math >= 3.6.1, java-headless >= 1:21") +set(CPACK_RPM_PACKAGE_REQUIRES "apache-commons-math >= 3.6.1, java-headless >= 1:25")🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@CMakeLists.txt` around lines 160 - 168, Update CPACK_RPM_PACKAGE_REQUIRES to require java-headless >= 1:25 instead of 1:21, while preserving the existing apache-commons-math dependency.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Duplicate comments:
In `@CMakeLists.txt`:
- Around line 160-168: Update CPACK_RPM_PACKAGE_REQUIRES to require
java-headless >= 1:25 instead of 1:21, while preserving the existing
apache-commons-math dependency.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 29029dea-92d0-4655-9668-af0bed6b0d1d
📒 Files selected for processing (6)
.bazelrc.github/workflows/ci.ymlCMakeLists.txtDockerfileMODULE.bazelQUALITY_DECLARATION.md
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CMakeLists.txt`:
- Around line 160-168: Add the Java 25 runtime dependency to CPack’s Debian
metadata via CPACK_DEBIAN_PACKAGE_DEPENDS, preserving the existing
libcommons-math3-java dependency and matching the runtime requirement used by
the build and other package formats.
In `@MODULE.bazel`:
- Around line 45-61: Update the MODULE.bazel use_repo and register_toolchains
declarations for the remotejdk25 repositories to also include each generated
*_toolchain_config_repo repository. Register those config repos alongside the
existing runtime repos so the remotejdk_25 selectors resolve the Java toolchains
provided by rules_java.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 47d7d82e-6c28-49fc-a635-dfbf79f1e060
📒 Files selected for processing (6)
.bazelrc.github/workflows/ci.ymlCMakeLists.txtDockerfileMODULE.bazelQUALITY_DECLARATION.md
| use_repo( | ||
| toolchains, | ||
| "remotejdk25_linux", | ||
| "remotejdk25_linux_aarch64", | ||
| "remotejdk25_macos", | ||
| "remotejdk25_macos_aarch64", | ||
| "remotejdk25_win", | ||
| "remotejdk25_win_arm64", | ||
| ) | ||
|
|
||
| register_toolchains( | ||
| "@remotejdk25_linux//:all", | ||
| "@remotejdk25_linux_aarch64//:all", | ||
| "@remotejdk25_macos//:all", | ||
| "@remotejdk25_macos_aarch64//:all", | ||
| "@remotejdk25_win//:all", | ||
| "@remotejdk25_win_arm64//:all", |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
for repo in remotejdk25_linux remotejdk25_linux_aarch64 \
remotejdk25_macos remotejdk25_macos_aarch64 \
remotejdk25_win remotejdk25_win_arm64; do
grep -Fq "\"${repo}_toolchain_config_repo\"" MODULE.bazel
grep -Fq "\"@${repo}_toolchain_config_repo//:all\"" MODULE.bazel
doneRepository: snape/RVO2-Java
Length of output: 153
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "== MODULE.bazel =="
nl -ba MODULE.bazel | sed -n '1,140p'
echo
echo "== Search for remotejdk25 and toolchain_config_repo references =="
rg -n 'remotejdk25|toolchain_config_repo|remote_java_repository|register_toolchains|use_repo' -S .Repository: snape/RVO2-Java
Length of output: 212
🌐 Web query:
rules_java 9.7.0 remote_java_repository toolchain_config_repo use_repo register_toolchains remotejdk25
💡 Result:
In rules_java 9.7.0, the integration of remote JDKs—including remotejdk25—is managed via the Bzlmod extension system [1][2][3]. To configure these repositories in your MODULE.bazel file, you use the toolchains extension provided by rules_java [2][4]. The following pattern is the standard approach used by the module to declare and register remote JDK toolchains [2][5]: 1. Load the extension: toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains") 2. Use the repository: You must declare the specific remote JDK repository and its corresponding toolchain configuration repository [2][5]. For remotejdk25, this involves: use_repo(toolchains, "remotejdk25_linux", "remotejdk25_linux_toolchain_config_repo") # Example for linux 3. Register the toolchain: After importing the repositories, you register the toolchain configuration [2][5]: register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") In rules_java 9.7.0, the module internally defines a map (JDKS) that tracks supported platforms for various JDK versions, including 25 [2]. The naming convention for these repositories generally follows the pattern remotejdk{version}_{platform} and their corresponding toolchain configuration repositories are suffixed with _toolchain_config_repo [2][5]. If you are using the full suite of toolchains provided by rules_java, you can observe this logic dynamically handled in the module's own MODULE.bazel, which iterates over defined JDK versions and platforms to perform these use_repo and register_toolchains calls automatically [2][5]. If you only need a specific JDK, you can manually select the relevant repos as shown above [6][7].
Citations:
- 1: https://registry.bazel.build/modules/rules_java/9.7.0
- 2: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 3: bazelbuild/bazel-central-registry@9ee986b
- 4: https://pigweed.googlesource.com/third_party/github/bazelbuild/rules_java/+/refs/tags/9.0.3/MODULE.bazel
- 5: https://bazel.googlesource.com/rules_java/+/3cbc18e8e874b4d1d017d5e8b862d35624088b60/MODULE.bazel
- 6: https://bazel.build/docs/bazel-and-java
- 7: Difficult to override remote JDKs when using Bzlmod bazelbuild/rules_java#222
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
rg -n 'remotejdk|toolchain_config_repo|register_toolchains|use_repo|remote_java_repository' -S MODULE.bazel .bazelrc .bazelversion .bazelrc* 2>/dev/null || trueRepository: snape/RVO2-Java
Length of output: 1135
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
nl -ba MODULE.bazel | sed -n '35,70p'Repository: snape/RVO2-Java
Length of output: 193
🌐 Web query:
rules_java bzlmod remote_java_repository use_repo register_toolchains remotejdk25_toolchain_config_repo
💡 Result:
In Bazel with Bzlmod, the standard way to configure remote Java toolchains—including remotejdk25—is through the toolchains module extension provided by rules_java [1][2]. You do not typically need to manually call remote_java_repository in your own MODULE.bazel file, as the extension handles the declaration and registration of these repositories automatically [3]. 1. Default Configuration When you declare a dependency on rules_java in your MODULE.bazel file, the extension automatically defines the necessary repositories and registers the toolchains for supported JDK versions (including JDK 25) [1][3][2]. You can access these in your build by using the appropriate --java_runtime_version flag (e.g., --java_runtime_version=25). 2. How to Use use_repo and register_toolchains If you need to explicitly reference a remote JDK toolchain (e.g., to override it or use it in a specific build target), you follow these steps in your MODULE.bazel: First, retrieve the toolchains extension from rules_java: toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains") Next, use use_repo to import the specific repository and its associated toolchain configuration repository. For a JDK 25 remote repository (e.g., remotejdk25_linux), the pattern typically includes the repository itself and a _toolchain_config_repo suffix: use_repo(toolchains, "remotejdk25_linux", "remotejdk25_linux_toolchain_config_repo") Finally, register the toolchain using the config repository: register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") Note that the repository names and architecture suffixes (like _linux, _macos, _win) must match those defined by the rules_java extension [1][2]. You can verify available toolchains by examining the rules_java MODULE.bazel source or by listing registered toolchains using bazel query [1][4][2]. If you are attempting to define a custom remote JDK, you would define your own module extension that calls remote_java_repository [5][6]. However, for standard remotejdk25 usage, the built-in rules_java mechanism is the recommended and preferred approach [3].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/8.11.0/MODULE.bazel
- 3: Migrate remote JDK / Java tools and add Bzlmod support bazelbuild/rules_java#45
- 4: https://bazel.build/extending/toolchains
- 5: https://bazel.build/docs/bazel-and-java
- 6: Difficult to override remote JDKs when using Bzlmod bazelbuild/rules_java#222
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
echo "== MODULE.bazel (excerpt) =="
sed -n '1,120p' MODULE.bazel
echo
echo "== Extension and toolchain wiring =="
grep -nE 'use_extension|toolchains =|use_repo\(|register_toolchains\(' MODULE.bazelRepository: snape/RVO2-Java
Length of output: 3217
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
p = Path("MODULE.bazel")
for i, line in enumerate(p.read_text().splitlines(), 1):
if i <= 120:
print(f"{i:3}: {line}")
PY
printf '\n== Search for rules_java extension usage ==\n'
python3 - <<'PY'
from pathlib import Path
text = Path("MODULE.bazel").read_text().splitlines()
for i, line in enumerate(text, 1):
if 'use_extension' in line or 'use_repo(' in line or 'register_toolchains(' in line:
print(f"{i}: {line}")
PYRepository: snape/RVO2-Java
Length of output: 3668
🌐 Web query:
site:github.com bazelbuild/rules_java MODULE.bazel remotejdk25_linux_toolchain_config_repo register_toolchains "@remotejdk25_linux_toolchain_config_repo//:all"
💡 Result:
The command snippet you referenced relates to how remote Java Development Kit (JDK) toolchains are registered in Bazel projects using rules_java and Bzlmod [1][2]. In rules_java, remote JDKs are configured via toolchain repositories [1][3]. The pattern remotejdk<version>_<platform>_toolchain_config_repo refers to the repository containing the configuration for a specific remote JDK toolchain [1][2]. The command register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") is used in a MODULE.bazel file to register all available toolchains within that specific configuration repository [1][2]. In modern versions of rules_java (such as those supporting JDK 25), this is typically handled automatically or via loop constructs within the MODULE.bazel file, rather than by manually registering every individual repository [1][4][2]. For example, rules_java modules include logic to iterate over defined JDK versions and platforms, automatically fetching the necessary toolchain repositories and registering them [1][5][2]: [use_repo( toolchains, repo + "_toolchain_config_repo",) for repo in REMOTE_JDK_REPOS] [register_toolchains("@" + name + "_toolchain_config_repo//:all") for name in REMOTE_JDK_REPOS] If you are manually registering a specific toolchain, ensure that you have first imported the repository using use_repo from the rules_java toolchains extension [4][2]. If you are experiencing issues with toolchain precedence (e.g., Bazel downloading remote JDKs when you intended to use a local JDK), note that rules_java registers remote toolchains by default, which may take precedence over local ones depending on your configuration [6]. You can override this behavior by explicitly registering your local toolchain or using flags like --tool_java_runtime_version=local_jdk [6].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: bazelbuild/bazel-central-registry@49600cc
- 3: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
- 4: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/8.11.0/MODULE.bazel
- 5: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/7.12.5/MODULE.bazel
- 6: How to prevent bazel from downloading JDK11 and JDK21? bazelbuild/bazel#21752
🌐 Web query:
"bazelbuild/rules_java" "remotejdk25_linux_toolchain_config_repo" MODULE.bazel
💡 Result:
The remotejdk25_linux_toolchain_config_repo is a repository target generated by the rules_java Bazel module to support Java 25 toolchains on Linux [1][2]. In the context of the MODULE.bazel file for projects using rules_java, you typically do not declare these specific repositories manually. Instead, they are handled automatically by the extension provided by the module. ### How to use it To access remote JDK 25 toolchains in your project, follow this pattern in your MODULE.bazel file: 1. Add the rules_java dependency. 2. Use the toolchains extension to load the necessary repositories and register the toolchains [1][2]. The rules_java module uses a programmatic approach to declare and register these toolchains [1][2]: python # Declare the toolchains extension toolchains = use_extension("`@rules_java//java`:extensions.bzl", "toolchains") # This automatically loads remotejdk25_linux_toolchain_config_repo (and others) use_repo( toolchains, "remotejdk25_linux_toolchain_config_repo", # ... other required repos ) # Register the toolchains register_toolchains("`@remotejdk25_linux_toolchain_config_repo//`:all") ### Context and Implementation * Purpose: This repository contains the toolchain configuration required by Bazel to use a remote JDK 25 on Linux platforms [3]. * Automation: The rules_java MODULE.bazel file defines a JDKS dictionary and a REMOTE_JDK_REPOS list comprehension that dynamically generates the names (like remotejdk25_linux_toolchain_config_repo) and registers them [1][2]. * Availability: Support for JDK 25 was added to rules_java to facilitate builds for Bazel 9 and newer [4]. If you are not seeing the repository available, ensure you are using a sufficiently recent version of rules_java [5]. If you are trying to register all remote JDK toolchains at once as the official rules_java MODULE.bazel does, it uses this pattern [1][2]: python # Example of how rules_java registers all configured remote JDKs [register_toolchains("@" + name + "_toolchain_config_repo//:all") for name in REMOTE_JDK_REPOS]
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: https://pigweed.googlesource.com/third_party/github/bazelbuild/rules_java/+/refs/tags/9.0.3/MODULE.bazel
- 3: https://bazel.googlesource.com/bazel/+/refs/tags/6.0.0-pre.20220405.2/tools/jdk/remote_java_repository.bzl
- 4: Add remote JDK 25 for riscv64, ppc64le and s390x bazelbuild/rules_java#347
- 5: https://registry.bazel.build/modules/rules_java
🌐 Web query:
rules_java remote_java_repository.bzl toolchain_config_repo "register_toolchains" "remotejdk25_linux"
💡 Result:
In Bazel, remote_java_repository is a repository rule used to download and register a Java Runtime (JDK) from a remote URL, making it available as a toolchain [1][2]. The toolchain_config_repo component is automatically generated by this rule to provide the necessary toolchain definitions for Bazel to use the downloaded JDK [1]. When configuring these repositories, particularly for remotejdk25_linux, the pattern typically involves defining the repository and then registering the resulting toolchain [3][4]. Usage Pattern 1. Repository Definition: You can define a remote JDK repository by providing the necessary URLs, SHA256 checksums, and platform compatibility constraints (target_compatible_with) [1][2]. In modern Bazel projects using Bzlmod, this is often handled via the java_repository extension in MODULE.bazel [2]. 2. Toolchain Registration: After the repository rule (like remote_java_repository) creates the repository, it generates a sub-repository named _toolchain_config_repo [1]. You must register the toolchain contained within this sub-repository to make it available to your build [3][1]. Example Registration If you have defined a repository named remotejdk25_linux, the associated toolchain config repository is named remotejdk25_linux_toolchain_config_repo [1]. You register it in your WORKSPACE file (or via MODULE.bazel) as follows [3][5]: native.register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") Or simply: register_toolchains("@remotejdk25_linux_toolchain_config_repo//:toolchain") Key Points: - Automatic Config: The remote_java_repository rule automatically creates the _toolchain_config_repo, which contains the toolchain declaration [1]. - Toolchain Resolution: Bazel uses the target_compatible_with and the --java_runtime_version flag to select the correct toolchain from those registered [1][2]. - Bzlmod vs WORKSPACE: While older configurations used the WORKSPACE file directly, modern Bazel usage recommends using module extensions (e.g., use_extension("@rules_java//java:extensions.bzl", "java_repository")) to manage these JDK dependencies [2]. The rules_java repository maintains lists of these configurations for various JDK versions, including JDK 25 [3][6].
Citations:
- 1: https://bazel.googlesource.com/bazel/+/refs/tags/6.0.0-pre.20220405.2/tools/jdk/remote_java_repository.bzl
- 2: https://bazel.build/docs/bazel-and-java
- 3: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
- 4: https://pigweed.googlesource.com/third_party/github/bazelbuild/rules_java/+/refs/tags/8.8.0/java/repositories.bzl
- 5: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/8.11.0/MODULE.bazel
- 6: bazelbuild/rules_java@d2d7258
🌐 Web query:
site:github.com/bazelbuild/rules_java MODULE.bazel "register_toolchains(" "remotejdk25" "_toolchain_config_repo"
💡 Result:
In the context of the rules_java Bazel module (Bzlmod), you generally do not need to manually call register_toolchains for individual remote JDKs [1]. Instead, the rules_java module extension handles this automatically [2][1]. When you depend on rules_java in your MODULE.bazel, the module extension is responsible for importing the necessary remote JDK repositories and registering their corresponding toolchains [2][1]. If you are following the standard implementation in the rules_java repository, the toolchains are registered automatically via a list comprehension in the project's own MODULE.bazel file [2]: [register_toolchains("@" + name + "toolchain_config_repo//:all") for name in REMOTE_JDK_REPOS] This uses the REMOTE_JDK_REPOS list, which dynamically generates names based on the supported JDK versions (including 25) and platforms [2]. If you are attempting to register these toolchains in your own project: 1. Ensure you have the rules_java dependency configured in your MODULE.bazel. 2. In most cases, simply depending on rules_java is sufficient to make these toolchains available [1]. 3. If you find you must manually register them, ensure you are targeting the correct toolchain targets (e.g., //:all or //:toolchain) within the toolchain configuration repository, following the naming pattern: @remotejdk_toolchain_config_repo [2][3]. For further details on how rules_java manages these toolchains, you can refer to the official rules_java repository's MODULE.bazel and java/repositories.bzl files [2][3].
Citations:
- 1: Migrate remote JDK / Java tools and add Bzlmod support bazelbuild/rules_java#45
- 2: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 3: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
🌐 Web query:
"bazelbuild/rules_java" "remotejdk25_linux//:all" register_toolchains
💡 Result:
In the context of the bazelbuild/rules_java repository, the expression remotejdk25_linux//:all refers to a generated repository containing the toolchain configuration for a remote OpenJDK 25 environment on Linux [1][2]. ### Registering Toolchains When using rules_java with Bzlmod (the recommended dependency management system for modern Bazel projects), the toolchains for remote JDKs, including JDK 25, are typically registered automatically by the rules_java module extension [1][2]. In the MODULE.bazel file of rules_java, this is handled programmatically: 1. A JDKS dictionary defines the supported versions (including "25") and their corresponding platforms [1][2]. 2. The extension iterates through these, generating the necessary repository names (e.g., remotejdk25_linux) and their associated toolchain configuration repositories (e.g., remotejdk25_linux_toolchain_config_repo) [1][2]. 3. These toolchain configurations are then registered using register_toolchains("@" + name + "_toolchain_config_repo//:all") [1][2]. ### Manual Registration If you are defining custom toolchains or need to register specific JDK toolchains manually, you can use the register_toolchains() function in your root MODULE.bazel or WORKSPACE file [3][4]. For example, to register the remote JDK 25 toolchain configuration for Linux, you would typically point to the _toolchain_config_repo repository generated by rules_java [1][5]: register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") ### Key Concepts * Toolchain Resolution: Bazel uses toolchain resolution to select the appropriate JDK based on your project's platform constraints and command-line flags (like --java_runtime_version) [6][7][8]. * Remote JDKs: rules_java provides these remote repositories to ensure hermetic builds, allowing you to specify the exact JDK version used for compilation and execution without relying on locally installed Java environments [9][10]. * Generated Repositories: The remotejdk25_linux repository itself is an HTTP repository containing the JDK binaries, while the _toolchain_config_repo suffix indicates the repository containing the actual toolchain() definitions that Bazel requires for registration [1][8]. For most users, manually registering these toolchains is unnecessary if you have properly declared rules_java as a dependency in your MODULE.bazel file, as the module extension handles the registration of all included JDK toolchains automatically [1][2][5].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: https://pigweed.googlesource.com/third_party/github/bazelbuild/rules_java/+/refs/tags/9.0.3/MODULE.bazel
- 3: https://bazel.build/extending/toolchains
- 4: https://bazel.googlesource.com/bazel/+/staging/site/docs/toolchains.md?autodive=0%2F
- 5: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
- 6: https://bazel.build/versions/7.4.0/docs/bazel-and-java
- 7: incompatible_use_toolchain_resolution_for_java_rules: use toolchain resolution for Java rules bazelbuild/bazel#7849
- 8: https://bazel.googlesource.com/bazel/+/refs/tags/6.0.0-pre.20220405.2/tools/jdk/remote_java_repository.bzl
- 9: https://bazel.build/docs/bazel-and-java
- 10: https://bazel.build/versions/9.2.0/docs/bazel-and-java
🌐 Web query:
"toolchains = use_extension(\"@rules_java//java:extensions.bzl\", \"toolchains\")" remotejdk25 use_repo register_toolchains
💡 Result:
The snippet provided relates to the configuration of Java toolchains in a Bazel project using Bzlmod [1]. When using rules_java, the toolchains module extension is used to load remote JDK repositories, which are then registered as toolchains [2][3]. In a MODULE.bazel file, this typically looks like the following pattern: toolchains = use_extension("@rules_java//java:extensions.bzl", "toolchains") use_repo(toolchains, "remotejdk25_linux_x86_64", "remotejdk25_linux_x86_64_toolchain_config_repo") register_toolchains("@remotejdk25_linux_x86_64_toolchain_config_repo//:all") Explanation of components: 1. use_extension: Loads the toolchains extension from rules_java to make remote JDK repositories available [2][3]. 2. use_repo: Imports the specific remote JDK repository (e.g., remotejdk25 for a specific platform) and its associated toolchain configuration repository [2][3]. Rules_java generally provides a separate repository ending in _toolchain_config_repo that contains the actual toolchain definition [2][3]. 3. register_toolchains: Informs Bazel about the toolchain definitions available in the specified repository [4][5]. The:all target pattern is commonly used to register all toolchain definitions within that configuration repository [2][6][3]. The remotejdk25 identifier refers to pre-configured remote JDK 25 distributions provided by rules_java for various platforms [2][3][7]. These can be selected during the build using the --java_runtime_version=remotejdk_25 flag [8][9]. If you are setting this up, ensure you identify the correct repository names for your target platforms (e.g., linux_aarch64, windows, macos) as defined in the rules_java extension [2][3]. Registration is only available in the MODULE.bazel file when using Bzlmod [1][5].
Citations:
- 1: https://bazel.build/external/migration
- 2: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 3: https://pigweed.googlesource.com/third_party/github/bazelbuild/rules_java/+/refs/tags/9.0.3/MODULE.bazel
- 4: https://bazel.build/extending/toolchains
- 5: https://bazel.build/rules/lib/globals/module
- 6: Difficult to override remote JDKs when using Bzlmod bazelbuild/rules_java#222
- 7: Add remote JDK 25 for riscv64, ppc64le and s390x bazelbuild/rules_java#347
- 8: https://bazel.build/docs/bazel-and-java
- 9: https://bazel.build/versions/7.5.0/docs/bazel-and-java
🌐 Web query:
"remotejdk25_linux_toolchain_config_repo" "rules_java" "MODULE.bazel" "GitHub"
💡 Result:
In the context of the rules_java Bazel module, remotejdk25_linux_toolchain_config_repo is an auto-generated repository name used to provide Java 25 toolchain configurations for Linux environments [1][2]. The rules_java module automatically manages remote JDK toolchains, including JDK 25, via its MODULE.bazel file and associated repository utilities [2]. When you use rules_java, the module defines a dictionary of supported JDK versions and platforms [2]. For JDK 25, it automatically generates repository names following the pattern remotejdk{version}_{platform}_toolchain_config_repo [2]. To utilize these toolchains in your project using Bzlmod: 1. Ensure you have the rules_java dependency declared in your MODULE.bazel file [3]. 2. The rules_java module internal logic automatically uses use_repo to bring in the necessary toolchain config repositories and registers them [2]. Specifically, the code performs the following: [use_repo( toolchains, repo + "_toolchain_config_repo",) for repo in REMOTE_JDK_REPOS] [register_toolchains("@" + name + "_toolchain_config_repo//:all") for name in REMOTE_JDK_REPOS] You do not typically need to manually declare remotejdk25_linux_toolchain_config_repo in your own MODULE.bazel file; rather, it is consumed automatically by the rules_java module's setup process [2]. If you need to verify if the toolchain is registered, you can run bazel query //... to inspect registered toolchains or check the output of bazel build with verbose logging [4][5].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
- 2: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 3: https://registry.bazel.build/modules/rules_java
- 4: https://bazel.build/reference/be/java
- 5: https://docs.bazel.build/versions/main/be/java.html
🌐 Web query:
"remotejdk25_linux_toolchain_config_repo" "register_toolchains" "use_repo"
💡 Result:
The identifiers remotejdk25_linux_toolchain_config_repo, register_toolchains, and use_repo are components of Bazel's Bzlmod system used to configure Java toolchains from the rules_java module [1][2]. These are typically used together in a MODULE.bazel file to fetch and register remote JDK toolchains [1][2]. Below is the standard pattern found in the rules_java module: 1. Use an extension to define the toolchains: toolchains = use_extension("//java:extensions.bzl", "toolchains") 2. Use use_repo to make the specific toolchain config repository available: use_repo(toolchains, "remotejdk25_linux_toolchain_config_repo") 3. Register the toolchain so Bazel can use it for builds: register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all") In practice, this is often automated within the rules_java module using list comprehensions to register all available JDK configurations, as seen in the official MODULE.bazel [1][2][3]: # Example of batch registration used by rules_java [use_repo(toolchains, "remotejdk25_linux_toolchain_config_repo")] [register_toolchains("@remotejdk25_linux_toolchain_config_repo//:all")] To use a specific JDK version, you can also set flags in your.bazelrc file, such as --java_runtime_version=remotejdk_25, which corresponds to the registered toolchain [4]. When migrating from WORKSPACE to Bzlmod, note that register_toolchains must be called in MODULE.bazel [5][6].
Citations:
- 1: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/7.12.5/MODULE.bazel
- 2: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 3: https://bazel.googlesource.com/rules_java/+/d413f31d399641a5fd9045551376d4f2c1b6b418/MODULE.bazel
- 4: https://github.com/bazelbuild/bazel/blob/ec67534beb6b1e969b059da4d29394d2934c0980/.bazelrc
- 5: https://bazel.build/external/migration
- 6: https://bazel.build/versions/8.7.0/external/migration
🌐 Web query:
site:raw.githubusercontent.com bazelbuild rules_java MODULE.bazel "remotejdk25_linux" "_toolchain_config_repo"
💡 Result:
In the context of the Bazel rules_java module, remotejdk25_linux refers to a repository name for a specific remote Java Development Kit (JDK 25) distribution for Linux [1][2]. The suffix _toolchain_config_repo is a naming convention used in the MODULE.bazel file of rules_java to identify the auto-generated repositories that provide the toolchain configuration for each remote JDK [1][2][3]. The rules_java MODULE.bazel file typically defines a dictionary of JDK versions and their supported platforms [1][2][3]. It then iterates through these to automatically generate and register toolchains [1][2]. The relevant logic often appears as follows: 1. A list of remote JDK repositories is constructed, such as remotejdk25_linux [1][2]. 2. For each repository in this list, the MODULE.bazel file uses use_repo to fetch the corresponding toolchain configuration repository, named by appending _toolchain_config_repo to the base repository name (e.g., remotejdk25_linux_toolchain_config_repo) [1][2]. 3. These toolchain configuration repositories are then registered with Bazel using register_toolchains [1][2]. This structure allows rules_java to manage multiple JDK versions and platforms in a scalable way, ensuring that the necessary toolchain definitions are loaded and registered dynamically based on the configured environment [1][3].
Citations:
- 1: https://raw.githubusercontent.com/bazelbuild/bazel-central-registry/main/modules/rules_java/7.5.0/MODULE.bazel
- 2: https://raw.githubusercontent.com/filmil/bazel-central-registry/dev/modules/rules_java/8.6.1/MODULE.bazel
- 3: https://raw.githubusercontent.com/filmil/bazel-central-registry/dev/modules/rules_java/7.6.1/MODULE.bazel
🌐 Web query:
"rules_java" "REMOTE_JDK_REPOS" "register_toolchains(\"@\" + name + \"_toolchain_config_repo//:all\")"
💡 Result:
The code snippet register_toolchains("@" + name + "_toolchain_config_repo//:all") is a common pattern used in Bazel modules and repositories to register Java toolchains generated by the rules_java library [1][2]. When using Bzlmod (the Bazel module system), remote JDKs are configured via extensions [3][4]. The rules_java repository maintains a list of predefined remote JDK repositories (represented by the variable REMOTE_JDK_REPOS) [1][2]. For each of these repositories, a corresponding toolchain configuration repository is generated, which typically has a suffix of _toolchain_config_repo [1][2]. The registration process involves: 1. Identifying the repository name (e.g., remotejdk21_linux) [1][2]. 2. Referencing the generated toolchain configuration repository (e.g., @remotejdk21_linux_toolchain_config_repo) [1][2]. 3. Invoking register_toolchains with the path //:all, which points to the toolchain definitions within that configuration repository [1][3][2]. This registration makes the specific JDK available for use in your build, allowing you to select it via the --java_runtime_version flag (e.g., --java_runtime_version=21) [3][5][4]. If you are defining custom JDKs, you follow this same pattern by creating a repository rule (like remote_java_repository), creating a _toolchain_config_repo, and then registering those toolchains in your MODULE.bazel file [3][5][4].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: https://github.com/bazelbuild/bazel-central-registry/blob/ab271a24/modules/rules_java/8.11.0/MODULE.bazel
- 3: https://bazel.build/docs/bazel-and-java
- 4: https://bazel.build/versions/9.1.0/docs/bazel-and-java
- 5: https://bazel.googlesource.com/bazel/+/refs/tags/6.0.0-pre.20220405.2/tools/jdk/remote_java_repository.bzl
🌐 Web query:
"REMOTE_JDK_REPOS" "toolchain_config_repo" "rules_java" MODULE.bazel
💡 Result:
In the context of the rules_java Bazel module, REMOTE_JDK_REPOS and toolchain_config_repo are mechanisms used to manage and register remote JDK toolchains when using Bzlmod [1][2]. REMOTE_JDK_REPOS is a variable (typically defined in the rules_java MODULE.bazel file) that generates a list of repository names for supported JDK versions and platforms [1][3]. These repositories represent the raw JDK downloads [4]. Each of these JDK repositories has a corresponding toolchain_config_repo, which is a repository created to hold the actual Bazel toolchain configuration (such as build files, constraints, and toolchain definitions) required for Bazel to use that JDK [4]. When configuring these in your own MODULE.bazel file, the pattern generally involves: 1. Loading the necessary extension from rules_java (often named toolchains or similar) [1][5]. 2. Using the use_repo directive to import both the JDK repository and its associated toolchain_config_repo [5][6]. 3. Registering the toolchain using the register_toolchains directive, specifically pointing to the toolchain_config_repo [1][5][6]. For example, if you are defining a custom remote JDK, you would typically need to import the *_toolchain_config_repo specifically to register it with Bazel, as the toolchain resolution relies on the configuration files contained within that specific repo [5][4][6]. The standard rules_java implementation automates this by iterating over the list of supported JDKs, importing the config repos, and registering them [1][7].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/MODULE.bazel
- 2: https://bazel.googlesource.com/rules_java/+/d8246a409519f9d551dd866a46278e394bd1b295/MODULE.bazel
- 3: https://bazel.googlesource.com/rules_java/+/899c2b75bdce62dbec082a3ad664f9f0b5f6ede9/MODULE.bazel
- 4: https://bazel.googlesource.com/bazel/+/refs/tags/6.0.0-pre.20220405.2/tools/jdk/remote_java_repository.bzl
- 5: https://bazel.build/docs/bazel-and-java
- 6: Difficult to override remote JDKs when using Bzlmod bazelbuild/rules_java#222
- 7: https://bazel.googlesource.com/rules_java/+/94426d158cdc6fdfcba524ff042bf8ffddf9514a/MODULE.bazel
🌐 Web query:
raw.githubusercontent.com bazelbuild/rules_java MODULE.bazel remotejdk25_linux_toolchain_config_repo remotejdk25_linux
💡 Result:
The identifier remotejdk25_linux refers to a remote Java Development Kit (JDK) 25 toolchain configuration provided by the bazelbuild/rules_java repository [1]. It is defined in the repositories.bzl file within the rules_java project [1] and is designed for use in Bazel builds to provide a hermetic Java runtime environment for Linux systems on various architectures (such as x86_64) [1]. Specifically, remotejdk25_linux_toolchain_config_repo is an internal repository name or label associated with the toolchain configuration that Bazel uses to register and manage this specific JDK 25 runtime [1][2]. When using Bazel's Bzlmod (the recommended dependency management system), these toolchains are typically accessed through the rules_java module, which can be added to your MODULE.bazel file via the Bazel Central Registry [3]. For example, by configuring rules_java, you can enable these pre-built, remote JDKs to be used as toolchains for compiling and running Java code, ensuring consistent build environments across different machines [1]. These definitions often include the necessary checksums, strip prefixes, and download URLs for the corresponding JDK distributions (e.g., from Azul Zulu or Adoptium) [1]. If you encounter errors mentioning this identifier, it often implies a dependency on the rules_java toolchain repository or an issue with the environment's ability to resolve or download the required JDK binary [2].
Citations:
- 1: https://github.com/bazelbuild/rules_java/blob/master/java/repositories.bzl
- 2: bazel-contrib/rules_jvm@cd8c205
- 3: https://registry.bazel.build/modules/rules_java
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
from pathlib import Path
for path in [Path("MODULE.bazel"), Path(".bazelrc")]:
print(f"== {path} ==")
text = path.read_text().splitlines()
for i, line in enumerate(text, 1):
if path.name == ".bazelrc":
if 520 <= i <= 540:
print(f"{i:4}: {line}")
else:
if 40 <= i <= 65:
print(f"{i:4}: {line}")
print()
PY
printf '== references to remotejdk_25 in repo ==\n'
python3 - <<'PY'
from pathlib import Path
import os
for path in Path('.').rglob('*'):
if path.is_file():
try:
text = path.read_text(errors='ignore')
except Exception:
continue
if 'remotejdk_25' in text or 'remotejdk25_' in text:
print(path)
PYRepository: snape/RVO2-Java
Length of output: 1638
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import urllib.request
urls = {
"rules_java_MODULE": "https://raw.githubusercontent.com/bazelbuild/rules_java/master/MODULE.bazel",
"rules_java_repositories": "https://raw.githubusercontent.com/bazelbuild/rules_java/master/java/repositories.bzl",
}
for name, url in urls.items():
print(f"== {name} ==")
try:
with urllib.request.urlopen(url, timeout=20) as r:
data = r.read().decode("utf-8", "replace").splitlines()
for i, line in enumerate(data, 1):
if "remotejdk25" in line or "REMOTE_JDK_REPOS" in line or "toolchain_config_repo" in line or "register_toolchains" in line or "use_repo" in line or "use_extension" in line:
print(f"{i:4}: {line}")
except Exception as e:
print(f"ERROR: {e}")
print()
PYRepository: snape/RVO2-Java
Length of output: 491
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
python3 - <<'PY'
import ssl
import urllib.request
urls = {
"rules_java_MODULE": "https://raw.githubusercontent.com/bazelbuild/rules_java/master/MODULE.bazel",
"rules_java_repositories": "https://raw.githubusercontent.com/bazelbuild/rules_java/master/java/repositories.bzl",
}
ctx = ssl._create_unverified_context()
for name, url in urls.items():
print(f"== {name} ==")
try:
with urllib.request.urlopen(url, context=ctx, timeout=20) as r:
data = r.read().decode("utf-8", "replace").splitlines()
for i, line in enumerate(data, 1):
if ("remotejdk25" in line or "REMOTE_JDK_REPOS" in line or
"toolchain_config_repo" in line or "register_toolchains" in line or
"use_repo" in line or "use_extension" in line):
print(f"{i:4}: {line}")
except Exception as e:
print(f"ERROR: {e}")
print()
PYRepository: snape/RVO2-Java
Length of output: 2078
Register the generated *_toolchain_config_repo repos here. rules_java registers Java toolchains from those config repos; @remotejdk25_*//:all only imports the runtime repos, so .bazelrc’s remotejdk_25 selectors won’t have the toolchains they need.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@MODULE.bazel` around lines 45 - 61, Update the MODULE.bazel use_repo and
register_toolchains declarations for the remotejdk25 repositories to also
include each generated *_toolchain_config_repo repository. Register those config
repos alongside the existing runtime repos so the remotejdk_25 selectors resolve
the Java toolchains provided by rules_java.
Source: MCP tools
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@MODULE.bazel`:
- Around line 43-44: Remove the extra closing parenthesis from the
register_toolchains call in MODULE.bazel so the expression has balanced syntax
and the file parses successfully.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a634f50e-c007-473f-8dcc-9dca2fca6d14
📒 Files selected for processing (6)
.bazelrc.github/workflows/ci.ymlCMakeLists.txtDockerfileMODULE.bazelQUALITY_DECLARATION.md
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@CMakeLists.txt`:
- Line 168: Update the CPACK_RPM_PACKAGE_REQUIRES definition to remove the epoch
prefix from the java-headless dependency, using java-headless >= 25 or an
equivalent distro-specific requirement while preserving the apache-commons-math
dependency.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: f41753d8-3722-4200-be43-93b67700757d
📒 Files selected for processing (6)
.bazelrc.github/workflows/ci.ymlCMakeLists.txtDockerfileMODULE.bazelQUALITY_DECLARATION.md
Set Bazel Java language and runtime defaults to 25 in .bazelrc. Update CI Java provisioning: - Bazel Linux jobs use Java 25 runtime headless packages - OpenSUSE CMake and Gradle jobs use Java 25 devel packages - CMake macOS exports JAVA_HOME and PATH from Homebrew OpenJDK in .github/workflows/ci.yml Update Java 25 requirements and metadata in CMakeLists.txt, Dockerfile, and QUALITY_DECLARATION.md.
1 participant
No description provided.