On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI >> environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a >> 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI >> was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 >> environment when it really wants the latest. `GetEnv` should request >> `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and >> compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, >> and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Get rid of some structs and statics that are no longer needed. In the distant past it may have been useful to copy libjdwp/libsocket_dt from a JDK build into a build (JRE or embedded) that didn't have the debugger agent. Those days are long gone. Also since JDK 9, the JDK build generates a hash for each packaged module that is later use by jlink to detect any accidental mix 'n matching of modules from one JDK build with another. This will catch accidental attempts to use the jdk.jdwp.agent module one from build with java.base from another build. The error message "is your J2SE a 1.5 or newer version?" has come several times during JDK 19 and JDK 20 development, mostly in GHA with new tests attempting to run with --enable-preview and use JVMTI (jshell tests for example). JDK-8287812 was created to remove the confusing part of the error message but has since expanded to broader cleanup, which is okay. If virtual threads become permanent in JDK 21, and if the are outstanding ports of VM continuations, then it means that JVMTI may have to be disabled completely for those ports (in which case the error in PR will be seem widely, unless the tests are changed to skip) or JVMTI will have to be changed to work the alternative implementation of virtual threads (in which case this error should not be seen). ------------- PR: https://git.openjdk.org/jdk/pull/11602
