From szegedia at gmail.com Fri Nov 1 17:48:14 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 1 Nov 2024 18:48:14 +0100 Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: References: Message-ID: Hi Packiaraj, I suspect a particular issue might be at play here. Specifically, Nashorn used to be able to rely on Unsafe.defineAnonymousClass to use a more lightweight method to load compiled code. This was unfortunately taken away with Java 17. You can test this assumption by running your system on Java 16 and see whether the performance gets restored. Unfortunately, there's not much we can do to fix that. Nashorn will use Unsafe.defineAnonymousClass when available, but on Java 17+ it is no longer. However, you can, in fact, share ScriptEngine instances across threads, and you should prepare all your scripts into CompiledScript instances if you can. What you shouldn't share is Bindings. I wrote about this in some detail in this SO answer: https://stackoverflow.com/a/30159424/131552, and also less comprehensively here: https://stackoverflow.com/a/34122641/131552 Hope this helps. Attila. On Fri, Oct 25, 2024 at 5:21?PM Packiaraj S wrote: > Hello, > > We use Nashorn with Tomcat as a long running service. We recently > migrated to Java 21. ( from java 11 and the performance is good > with Java-11). > Since Nashorn is moved out of JDK we have pulled in ' > *nashorn-core-15.4.jar*' and its dependency (*asm**) and loaded it as a > regular jar. Functionality everything looks ok. > > During the performance test we observed very high cpu usage when nashorn > engine's 'eval' is called. The CPU consumption is so high that instances > are throttled and performance becomes 10x slower compared to java-11. > > Upon investigation using profiler (jvisualVM) looks like most of the CPU > is spent in compile method > , > more specifically during ContextCodeInstaller.initialize > > and NamedContextCodeInstaller.install > > > > Looks like the compile method is optimized with cache, unfortunately the > cache is in context scope, meaning it's not shared between ScriptEngines > and Nashorn is not thread-safe (as per the docs) to use a single instance > of ScriptEngine across all threads. Also the cache uses 'soft-reference', > would it cause double whammy when there is a memory pressure. > > so, how to improve the performance of the Nashorn engine, specifically the > `compile` part. > Is there any other option we can try? BTW, persistent-code-cache did not > help as OptimisticTypesPersistence.getVersionDirName is performing poorly > > Test code that we used to study this high CPU issue is attached. > > Thanks a lot for hemp & any insight > Sakkanan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Fri Nov 1 18:28:49 2024 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 1 Nov 2024 19:28:49 +0100 (CET) Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: References: Message-ID: <363880047.11905208.1730485729711.JavaMail.zimbra@univ-eiffel.fr> > From: "Attila Szegedi" > To: "Packiaraj S" > Cc: "nashorn-dev" > Sent: Friday, November 1, 2024 6:48:14 PM > Subject: Re: High CPU consumption with Java-21 + Nashorn 15.4 > Hi Packiaraj, > I suspect a particular issue might be at play here. Specifically, Nashorn used > to be able to rely on Unsafe.defineAnonymousClass to use a more lightweight > method to load compiled code. This was unfortunately taken away with Java 17. > You can test this assumption by running your system on Java 16 and see whether > the performance gets restored. Unfortunately, there's not much we can do to fix > that. Nashorn will use Unsafe.defineAnonymousClass when available, but on Java > 17+ it is no longer. Hello Attila, you can use not use Lookup.defineHiddenClass(bytes, true, NESTMATE) instead ? https://bugs.openjdk.org/browse/JDK-8266760 > However, you can, in fact, share ScriptEngine instances across threads, and you > should prepare all your scripts into CompiledScript instances if you can. What > you shouldn't share is Bindings. I wrote about this in some detail in this SO > answer: [ https://stackoverflow.com/a/30159424/131552 | > https://stackoverflow.com/a/30159424/131552 ] , and also less comprehensively > here: [ https://stackoverflow.com/a/34122641/131552 | > https://stackoverflow.com/a/34122641/131552 ] > Hope this helps. > Attila. regards, R?mi > On Fri, Oct 25, 2024 at 5:21 PM Packiaraj S < [ mailto:s.packiaraj at gmail.com | > s.packiaraj at gmail.com ] > wrote: >> Hello, >> We use Nashorn with Tomcat as a long running service. We recently migrated to >> Java 21. ( from java 11 and the performance is good with Java-11). >> Since Nashorn is moved out of JDK we have pulled in ' nashorn-core-15.4.jar ' >> and its dependency ( asm *) and loaded it as a regular jar. Functionality >> everything looks ok. >> During the performance test we observed very high cpu usage when nashorn >> engine's 'eval' is called. The CPU consumption is so high that instances are >> throttled and performance becomes 10x slower compared to java-11. >> Upon investigation using profiler (jvisualVM) looks like most of the CPU is >> spent in compile [ >> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L1454 >> | method ] , more specifically during [ >> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L217 >> | ContextCodeInstaller.initialize ] and [ http://namedcontextcodeinstaller./ | >> NamedContextCodeInstaller. ] [ >> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L290 >> | install ] >> Looks like the compile method is optimized with cache, unfortunately the cache >> is in context scope, meaning it's not shared between ScriptEngines and Nashorn >> is not thread-safe (as per the docs) to use a single instance of ScriptEngine >> across all threads. Also the cache uses 'soft-reference', would it cause double >> whammy when there is a memory pressure. >> so, how to improve the performance of the Nashorn engine, specifically the >> `compile` part. >> Is there any other option we can try? BTW, persistent-code-cache did not help as >> OptimisticTypesPersistence.g etVersionDirName is performing poorly >> Test code that we used to study this high CPU issue is attached. >> Thanks a lot for hemp & any insight >> Sakkanan -------------- next part -------------- An HTML attachment was scrubbed... URL: From s.packiaraj at gmail.com Fri Nov 1 18:38:51 2024 From: s.packiaraj at gmail.com (Packiaraj S) Date: Fri, 1 Nov 2024 11:38:51 -0700 Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: References: Message-ID: Thanks Attila. This is the side-effect of Unsafe.defineAnonymousClass removal changes. Just a thought. If script Engine can be shared across threads, would it be possible to make the script ClassCache global, like making classCache as static. That way cache is reused across threads and performance is also improved. I tried this solution and it seems to be working fine, but unfortunately due to Licensing (GPL v2) I am unable to make source code changes. On Fri, Nov 1, 2024 at 10:48?AM Attila Szegedi wrote: > Hi Packiaraj, > > I suspect a particular issue might be at play here. Specifically, Nashorn > used to be able to rely on Unsafe.defineAnonymousClass to use a more > lightweight method to load compiled code. This was unfortunately taken away > with Java 17. You can test this assumption by running your system on Java > 16 and see whether the performance gets restored. Unfortunately, there's > not much we can do to fix that. Nashorn will use > Unsafe.defineAnonymousClass when available, but on Java 17+ it is no longer. > > However, you can, in fact, share ScriptEngine instances across threads, > and you should prepare all your scripts into CompiledScript instances if > you can. What you shouldn't share is Bindings. I wrote about this in some > detail in this SO answer: https://stackoverflow.com/a/30159424/131552, > and also less comprehensively here: > https://stackoverflow.com/a/34122641/131552 > > Hope this helps. > Attila. > > > On Fri, Oct 25, 2024 at 5:21?PM Packiaraj S wrote: > >> Hello, >> >> We use Nashorn with Tomcat as a long running service. We recently >> migrated to Java 21. ( from java 11 and the performance is good >> with Java-11). >> Since Nashorn is moved out of JDK we have pulled in ' >> *nashorn-core-15.4.jar*' and its dependency (*asm**) and loaded it as a >> regular jar. Functionality everything looks ok. >> >> During the performance test we observed very high cpu usage when nashorn >> engine's 'eval' is called. The CPU consumption is so high that instances >> are throttled and performance becomes 10x slower compared to java-11. >> >> Upon investigation using profiler (jvisualVM) looks like most of the CPU >> is spent in compile method >> , >> more specifically during ContextCodeInstaller.initialize >> >> and NamedContextCodeInstaller.install >> >> >> >> Looks like the compile method is optimized with cache, unfortunately the >> cache is in context scope, meaning it's not shared between ScriptEngines >> and Nashorn is not thread-safe (as per the docs) to use a single instance >> of ScriptEngine across all threads. Also the cache uses 'soft-reference', >> would it cause double whammy when there is a memory pressure. >> >> so, how to improve the performance of the Nashorn engine, specifically >> the `compile` part. >> Is there any other option we can try? BTW, persistent-code-cache did >> not help as OptimisticTypesPersistence.getVersionDirName is performing >> poorly >> >> Test code that we used to study this high CPU issue is attached. >> >> Thanks a lot for hemp & any insight >> Sakkanan >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szegedia at gmail.com Fri Nov 1 20:37:56 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 1 Nov 2024 21:37:56 +0100 Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: <363880047.11905208.1730485729711.JavaMail.zimbra@univ-eiffel.fr> References: <363880047.11905208.1730485729711.JavaMail.zimbra@univ-eiffel.fr> Message-ID: Hi Remi, We had a similar discussion[0] almost exactly 4 years ago ? the main problem was that the hidden classes are hidden, so JavaScript errors won't have stack traces anymore? We didn't get an option for a "visible hidden" class since. In any case, I suspect the performance difference is mostly in verification, which Unsafe.defineAnonymousClass didn't run, but I'm fairly sure defineHiddenClass does. Regardless, using a single ScriptEngine mostly remedies the issue. I would still love to get a VISIBLE ClassOption for the hidden classes tho'. Attila. -- [0] https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html On Fri, Nov 1, 2024 at 7:28?PM Remi Forax wrote: > > > ------------------------------ > > *From: *"Attila Szegedi" > *To: *"Packiaraj S" > *Cc: *"nashorn-dev" > *Sent: *Friday, November 1, 2024 6:48:14 PM > *Subject: *Re: High CPU consumption with Java-21 + Nashorn 15.4 > > Hi Packiaraj, > I suspect a particular issue might be at play here. Specifically, Nashorn > used to be able to rely on Unsafe.defineAnonymousClass to use a more > lightweight method to load compiled code. This was unfortunately taken away > with Java 17. You can test this assumption by running your system on Java > 16 and see whether the performance gets restored. Unfortunately, there's > not much we can do to fix that. Nashorn will use > Unsafe.defineAnonymousClass when available, but on Java 17+ it is no longer. > > > Hello Attila, > you can use not use Lookup.defineHiddenClass(bytes, true, NESTMATE) > instead ? > https://bugs.openjdk.org/browse/JDK-8266760 > > > However, you can, in fact, share ScriptEngine instances across threads, > and you should prepare all your scripts into CompiledScript instances if > you can. What you shouldn't share is Bindings. I wrote about this in some > detail in this SO answer: https://stackoverflow.com/a/30159424/131552, > and also less comprehensively here: > https://stackoverflow.com/a/34122641/131552 > > Hope this helps. > Attila. > > > regards, > R?mi > > > > On Fri, Oct 25, 2024 at 5:21?PM Packiaraj S wrote: > >> Hello, >> >> We use Nashorn with Tomcat as a long running service. We recently >> migrated to Java 21. ( from java 11 and the performance is good >> with Java-11). >> Since Nashorn is moved out of JDK we have pulled in ' >> *nashorn-core-15.4.jar*' and its dependency (*asm**) and loaded it as a >> regular jar. Functionality everything looks ok. >> >> During the performance test we observed very high cpu usage when nashorn >> engine's 'eval' is called. The CPU consumption is so high that instances >> are throttled and performance becomes 10x slower compared to java-11. >> >> Upon investigation using profiler (jvisualVM) looks like most of the CPU >> is spent in compile method >> , >> more specifically during ContextCodeInstaller.initialize >> >> and NamedContextCodeInstaller.install >> >> >> Looks like the compile method is optimized with cache, unfortunately the >> cache is in context scope, meaning it's not shared between ScriptEngines >> and Nashorn is not thread-safe (as per the docs) to use a single instance >> of ScriptEngine across all threads. Also the cache uses 'soft-reference', >> would it cause double whammy when there is a memory pressure. >> >> so, how to improve the performance of the Nashorn engine, specifically >> the `compile` part. >> Is there any other option we can try? BTW, persistent-code-cache did >> not help as OptimisticTypesPersistence.getVersionDirName is performing >> poorly >> >> Test code that we used to study this high CPU issue is attached. >> >> Thanks a lot for hemp & any insight >> Sakkanan >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szegedia at gmail.com Fri Nov 1 20:50:40 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 1 Nov 2024 21:50:40 +0100 Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: References:

Message-ID: The idea is that engines can be configured with options when created through the NashornScriptEngineFactory API[0], and options can affect compilation, e.g. you can create an engine with optimistic types on etc. As an example: var factory = new NashornScriptEngineFactory(); var engine = factory.getScriptEngine("--optimistic-types"); This configuration is engine-specific, hence you can't have a global cache. I strongly suggest you create a single engine in your service, and don't even rely on caching behavior in there but rather rather manage your own CompiledScript instances for best performance. Attila. -- [0] https://www.javadoc.io/doc/org.openjdk.nashorn/nashorn-core/latest/org.openjdk.nashorn/org/openjdk/nashorn/api/scripting/NashornScriptEngineFactory.html On Fri, Nov 1, 2024 at 7:39?PM Packiaraj S wrote: > Thanks Attila. This is the side-effect of Unsafe.defineAnonymousClass > removal changes. > > Just a thought. If script Engine can be shared across threads, would it be > possible to make the script ClassCache global, like making classCache > as > static. That way cache is reused across threads and performance is also > improved. I tried this solution and it seems to be working fine, but > unfortunately due to Licensing (GPL v2) I am unable to make source code > changes. > > On Fri, Nov 1, 2024 at 10:48?AM Attila Szegedi wrote: > >> Hi Packiaraj, >> >> I suspect a particular issue might be at play here. Specifically, Nashorn >> used to be able to rely on Unsafe.defineAnonymousClass to use a more >> lightweight method to load compiled code. This was unfortunately taken away >> with Java 17. You can test this assumption by running your system on Java >> 16 and see whether the performance gets restored. Unfortunately, there's >> not much we can do to fix that. Nashorn will use >> Unsafe.defineAnonymousClass when available, but on Java 17+ it is no longer. >> >> However, you can, in fact, share ScriptEngine instances across threads, >> and you should prepare all your scripts into CompiledScript instances if >> you can. What you shouldn't share is Bindings. I wrote about this in some >> detail in this SO answer: https://stackoverflow.com/a/30159424/131552, >> and also less comprehensively here: >> https://stackoverflow.com/a/34122641/131552 >> >> Hope this helps. >> Attila. >> >> >> On Fri, Oct 25, 2024 at 5:21?PM Packiaraj S >> wrote: >> >>> Hello, >>> >>> We use Nashorn with Tomcat as a long running service. We recently >>> migrated to Java 21. ( from java 11 and the performance is good >>> with Java-11). >>> Since Nashorn is moved out of JDK we have pulled in ' >>> *nashorn-core-15.4.jar*' and its dependency (*asm**) and loaded it as a >>> regular jar. Functionality everything looks ok. >>> >>> During the performance test we observed very high cpu usage when nashorn >>> engine's 'eval' is called. The CPU consumption is so high that instances >>> are throttled and performance becomes 10x slower compared to java-11. >>> >>> Upon investigation using profiler (jvisualVM) looks like most of the CPU >>> is spent in compile method >>> , >>> more specifically during ContextCodeInstaller.initialize >>> >>> and NamedContextCodeInstaller.install >>> >>> >>> >>> Looks like the compile method is optimized with cache, unfortunately the >>> cache is in context scope, meaning it's not shared between ScriptEngines >>> and Nashorn is not thread-safe (as per the docs) to use a single instance >>> of ScriptEngine across all threads. Also the cache uses 'soft-reference', >>> would it cause double whammy when there is a memory pressure. >>> >>> so, how to improve the performance of the Nashorn engine, specifically >>> the `compile` part. >>> Is there any other option we can try? BTW, persistent-code-cache did >>> not help as OptimisticTypesPersistence.getVersionDirName is performing >>> poorly >>> >>> Test code that we used to study this high CPU issue is attached. >>> >>> Thanks a lot for hemp & any insight >>> Sakkanan >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From forax at univ-mlv.fr Sat Nov 2 13:18:11 2024 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Sat, 2 Nov 2024 14:18:11 +0100 (CET) Subject: High CPU consumption with Java-21 + Nashorn 15.4 In-Reply-To: References: <363880047.11905208.1730485729711.JavaMail.zimbra@univ-eiffel.fr> Message-ID: <473427509.12727442.1730553491768.JavaMail.zimbra@univ-eiffel.fr> > From: "Attila Szegedi" > To: "Remi Forax" > Cc: "Packiaraj" , "nashorn-dev" > Sent: Friday, November 1, 2024 9:37:56 PM > Subject: Re: High CPU consumption with Java-21 + Nashorn 15.4 > Hi Remi, > We had a similar discussion[0] almost exactly 4 years ago ? the main problem was > that the hidden classes are hidden, so JavaScript errors won't have stack > traces anymore? We didn't get an option for a "visible hidden" class since. In > any case, I suspect the performance difference is mostly in verification, which > Unsafe.defineAnonymousClass didn't run, but I'm fairly sure defineHiddenClass > does. > Regardless, using a single ScriptEngine mostly remedies the issue. I would still > love to get a VISIBLE ClassOption for the hidden classes tho'. Let's prentend my memory is ok, 2020 was a special year :) I think we should try to ask for the VISISBLE classOption again. > Attila. R?mi > -- > [0] [ https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html | > https://mail.openjdk.org/pipermail/nashorn-dev/2020-October/007575.html ] > On Fri, Nov 1, 2024 at 7:28 PM Remi Forax < [ mailto:forax at univ-mlv.fr | > forax at univ-mlv.fr ] > wrote: >>> From: "Attila Szegedi" < [ mailto:szegedia at gmail.com | szegedia at gmail.com ] > >>> To: "Packiaraj S" < [ mailto:s.packiaraj at gmail.com | s.packiaraj at gmail.com ] > >>> Cc: "nashorn-dev" < [ mailto:nashorn-dev at openjdk.org | nashorn-dev at openjdk.org ] >>> > >>> Sent: Friday, November 1, 2024 6:48:14 PM >>> Subject: Re: High CPU consumption with Java-21 + Nashorn 15.4 >>> Hi Packiaraj, >>> I suspect a particular issue might be at play here. Specifically, Nashorn used >>> to be able to rely on Unsafe.defineAnonymousClass to use a more lightweight >>> method to load compiled code. This was unfortunately taken away with Java 17. >>> You can test this assumption by running your system on Java 16 and see whether >>> the performance gets restored. Unfortunately, there's not much we can do to fix >>> that. Nashorn will use Unsafe.defineAnonymousClass when available, but on Java >>> 17+ it is no longer. >> Hello Attila, >> you can use not use Lookup.defineHiddenClass(bytes, true, NESTMATE) instead ? >> [ https://bugs.openjdk.org/browse/JDK-8266760 | >> https://bugs.openjdk.org/browse/JDK-8266760 ] >>> However, you can, in fact, share ScriptEngine instances across threads, and you >>> should prepare all your scripts into CompiledScript instances if you can. What >>> you shouldn't share is Bindings. I wrote about this in some detail in this SO >>> answer: [ https://stackoverflow.com/a/30159424/131552 | >>> https://stackoverflow.com/a/30159424/131552 ] , and also less comprehensively >>> here: [ https://stackoverflow.com/a/34122641/131552 | >>> https://stackoverflow.com/a/34122641/131552 ] >>> Hope this helps. >>> Attila. >> regards, >> R?mi >>> On Fri, Oct 25, 2024 at 5:21 PM Packiaraj S < [ mailto:s.packiaraj at gmail.com | >>> s.packiaraj at gmail.com ] > wrote: >>>> Hello, >>>> We use Nashorn with Tomcat as a long running service. We recently migrated to >>>> Java 21. ( from java 11 and the performance is good with Java-11). >>>> Since Nashorn is moved out of JDK we have pulled in ' nashorn-core-15.4.jar ' >>>> and its dependency ( asm *) and loaded it as a regular jar. Functionality >>>> everything looks ok. >>>> During the performance test we observed very high cpu usage when nashorn >>>> engine's 'eval' is called. The CPU consumption is so high that instances are >>>> throttled and performance becomes 10x slower compared to java-11. >>>> Upon investigation using profiler (jvisualVM) looks like most of the CPU is >>>> spent in compile [ >>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L1454 >>>> | method ] , more specifically during [ >>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L217 >>>> | ContextCodeInstaller.initialize ] and [ http://namedcontextcodeinstaller./ | >>>> NamedContextCodeInstaller. ] [ >>>> https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/Context.java#L290 >>>> | install ] >>>> Looks like the compile method is optimized with cache, unfortunately the cache >>>> is in context scope, meaning it's not shared between ScriptEngines and Nashorn >>>> is not thread-safe (as per the docs) to use a single instance of ScriptEngine >>>> across all threads. Also the cache uses 'soft-reference', would it cause double >>>> whammy when there is a memory pressure. >>>> so, how to improve the performance of the Nashorn engine, specifically the >>>> `compile` part. >>>> Is there any other option we can try? BTW, persistent-code-cache did not help as >>>> OptimisticTypesPersistence.g etVersionDirName is performing poorly >>>> Test code that we used to study this high CPU issue is attached. >>>> Thanks a lot for hemp & any insight >>>> Sakkanan -------------- next part -------------- An HTML attachment was scrubbed... URL: From szegedia at gmail.com Fri Nov 8 07:36:49 2024 From: szegedia at gmail.com (Attila Szegedi) Date: Fri, 8 Nov 2024 01:36:49 -0600 Subject: Nashorn logging and JUL implementations In-Reply-To: <21784a1a-532c-461f-a536-8d3f0b063e60@mailing.copernik.eu> References: <21784a1a-532c-461f-a536-8d3f0b063e60@mailing.copernik.eu> Message-ID: Hi Piotr, Thank you for so thoroughly evaluating the state of logging in Nashorn. Judging from your OSS involvement, you definitely have the right expertise to know what the good practices are for libraries? integration with modern logging. I?d welcome contributions that improve the current situation. By ?welcome? I mean I can promise to treat them with good-faith intent of acceptance subject to discussion and review, of course :-) Hope your OCA came through! Attila. On 27 Oct 2024 at 12:29:55, Piotr P. Karwasz wrote: > Hi all, > > As reported by one of our users[1], there are some issues concerning the > compatibility of Nashorn with alternative `java.util.logging` > implementations. While we can implement a workaround in Log4j, I believe > that a proper solution requires the collaboration of both projects. > > As you are probably aware the standalone `jjs` application provides a > `-log` option[2] that allows users to modify the logging configuration > of the Nashorn Shell. There are however some issues with this code: > > 1. The code is contained in `nashorn-core`, so it will affect all > applications, even those that use Nashorn as a library. I strongly > believe that application developers should be in full control of the > logging configuration, without having libraries modify that > configuration behind their back. > > 2. The code relies on the usage of the `Logger.setLevel()`, > `Logger.addHandler()` and `Logger.setUseParentHandler()` JUL methods. > These methods have no equivalents in pure logging APIs such as Log4j API > and SLF4J and are no-ops. For users of the JUL-to-Log4j API bridge this > means that the `-log` option will be ignored. > > 3. The code relies on the usage of the `Logger.getLevel()` method to > find the **effective** level of a logger. Similarly to the setter > methods, pure logging APIs do not provide a way to find out if a level > configuration was explicitly provided by the user or it was inherited > from the parent logger. While we can fix the coherence between > `setLevel()` and `getLevel()` (see [4]), this looks more like a > workaround to me and Nashorn should probably replace `Logger.getLevel()` > with `Logger.isLoggable()` (the latter will always provide the effective > level). > > 4. Nashorn uses a logger wrapper (`DebugLogger`), which makes all the > location information in the logs point to the `DebugLogger` class itself. > > I can certainly provide help in solving these issues, but before > creating some PRs, I would like to know what the Nashorn team thinks > about changes to the logging code and what directions would be > acceptable for the team. > > Piotr > > [1] https://github.com/apache/logging-log4j2/issues/3119 > > [2] > > https://github.com/openjdk/nashorn/blob/2eb88e4024023ee8e9baacb7736f914e3aa68aa4/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/options/Options.java#L541 > > [3] > > https://github.com/openjdk/nashorn/blob/main/src/org.openjdk.nashorn/share/classes/org/openjdk/nashorn/internal/runtime/logging/DebugLogger.java > > [4] https://github.com/apache/logging-log4j2/pull/3125 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: