sdedic commented on PR #5842: URL: https://github.com/apache/netbeans/pull/5842#issuecomment-1520540409
> Are there any risks to the module system tweaks? We'll be looking to close off delivery on Wednesday for 18-rc2 - might be good to get this and tested sooner rather than later. For the classloading no - the new code path is only triggered from within GraalSDK module for its operation and for a specific private ClassLoader instance. No other ClassLoader should be affected. As for the `eager` and `autoload` tweaks, there's a slight chance that it changes behaviour, especially the first start - varying on different systems. But it seems easy to test: - there should not be any complaint that a module cannot be enabled in the startup log (except possibly javafx) - if JDK runtime supports javafx, exactly one module (for the runtime platform) should load - it's best to test **without** ergonomic cluster with all standalone modules enabled The fix itself can be easily tested on a network where PAC is present (http://wpad/wpad.dat exists and produces content): - PAC is processed on standard JDK - PAC is processed on GraalVM JDK **without** javascript installed - PAC is processed on GraalVM JDK **with** javascript installed (these situations are covered by unit tests for `libs.graalsdk` and `libs.graalsdk.system` modules -- 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
