Disable preview features from triage.properties

[niloc132]

Running the emulation doc commands with Java 26 results in these lines (among many others) in triage.properties

members=java.util.List#ofLazy(int, IntFunction)\
java.util.Map#ofLazy(Set, Function)

However, these are preview-only features
https://docs.oracle.com/en/java/javase/26/docs/api/java.base/java/util/Map.html#ofLazy(java.util.Set,java.util.function.Function)

ofLazy is a preview API of the Java platform.
Programs can only use ofLazy when preview features are enabled.
Preview features may be removed in a future release, or upgraded to permanent features of the Java platform.

We shouldn't even list these until they are no longer marked as preview.

When this is fixed, the gh1037.properties file should be deleted as no longer needed to build on java 26.

[zbynek]

Preview methods can be listed in https://github.com/gwtproject/gwt/blob/main/build_tools/doctool/src/com/google/doctool/custom/JavaEmulSummaryDoclet.java#L85 (one preview method is there already)

Since https://github.com/openjdk/jdk/blob/ff2b7b3f9d57be6f869759f3cda3e3debb05d047/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java#L50 has CLASS retention I'm not sure there's a better solution than an explicit list.

[tbroyer]

CLASS retention means it can be read by reflection so it should be possible to detect those methods and classes, right?

[zbynek]

CLASS retention means it can be read by reflection

per documentation "Annotations are to be recorded in the class file by the compiler but need not be retained by the VM at run time" so reflection won't work.

[niloc132]

We aren't using reflection here though right? I believe that the javadoc tooling has access to elements/mirrors, which don't need RUNTIME, but can either read SOURCE level (if being fed sources, which won't apply to jre types) or CLASS (for libraries, the jre itself).

[zbynek]

We're comparing the

• elements/mirrors of the emulated types that that we get from the GWT source -- those don't have the preview methods
• the actual types available in the running JVM (via reflection) -- those have the preview methods, but without accessible annotations

am I missing something?

[niloc132]

Got it, my mistake then - I thought we were reading elements of the JRE.

We should be able to instead read the class itself (asm would be my first guess for an easy tool already on hand... but then we must have asm up to date with the latest supported JRE). Since up to Java 26 we only have three examples of an issue here (one already explicitly included in the doclet, the other two discussed here), maybe we stick to hardcoding them and reevaluate for Java 27 or so...?

[zbynek]

maybe we stick to hardcoding them and reevaluate for Java 27 or so...?

Sounds good.