matthiasblaesing commented on PR #7248: URL: https://github.com/apache/netbeans/pull/7248#issuecomment-2052321651
> I do not entirely think that GraalVM is an 'exerimental' technology ... I consider GraalVM stable once project Galahad (integration into the JDK) has happend and the first LTS JDK with that technology is out. I'm still irritated, that Nashorn was dropped before the replacement was ready. > but anyway, I think there are still some issues: > > * published module (libs.truffleapi) is dropped that declares **public** packages, which might break some projects. This should be done for a reason only and if, then `module_auto_deps` should be used to maintain binary compatibility. I ran sigtest - and the signature of the module changed in an incompatible way. So the release major version of the module would go up and thus dependencies will break anyway. I would also assume, that it will break again in the next few years, until the technology is stable. > * drops the possibility to go along two paths: consume JDK services and provide bundled ones; this is because drop of `libs.graalsdk.system` from the start. Reasons not well explained. If it can be fixed, it would be fair to drop this "dichotomy" when GraalVM for JDK 17 goes EOL or NB stops supporting JDK17, whichever comes first. My reasoning: I have limited time and release of NB 22 is planed in the not too distant future. To me the question was: Support OpenJDK 22 or GraalVM 17. Supporting the current JVM is IMHO more important, that a VM with experimental extensions. This was the state I could reach with my resources. I never claimed, that it was the best/right approach. > I'll make a parallel experiment that does not drop this ... to see if it is workable and if it is not more hacky than the current state. Conceptual issues of this approach (supporting language injection from JDK) can be discussed here. I would prefer a better solution, so it would be great if you could come up with one. :laughing: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
