8151255: javac with a annotation processor returns incorrect error code

[liliBestCoder]

Hi,

When I was building my application using Maven 3.6.3, I had two applications A and B that had a dependency relationship. B relied on A's jar. When I built both A and B simultaneously, A built successfully. Although B threw an exception, Javac believed that B had built successfully. I unpacked B's jar package and found that there was no class file inside. So I searched for the reason based on the exception information, and found that Javac was divided into multiple rounds when processing annotations. If an abort occurred in a certain round, Javac would not be able to find the delegate compiler. If Javac's own errors were 0 at this time, it would consider compilation successful, but te specific error information was reported to the global diagnosticCollector by the delegate compiler, So even though Maven printed an error, it didn't stop working due to the error, but instead continued to package and ultimately printed an incorrect package.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• JDK-8151255 needs maintainer approval
• Commit message must refer to an issue

Issue

• JDK-8151255: javac with a annotation processor returns incorrect error code (Bug - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk8u-dev.git pull/432/head:pull/432
$ git checkout pull/432

Update a local copy of the PR:
$ git checkout pull/432
$ git pull https://git.openjdk.org/jdk8u-dev.git pull/432/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 432

View PR using the GUI difftool:
$ git pr show -t 432

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk8u-dev/pull/432.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back liliBestCoder! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge]

Webrevs

• 00: Full (0ccd02f3)

[jddarcy]

@liliBestCoder , per general OpenJDK development procedures, a fix like this should first be considered against the mainline release, currently JDK 23, and then if it is fixed in mainline, subsequently possibly backported to earlier release trains. You could also inquire to get feedback on a fix for a bug to the appropriate mailing list before sending the PR, compiler-dev in this case. HTH

[liliBestCoder]

@liliBestCoder , per general OpenJDK development procedures, a fix like this should first be considered against the mainline release, currently JDK 23, and then if it is fixed in mainline, subsequently possibly backported to earlier release trains. You could also inquire to get feedback on a fix for a bug to the appropriate mailing list before sending the PR, compiler-dev in this case. HTH

I don't know if this problem has been fixed in jdk 23. This should need to be tested to know. But I think jdk 23 should be very different from jdk 8. The patch should not be applied directly here. That's why I submitted PR here

[liliBestCoder]

I have looked at the code of jdk23 and found that the delegated compiler is no longer used when processing annotations, and when an abort occurs, the exception should be reported directly to the global diagnosticCollector, so this problem of mine no longer exists. Moreover, the code difference is relatively large and it is difficult to backport it to Java8.

[jddarcy]

I have looked at the code of jdk23 and found that the delegated compiler is no longer used when processing annotations, and when an abort occurs, the exception should be reported directly to the global diagnosticCollector, so this problem of mine no longer exists. Moreover, the code difference is relatively large and it is difficult to backport it to Java8.

From a comment on the bug, the issue does not reproduce under JDK 9 so was presumably fixed as a side-effect of some JDK 9 javac change.

As a rule, OpenJDK generally follows a fix in later release and then backport model, so isolating the JDK 9 change the addressed this issue would, by default, be the route to fix it. However, the 8u maintainers are conservative in what fixes are allowed in, so they may decline to accept the fix even if it backported from a later release. HTH

[liliBestCoder]

I have looked at the code of jdk23 and found that the delegated compiler is no longer used when processing annotations, and when an abort occurs, the exception should be reported directly to the global diagnosticCollector, so this problem of mine no longer exists. Moreover, the code difference is relatively large and it is difficult to backport it to Java8.

From a comment on the bug, the issue does not reproduce under JDK 9 so was presumably fixed as a side-effect of some JDK 9 javac change.

As a rule, OpenJDK generally follows a fix in later release and then backport model, so isolating the JDK 9 change the addressed this issue would, by default, be the route to fix it. However, the 8u maintainers are conservative in what fixes are allowed in, so they may decline to accept the fix even if it backported from a later release. HTH

Oh, I saw that this problem was indeed solved in jdk9, and the relevant code is also reflected in jdk23. The versions of these codes are quite different from jdk8. So now that jdk8 has such a problem, do we need to isolate jdk9 to solve it? Or just ignore it?
Or let those using jdk8 solve this problem by upgrading the jdk version.

[bridgekeeper]

@liliBestCoder This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[bridgekeeper]

@liliBestCoder This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[bridgekeeper]

@liliBestCoder This pull request has been inactive for more than 8 weeks and will now be automatically closed. If you would like to continue working on this pull request in the future, feel free to reopen it! This can be done using the /open pull request command.