Propagate canUseRelease into CustomJavacClassLoader

[jtulach]

• enhances ba99c75 by @mbien to use the canUseRelease flag also in custom class loader
• the change is motivated by failure when fixing nb-javac
• with this change the java/form builds OK with the nb-javac being developed at 1:1 semantics with DirectModuleWrapper over java.lang.Module JaroslavTulach/nb-javac#39
• I am setting the target to delivery:
  • this change doesn't affect production bits (nb-javac isn't used to produce them)
  • it would be useful to have the java/form module from release300 buildable by nb-javac

[jtulach]

• @matthiasblaesing suggested to remove the canUseRelease code altogether
• I would rather fix the code to honor canUseRelease everywhere as this PR does
  • using --release is preferred over --source and --target in my opinion
  • the --release exposes only official Java API
  • when nb-javac build of NetBeans succeeds, we are then sure that regular modules don't use sun.misc.Unsafe & co. ...
  • ... which was a typical problem before I implemented this replace source and target by release when possible check
• with the change here and 1:1 semantics with DirectModuleWrapper over java.lang.Module JaroslavTulach/nb-javac#39 I can build ant build -Dnbjavac.class.path=/nb-javac/make/langtools/netbeans/nb-javac/dist/nb-javac-jdk-26+35-*jar successfully

[neilcsmith-net]

I know @ebarboni planned to run the release vote this week. This isn't currently labelled high or critical so as is won't go in NB30. If you think it needs to, then justification and reason for additional RC and week delay needs adding to the PR.

[jtulach]

I know @ebarboni planned to run the release vote this week. This isn't currently labelled high or critical so as is won't go in NB30. If you think it needs to, then justification and reason for additional RC and week delay needs adding to the PR.

Thank you Neil. No reason to require additional RC and have a week delay because of this change. If there is some other "high" or "critical" reason for another RC, then we could include this PR. Otherwise, we just integrate it into master.

[matthiasblaesing]

Looks sane to me and can IMHO be merged to master, not delivery. I don't see a reason to interfere with release for this.

Independent from that I disagree with the assessment, that having the magic --target == --source maps to --release in there is a good idea. Many modules are already are correctly configured in their properties, to use javac.release, it would be better to complete the transition there instead of this magic.

[lahodaj]

Looks OK to me. We can cleanup later when we stop using javac.source in NB.

[ebarboni]

ok, flagging do not merge to not mess up. If you rebase on master please remove the label.

Btw I will try to do the release on monday. Running out of time

[matthiasblaesing]

@jtulach I suggest to retarget this to master, check that target is indeed master, rerun checks and if they come back green merge.

[jtulach]

Looks sane to me and can IMHO be merged to master, not delivery. I don't see a reason to interfere with release for this.

OK, targeting master. We are still green.

Independent from that I disagree with the assessment, that having the magic --target == --source maps to --release in there is a good idea. Many modules are already are correctly configured in their properties, to use javac.release,

Yeah, using javac.release where possible is certainly better and less magical than the current "switch"...

We can cleanup later when we stop using javac.source in NB.

...but as Jan wrote. Let that happen in other PRs.