Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for JDK9 modules #169

Merged
merged 3 commits into from
Nov 15, 2022
Merged

Add support for JDK9 modules #169

merged 3 commits into from
Nov 15, 2022

Conversation

Pante
Copy link
Owner

@Pante Pante commented Nov 12, 2022

This PR introduces low-level support for JDK 9 modules. Using this approach, it is possible that we do not need to introduce any additional annotations.

@Pante Pante added this to the 2.0.0 milestone Nov 12, 2022
@Pante Pante linked an issue Nov 12, 2022 that may be closed by this pull request
@codecov
Copy link

codecov bot commented Nov 12, 2022

Codecov Report

Base: 46.11% // Head: 46.78% // Increases project coverage by +0.66% 🎉

Coverage data is based on head (0e8c6c8) compared to base (a4ef241).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #169      +/-   ##
============================================
+ Coverage     46.11%   46.78%   +0.66%     
- Complexity      219      224       +5     
============================================
  Files            35       35              
  Lines          1030     1041      +11     
  Branches        100      103       +3     
============================================
+ Hits            475      487      +12     
+ Misses          534      533       -1     
  Partials         21       21              
Impacted Files Coverage Δ
...c/main/java/com/karuslabs/elementary/Compiler.java 98.33% <100.00%> (+0.37%) ⬆️
...com/karuslabs/elementary/junit/DaemonCompiler.java 97.77% <100.00%> (+2.22%) ⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

CHANGELOG.md Outdated Show resolved Hide resolved
CHANGELOG.md Outdated Show resolved Hide resolved
@@ -57,7 +57,7 @@ public static Compiler javac() {
private final JavaCompiler compiler;
private final List<Processor> processors = new ArrayList<>();
private final List<String> options = new ArrayList<>();
private @Nullable List<File> classpath;
@Nullable Set<File> classpath;
Copy link
Contributor

Choose a reason for hiding this comment

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

Why not private?

Copy link
Owner Author

Choose a reason for hiding this comment

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

This was made package-private so that we can inspect the classpath in unit tests.

Copy link
Contributor

Choose a reason for hiding this comment

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

You could use something like @VisibleForTesting, but it's also a sign that you're testing something the wrong way. If you don't want to create a public method exposing the field, then consider using a mockito mock for the compiler object and use a mockito capture for the parameter that uses this field. That way this field can remain private.

Copy link
Owner Author

Choose a reason for hiding this comment

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

Generally, I prefer not to use @VisibleForTesting since it requires a dependency on Guava, which isn't really worth it. Also making it public/protected and annotating with @VisibleForTesting will cause the field to appear in the Javadocs which IMO is a worse trade-off.

Normally I would have exposed it as a parameter and allowed it to be DIed in. However, in this case, the field needs to be lazy which isn't a good candidate for that. IMO it's slightly better than using a mock in this case.

@Pante
Copy link
Owner Author

Pante commented Nov 15, 2022

I'm going ahead and merging this in.

@Pante Pante merged commit 4b2d435 into master Nov 15, 2022
@Pante Pante deleted the feature/support-JDK9-modules branch February 1, 2023 04:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FEATURE REQUEST] Primitives for Module support
2 participants