> On 2020. Dec 16., at 11:58, Ben Evans <benjamin.john.ev...@gmail.com> wrote: > > Hi Attila, > > This might be being pedantic - but for folks that want to use > standalone Nashorn it is emphatically not the case that they "have not > adopted JPMS": If they're using a Java 9+ runtime then they *have* > adopted JPMS - they're just using a nasty compatibility mode of it to > dump their classpath into UNNAMED.
They certainly took no conscious action to adopt JPMS, rather the runtime is providing them with nonintrusive compatibility behavior. I don’t disagree with you, mind you. I’d rather everybody used --module-path and nobody used -classpath anymore, but pragmatically for lots of folks this might hinder adoption. > > Having said that, if it's just a small amount of code, then maybe it > does make sense to add the conditionals. Done; I put it up for review: <https://github.com/openjdk/nashorn/pull/9> Modularity handling in Nashorn was never really essential functionality, it was rather necessary plumbing that made Nashorn operational under JPMS in the first place – since it itself had to be a module since Java 9 as it was code that shipped in the JDK, there was no escaping this. > I think the bigger part is the SB module dependencies issue - and that > probably does need someone from the SB side to help debug what's going > wrong and where the problem actually comes from. > > Thanks, > > Ben > > On Tue, 15 Dec 2020 at 14:35, Attila Szegedi <szege...@gmail.com> wrote: >> >> Hi Ben, >> >> funnily enough since I posted this I found this newly submitted issue: >> <https://bugs.openjdk.java.net/browse/JDK-8258216> The reporter there argues >> that lots of folks might still be using Nashorn in non-modular applications. >> I think all module handling is restricted to three source files and it’d be >> fairly easy to just add conditionals around it. OTOH I can also see the >> merit in driving people towards more widespread adoption of --module-path :-) >> >> I also agree with you that SB should correctly handle module dependencies, >> but I’m familiar with Nashorn and not familiar with SB, so it’s definitely >> easier for me to take Nashorn from mandatory-JPMS to optionally-JPMS. That >> said, I’m still mulling it over and am open to further discussion. >> >> Attila. >> >>> On 2020. Dec 15., at 14:05, Ben Evans <benjamin.john.ev...@gmail.com> wrote: >>> >>> Hi Attila, >>> >>> I'd like to put forward a counterargument: Why would this be a good >>> use of time? Nashorn SO requires at least Java 15, so it will never >>> need to run on a pre-modular runtime. >>> >>> Rather than spending effort on making it run as a non-modular JAR, I >>> would argue that getting to the bottom of why it's not working with >>> Spring Boot (and potentially providing fixes, whether into Nashorn or >>> SB) is a better use of limited resources - both now and in terms of >>> ongoing maintenance. >>> >>> Cheers, >>> >>> Ben >>> >>> On Tue, 15 Dec 2020 at 12:55, Attila Szegedi <szege...@gmail.com> wrote: >>>> >>>> I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn >>>> as a module, and was wondering if it’d make sense to put some effort into >>>> allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts? >>>> >>>> Attila. >>>> >>
