RFC: enable demodularized operation?

[Attila Szegedi]

> On 2020. Dec 16., at 11:58, Ben Evans <benjamin.john.evans at 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 <szegedia at 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.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.
>>>> 
>>