Skip to content

Comments

Improving handling of broken bootpaths with an implicit hardcoded --release#9048

Merged
lahodaj merged 1 commit intoapache:masterfrom
lahodaj:improving-handling-of-release-in-javacparser
Dec 1, 2025
Merged

Improving handling of broken bootpaths with an implicit hardcoded --release#9048
lahodaj merged 1 commit intoapache:masterfrom
lahodaj:improving-handling-of-release-in-javacparser

Conversation

@lahodaj
Copy link
Contributor

@lahodaj lahodaj commented Nov 28, 2025

When a project sends broken bootclasspath/system module path, NetBeans' JavacParser will fall back to an implicit --release. while I may have some reservations about it, it does help in some cases.
There are two problems with that however:

  • when compiler options are validated, they are validated against the validated source level, not against the release version javac will use in the end. In practice, this means options like --limit-modules are usually filtered-out, as the validated source level is something extremely old (like 1.3). If we use the implicit --release, we should validate against it.
  • if the source level is very old (older that 1.7), we use 1.7 instead. And then check if the source level is "supported" - but 1.7 is not supported anymore, so --release won't be used when very old source level is used. The proposal herein is to simply use the oldest supported source level.

^Add meaningful description above

Click to collapse/expand PR instructions

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

  • are all your own work, and you have the right to contribute them.
  • are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

  1. Was this PR correctly labeled, did the right tests run? When did they run?
  2. Is this PR squashed?
  3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
  4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

@lahodaj lahodaj added this to the NB29 milestone Nov 28, 2025
@lahodaj lahodaj added the Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form) label Nov 28, 2025
Copy link
Member

@mbien mbien left a comment

Choose a reason for hiding this comment

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

looks good to me

(some of the javac flags this class sets might no longer be supported? e.g i could still find -XDsuppressAbortOnBadClassFile in the jdk 8 repo but no longer in jdk 11)

@lahodaj lahodaj force-pushed the improving-handling-of-release-in-javacparser branch from c83545f to e409a3e Compare December 1, 2025 12:38
@lahodaj lahodaj merged commit fcac054 into apache:master Dec 1, 2025
69 of 70 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Java [ci] enable extra Java tests (java.completion, java.source.base, java.hints, refactoring.java, form)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants