I would try to go down way (b). That way the discussion whether or not to drop $featureX in favor of $featureY does not need to happen.
The interesting question is: How ugly can it get and what should be supported? Could nashorn-jdk and nashorn-standalone coexist in a single VM and if so, is it possible to modify the routines, to cover both cases?

@matthiasblaesing,
I missed your question, sorry about that.

The interesting question is: How ugly can it get and what should be supported?

Ugly ... it depends on personal subjective feelings, only those constants will be doubled, not a big deal.

Could nashorn-jdk and nashorn-standalone coexist in a single VM

I guess so, they have different name space (package)

is it possible to modify the routines, to cover both cases?

Yes, it is.

Based on the question I deduct the fix for new Nashorn has a chance to be accepted, I'll prepare fix that supports both engines in one source code.

@cz6ace your interpretation is correct. Thanks for taking this on.

Any chance that this ticket gets some progress?
Netbeans was the only IDE which was able to properly debug nashorn/js.
It's a bit sad that it no longer is.

@ChrisHuebsch-FLIG provide exakt steps of what you expect to work and people might look at it. Just talking about it won't help.

Any chance that this ticket gets some progress? Netbeans was the only IDE which was able to properly debug nashorn/js. It's a bit sad that it no longer is.

I know, I know, if there's really someone looking for it, I'll provide patch. I was terribly busy, but I did not forgot. Promise.

I know, I know, if there's really someone looking for it, I'll provide patch. I was terribly busy, but I did not forgot. Promise.

I just got the current version from the git, added your patch, compiled it and now I am able to remote debug JS again. :-)

Works great. I really appreciate it.

@ChrisHuebsch-FLIG what I meant was, that to check if any changes worked, there needs to be an example what should happen. I.e. a sample project and what are to be executed in the IDE to reach the target state (initial debugging). The patch from @cz6ace looks sane to me and most probably it can be extended to cover both "JDK bundled" and "external nashorn" case. We went down the "just scan for the other named class" road already for the JavaEE/JakartaEE transition, so we know, that it works in principle.

I've prepared second patch that should work with both Nashorns - see attached
nashorn-15-both.patch
Before Pull request I tried to rebase (from Netbeans 20) to the latest master and I'm not able to compile. ant clean build did not help and whole Sunday is exhausted by this.

@ChrisHuebsch-FLIG could you please try this second patch? And what JDK do you have (I have OpenJDK 17.0.12 in Ubuntu 22) ? Any special environment set for compilation?

Edit: I was able to compile on master by moving to Ubuntu 24

@ChrisHuebsch-FLIG could you please try this second patch? And what JDK do you have (I have OpenJDK 17.0.12 in Ubuntu 22) ? Any special environment set for compilation?

I am using Windows 10 & Adoptium OpenJDK 17.0.13_11

I was using a git bash to apply your (first) patch and used the method given by netbeans to compile it. (Set ANT_HOME and JAVA_HOME and run the ant.)
Although I got lots of warnings regarding deprecated APIs and "unsafe" casts, I got a working version.

For testing your second patch I need to find some time.