jorsol commented on code in PR #219:
URL:
https://github.com/apache/maven-compiler-plugin/pull/219#discussion_r1433148927
##########
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java:
##########
@@ -1842,6 +1851,48 @@ private boolean
hasInputFileTreeChanged(IncrementalBuildHelper ibh, Set<File> in
return inputTreeChanges.hasChanged();
}
+ private static final int MAX_FILE_WALK_LIMIT = 20;
+
+ /**
+ * Performs a check on compiled class files to ensure that the bytecode
version
+ * hasn't changed between runs.
+ *
+ * <p>This is limited to check a maximum of {@link #MAX_FILE_WALK_LIMIT}.
+ *
+ * @return true if a bytecode version differs from the actual release
version.
+ */
+ private boolean hasBytecodeChanged() {
+ String currentVersion = getVersionRelease();
+ JavaVersion javaVersion = JavaVersion.parse(currentVersion).asMajor();
+
+ try (Stream<Path> walk = Files.walk(getOutputDirectory().toPath())) {
+ Map<Path, JavaClassfileVersion> pathVersionMap = walk.filter(file
-> "class"
+
.equals(FileUtils.extension(file.getFileName().toString())))
+ .limit(MAX_FILE_WALK_LIMIT)
+ .collect(Collectors.toMap(Function.identity(),
JavaClassfileVersion::of));
Review Comment:
That's a really good approach, I'm making complex bytecode checks when
simply storing the current JDK, and verifying next time would do the trick.
Closing this in favor of that approach (will open a new PR later).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
