Remove placeholder jshell jdk8 module

[mbien]

originally intended to do something in the sense of https://github.com/apache/netbeans/pull/7677 and keep one module, but it turns out that more can be removed

Remove lib.jshell and lib.jshell9 modules

• modules are no longer needed with current JDK requirements
• removes jshell-9.jar dependency which embedded jdk classes into nb-mod-jshell-probe.jar
• bump lib.jshell.agent module to JDK 11
• jshell won't be able to launch on JDK 8 anymore (now 9+)

[lahodaj]

I think this will be a good cleanup.

[mbien]

@lahodaj originally I only intended to replace lib.nbjshell with lib.nbjshell9, but it turned out that both modules can likely be removed.

while testing I noticed that jshell doesn't work if NB runtime JDK < configured jshell JDK. I am not sure if this was a requirement or not. Thats why I set it back to draft. (this is the case in NB 25 already, with or without this PR. If NB runs on JDK 17 it can't run jshell on 21.

[matthiasblaesing]

The cross-jdk access indeed seems to be problematic. NB running on JDK 23 can use target JDK 23 and 21, but not 17. Running this by hand shows the problem:

matthias@enterprise:~$ /usr/lib/jvm/java-17-openjdk-amd64/bin/java -classpath /home/matthias/bin/netbeans-dev/java/modules/ext/nb-mod-jshell-probe.jar: -Xrunjdwp:transport=dt_socket,address=localhost:53633,suspend=y,includevirtualthreads=n org.netbeans.lib.jshell.agent.AgentWorker 35645
ERROR: JDWP option syntax error: -agentlib:jdwp=transport=dt_socket,address=localhost:53633,suspend=y,includevirtualthreads=n
matthias@enterprise:~$

The new parameter includevirtualthreads breaks the connection setup.

In the opposite direction I see a problem when running on JDK 17 and choosing JDK 21 as platform. If I read ShellSession.java correctly, the code asks the runtime JDK to create a javac with target of the target platform. This must go wrong.

So I think this is not a regression, just a feature, that is broken when not used in default configuration (target JDK != runtime JDK).

[mbien]

The cross-jdk access indeed seems to be problematic. NB running on JDK 23 can use target JDK 23 and 21, but not 17

took a look and

• for JDK 19+ as runtime the compatible jshell version would be [19, RT_JDK]
• for JDK 17 or 18 as runtime it would be [9, RT_JDK]

due to https://github.com/openjdk/jdk/blob/0460978e7c769624cacdb528277a99914b327e30/src/jdk.jdi/share/classes/com/sun/tools/jdi/SunCommandLineLauncher.java#L135-L140 which isn't recognized on JVMs < 19 (there is also no option to ignore unknown flags) as you mentioned.

whats funny though is that the argument is checked on both sides, I tried to remove it from the connector via reflection as test and it failed validation on the client side:

com.sun.jdi.connect.IllegalConnectorArgumentsException: Argument missing
	at jdk.jdi/com.sun.tools.jdi.ConnectorImpl.argument(ConnectorImpl.java:105)
	at jdk.jdi/com.sun.tools.jdi.SunCommandLineLauncher.launch(SunCommandLineLauncher.java:167)
	at jdk.jshell/jdk.jshell.execution.JdiInitiator.lambda$launchTarget$0(JdiInitiator.java:142)

In the opposite direction I see a problem when running on JDK 17 and choosing JDK 21 as platform. If I read ShellSession.java correctly, the code asks the runtime JDK to create a javac with target of the target platform. This must go wrong.

I think this might be actually correct since it uses also the classpath of the target platform too. I believe what is happening is that JShell invokes javac from the runtime JDK without using its javac or nb-javac. I tried to enable nb-javac but this lead to other classloader problems.

I probably won't change anything there for now - this would be something for other PRs.

[mbien]

rebase / resolved conflicts

[mbien]

I am leaning slightly towards the current version of the PR, which removes both lib.jshell and lib.jshell9. The consequence is that it is less likely that someone could find a workaround for https://github.com/apache/netbeans/pull/8264#issuecomment-2726292064. (JDK ranges are influenced by NB runtime JDK).

Not sure if it was cleared up that NB would bundle a few of the JDK's jshell classes, this seemed to be the case long before nb-javac was included. This might be a non-technical argument in favor for removal.

[neilcsmith-net]

Haven't had a chance to review properly, sorry, but I also think because of the JDK classes this has to go in?!

[mbien]

ok, lets get this in for NB 27, merging.

one osuosl dependency less