Skip to content

Fixes for jdk providers#104

Merged
quintesse merged 6 commits into
mainfrom
fix_accept
May 26, 2026
Merged

Fixes for jdk providers#104
quintesse merged 6 commits into
mainfrom
fix_accept

Conversation

@quintesse
Copy link
Copy Markdown
Contributor

@quintesse quintesse commented May 26, 2026

Summary by CodeRabbit

  • New Features

    • Added Windows registry-based JDK discovery to automatically detect Java installations from the system registry
  • Bug Fixes

    • Corrected Linux JDK root directory configuration
    • Improved symlink filtering and folder validation during JDK discovery
  • Tests

    • Added comprehensive test suites validating JDK discovery across multiple providers and platforms

Review Change Stack

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented May 26, 2026

📝 Walkthrough

Walkthrough

This PR refactors JDK provider folder acceptance logic by removing format validation from the base class and delegating it to subclasses, centralizes JDK root path resolution across providers with new jdksRoot() methods, introduces Windows registry-based JDK discovery via WindowsJdkProvider, and adds comprehensive test coverage for all provider implementations.

Changes

JDK Provider Refactoring and Windows Discovery

Layer / File(s) Summary
Base folder acceptance refactoring
src/main/java/dev/jbang/devkitman/jdkproviders/BaseFoldersJdkProvider.java
BaseFoldersJdkProvider.acceptFolder() no longer validates folder names against isValidId(); it only checks that folders exist under jdksRoot and contain a javac command. Provider-specific ID validation is now the responsibility of subclasses.
Subclass validation tightening
src/main/java/dev/jbang/devkitman/jdkproviders/JBangJdkProvider.java, LinkedJdkProvider.java
JBangJdkProvider and LinkedJdkProvider both add isValidId() checks to their acceptFolder() methods, enforcing folder-name format validation previously handled by the base class. JBangJdkProvider preserves numeric-folder compatibility.
JDK root path centralization
src/main/java/dev/jbang/devkitman/jdkproviders/LinuxJdkProvider.java, MiseJdkProvider.java, ScoopJdkProvider.java, SdkmanJdkProvider.java
Four providers introduce public static jdksRoot() methods to centralize JDK directory resolution. LinuxJdkProvider updates to /usr/lib/jvm, changes JDKS_ROOT to private, and replaces isSameFolderLink() with isLink() for symlink filtering. ScoopJdkProvider adds directory-existence checks and parent-folder-name inspection. SdkmanJdkProvider and MiseJdkProvider consolidate user.home resolution.
Windows registry-based JDK provider
src/main/java/dev/jbang/devkitman/jdkproviders/WindowsJdkProvider.java, src/main/resources/META-INF/services/dev.jbang.devkitman.JdkDiscovery
Introduces WindowsJdkProvider to discover installed JDKs from Windows registry (HKLM SOFTWARE\JavaSoft). Implements pluggable RegistryReader interface with default RegCommandRegistryReader that runs reg query and parses output. Deduplicates registry entries by home path, preserving entries with longest registry keys. Includes WindowsJdkProvider.Discovery for service loading. Registers discovery implementation in service manifest.
Comprehensive provider test coverage
src/test/java/dev/jbang/devkitman/TestJdkProviders.java, src/test/java/dev/jbang/devkitman/jdkproviders/*.java
Adds eight new JUnit 5 test classes (ExternalJdkProviderTest, JavaHomeJdkProviderTest, MiseJdkProviderTest, MultiHomeJdkProviderTest, PathJdkProviderTest, ScoopJdkProviderTest, WindowsJdkProviderTest) that verify JDK discovery by version pattern, symlink handling, invalid-path filtering, deduplication logic, and ID stability. TestJdkProviders is reformatted to include new provider assertions.

🎯 3 (Moderate) | ⏱️ ~25 minutes

🐰 A garden of JDK providers fair,
Now rooted deep, with paths laid bare,
Windows joins the meadow wide,
Tests bloom where discovery guides.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check ❓ Inconclusive The title 'Fixes for jdk providers' is overly vague and generic, using a non-specific term 'Fixes' without describing what problems are being addressed or what the main changes accomplish. Consider using a more descriptive title such as 'Refactor JDK provider folder acceptance logic and add Windows registry discovery' or 'Improve JDK provider acceptance criteria and add WindowsJdkProvider implementation' to better convey the actual changes.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix_accept

Warning

Tools execution failed with the following error:

Failed to run tools: 13 INTERNAL: Received RST_STREAM with code 2 (Internal server error)


Comment @coderabbitai help to get the list of available commands and usage tips.

@quintesse quintesse marked this pull request as ready for review May 26, 2026 16:12
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 `@src/main/java/dev/jbang/devkitman/jdkproviders/JBangJdkProvider.java`:
- Around line 91-92: The boolean expression currently allows parseToInt(...) > 0
to return true even when super.acceptFolder(jdkFolder) is false; update the
logic in JBangJdkProvider.acceptFolder so super.acceptFolder(jdkFolder) is
required and grouped with the ID checks by changing the expression to require
super.acceptFolder(jdkFolder) && (isValidId(jdkFolder.getFileName().toString())
|| JavaUtils.parseToInt(jdkFolder.getFileName().toString(), 0) > 0); this
ensures super.acceptFolder(...) is evaluated first and both ID or numeric checks
are applied only when the superclass accepts the folder.

In `@src/main/java/dev/jbang/devkitman/jdkproviders/WindowsJdkProvider.java`:
- Around line 42-44: The WindowsJdkProvider constructor accepts a RegistryReader
annotated `@NonNull` but doesn't guard at runtime; add an explicit null check in
the WindowsJdkProvider(`@NonNull` RegistryReader registryReader) constructor
(e.g., use Objects.requireNonNull or an if-check) to validate registryReader and
throw a clear NPE/IllegalArgumentException so callers fail fast instead of
deferring to listInstalled() when registryReader is used.
🪄 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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 43ce00cb-7641-4d5e-b218-e9321bfb4e31

📥 Commits

Reviewing files that changed from the base of the PR and between f1594ca and 51ca7e2.

📒 Files selected for processing (17)
  • src/main/java/dev/jbang/devkitman/jdkproviders/BaseFoldersJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/JBangJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/LinkedJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/LinuxJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/MiseJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/ScoopJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/SdkmanJdkProvider.java
  • src/main/java/dev/jbang/devkitman/jdkproviders/WindowsJdkProvider.java
  • src/main/resources/META-INF/services/dev.jbang.devkitman.JdkDiscovery
  • src/test/java/dev/jbang/devkitman/TestJdkProviders.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/ExternalJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/JavaHomeJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/MiseJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/MultiHomeJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/PathJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/ScoopJdkProviderTest.java
  • src/test/java/dev/jbang/devkitman/jdkproviders/WindowsJdkProviderTest.java

Comment on lines +42 to +44
public WindowsJdkProvider(@NonNull RegistryReader registryReader) {
this.registryReader = registryReader;
}
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Enforce non-null RegistryReader in the constructor.

@NonNull is not a runtime guard. If null is passed, the failure is deferred until dereference in listInstalled() (Line 70), making diagnosis harder.

Suggested fix
 public WindowsJdkProvider(`@NonNull` RegistryReader registryReader) {
-    this.registryReader = registryReader;
+    this.registryReader = Objects.requireNonNull(registryReader, "registryReader");
 }
🤖 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 `@src/main/java/dev/jbang/devkitman/jdkproviders/WindowsJdkProvider.java`
around lines 42 - 44, The WindowsJdkProvider constructor accepts a
RegistryReader annotated `@NonNull` but doesn't guard at runtime; add an explicit
null check in the WindowsJdkProvider(`@NonNull` RegistryReader registryReader)
constructor (e.g., use Objects.requireNonNull or an if-check) to validate
registryReader and throw a clear NPE/IllegalArgumentException so callers fail
fast instead of deferring to listInstalled() when registryReader is used.

@quintesse quintesse merged commit 6b55f28 into main May 26, 2026
4 checks passed
@quintesse quintesse deleted the fix_accept branch May 26, 2026 16:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant