RFC: enable demodularized operation?

[Attila Szegedi]

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.evans at 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 <szegedia at 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.
>>