Replace terminally deprecated SourcePositions method usage

[mbien]

can be replaced with variants without CompilationUnitTree parameter (javadoc, select 27)

added requires.nb.javac=true to

• enterprise/maven.j2ee
• java/gradle.java

ignored in refactoring

• java/jshell.support

refactoring script:

$src.getStartPosition($cu, $doc, $tree) :: $src instanceof com.sun.source.util.DocSourcePositions
=>
$src.getStartPosition($doc, $tree)
;;

$src.getEndPosition($cu, $doc, $tree) :: $src instanceof com.sun.source.util.DocSourcePositions
=>
$src.getEndPosition($doc, $tree)
;;

$src.getStartPosition($cu, $tree) :: $src instanceof com.sun.source.util.SourcePositions
=>
$src.getStartPosition($tree)
;;

$src.getEndPosition($cu, $tree) :: $src instanceof com.sun.source.util.SourcePositions
=>
$src.getEndPosition($tree)
;;

(i tried parameter type matching but it didn't work - likely classpath issue. Shouldn't matter though since there is no ambiguity)

[JaroslavTulach]

• you are trying to avoid usage of getEndPosition which is fine on JDK25
• but got deprecated in JDK 27 getEndPosition
  • I have no idea, why it got deprecated, but:
  • I don't see any reason why it should be removed!
  • It can be kept around and continue to delegate to the other method with less arguments indefinitely
  • I am sure Lahváč and Dušan could explain us the rationale, if they could speak openly in public...
• as the method doesn't have to be removed (unless the CompilationUnitTree is about to be removed)
  • I see little reasons to hurry up removing it from the JDK
  • by replacing its usage with a method that doesn't exist in JDK 25 ...
  • ... we disallow running NetBeans with older than JDK 27 plain javac
• I am not saying it is a problem...
  • in fact, I like requires.nb.javac=true and I'd put it on by default ;-)
  • the more nb-javac, the better!
• overall I don't feel I should judge this PR - this note is just my braindump - neither approval nor disapproval

[mbien]

deprecation is the right decision if a method parameter becomes a no-op - esp if there is a direct replacement with less parameters.

https://github.com/openjdk/jdk/blob/30ec3785d8181eb36593ab0871dcf1707af3cae3/src/jdk.compiler/share/classes/com/sun/source/util/SourcePositions.java#L59-L61

https://github.com/openjdk/jdk/blob/30ec3785d8181eb36593ab0871dcf1707af3cae3/src/jdk.compiler/share/classes/com/sun/source/util/DocSourcePositions.java#L66-L68

Even if it wouldn't be for-removal, its worth getting rid of a parameter which doesn't do anything since it is something which could allow further code simplifications in future. This is just aligning NB's usage with the new API while shrinking the build log too as side effect.

I am mostly looking for a second set of eyes who could go through the diff and check if it looks good. I already done that after refactoring but it wouldn't hurt.

going to do a second pass and remove redundant overrides of the default method as in

netbeans/java/java.source.base/src/org/netbeans/api/java/source/TreeUtilities.java

Lines 845 to 848 in 731d769

	@Override
	public long getStartPosition(CompilationUnitTree file, Tree tree) {
	return getStartPosition(tree);
	}

(there aren't many - this will be a second commit -> I think this will allow removal of a field in some cases)