Yes, it seems you’re right. I don’t quite get the point of “managing” them if new ones are created for everything, but this might have been handled differently in the past. This seems very wasteful to me though, but I don’t know the real cost of creating all these script engines.
Sure, it is accessed through JSR223/ScriptEngine and that’s fine, but as I understand it, that’s not where the “synchronization requirements” come from? Other JSR223 languages can run fine without isolating every script engine instance, as far as I understand.
Ah, so “context” and “context” are different concepts? There is a JSR223 “context” concept, and there is also GraalVM Polyglot Context, which is effectively wrapped in a ScriptEngine? That certainly complicates things, if the concepts work so differently for GraalVM and non-GraalVM languages. Have you (or anybody else) look at how this will be organized when it’s moved to OpenJDK?
Yes, the concepts are very confusing. OH Core use JSR223 and its concepts, while GraalVM doesn’t really do that, and have just made some “cheap adapter” to JSR223 to speed up adoption, while at the same time arguing that people shouldn’t use it this way.
I don’t have the necessary overview to evaluate this at all, but it might be that things would be easier if GraalVM wasn’t accessed through JSR223, and that support for GraalVM was made directly in Core instead, as an alternative to JRS223.
edit: I’ve created this topic for this instead of “polluting spaces where it doesn’t belong”:
