Mailing List Archive: Remove/Replace Nashorn, Remove Eval

Remove/Replace Nashorn, Remove Eval

Aug 12, 2020, 12:17 AM

Post #1 of 6 (299 views)

Not trying to spam the list, just looking to get feedback about the goings
on in the project and on some of my items before I share my Google Doc,
which is damning, even of my own work and efforts.

This line and subsequent lines concern me:

https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265

We should remove Nashorn and eval from our code base.

One could argue that eval should've been removed eight years ago. Nashorn
should have been removed in 2018 when Oracle announced it w
<https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as
shifting all efforts to GraalVM. Adopting GraalVm, if we feel we need it,
gives the platform many capabilities and much more security that what is
offered by Nashorn. Nashorn is not actively maintained anymore to my
knowledge.

Are there any objections to me removing Nashorn, revisiting adding GraalVM
if we feel we need it, and totally removing eval from the code base. It is
already mostly removed thanks to work from Kevin and Jan, I believe. I
wanted to remove it back in March of 2019, but that's another story for a
different email thread.

Anyway, please advise.

Best,

Marcus Eagan

Re: Remove/Replace Nashorn, Remove Eval [ In reply to ]

ichattopadhyaya at gmail

Aug 12, 2020, 1:29 AM

Post #2 of 6 (298 views)

Permalink

+1 to removing it.
Does the build pass if we remove that line?

On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan <marcuseagan@gmail.com> wrote:

> Not trying to spam the list, just looking to get feedback about the goings
> on in the project and on some of my items before I share my Google Doc,
> which is damning, even of my own work and efforts.
>
> This line and subsequent lines concern me:
>
>
> https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265
>
> We should remove Nashorn and eval from our code base.
>
> One could argue that eval should've been removed eight years ago. Nashorn
> should have been removed in 2018 when Oracle announced it w
> <https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as
> shifting all efforts to GraalVM. Adopting GraalVm, if we feel we need it,
> gives the platform many capabilities and much more security that what is
> offered by Nashorn. Nashorn is not actively maintained anymore to my
> knowledge.
>
> Are there any objections to me removing Nashorn, revisiting adding GraalVM
> if we feel we need it, and totally removing eval from the code base. It is
> already mostly removed thanks to work from Kevin and Jan, I believe. I
> wanted to remove it back in March of 2019, but that's another story for a
> different email thread.
>
> Anyway, please advise.
>
> Best,
>
> Marcus Eagan
>
>

Re: Remove/Replace Nashorn, Remove Eval [ In reply to ]

marcuseagan at gmail

Aug 12, 2020, 1:31 AM

Post #3 of 6 (298 views)

Permalink

I hadn't opened a ticket or PR but would as soon as I receive some support
from the community.

On Wed, Aug 12, 2020 at 1:29 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> +1 to removing it.
> Does the build pass if we remove that line?
>
> On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan <marcuseagan@gmail.com>
> wrote:
>
>> Not trying to spam the list, just looking to get feedback about the
>> goings on in the project and on some of my items before I share my Google
>> Doc, which is damning, even of my own work and efforts.
>>
>> This line and subsequent lines concern me:
>>
>>
>> https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265
>>
>> We should remove Nashorn and eval from our code base.
>>
>> One could argue that eval should've been removed eight years ago.
>> Nashorn should have been removed in 2018 when Oracle announced it w
>> <https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as
>> shifting all efforts to GraalVM. Adopting GraalVm, if we feel we need it,
>> gives the platform many capabilities and much more security that what is
>> offered by Nashorn. Nashorn is not actively maintained anymore to my
>> knowledge.
>>
>> Are there any objections to me removing Nashorn, revisiting adding
>> GraalVM if we feel we need it, and totally removing eval from the code
>> base. It is already mostly removed thanks to work from Kevin and Jan, I
>> believe. I wanted to remove it back in March of 2019, but that's another
>> story for a different email thread.
>>
>> Anyway, please advise.
>>
>> Best,
>>
>> Marcus Eagan
>>
>>

--
Marcus Eagan

Re: Remove/Replace Nashorn, Remove Eval [ In reply to ]

epugh at opensourceconnections

Aug 12, 2020, 3:34 AM

Post #4 of 6 (298 views)

Permalink

Doesn’t the StatelessScriptUpdateProcessorFactory require this? I poked around a bit, and it didn’t seem like there was a direct replacement for Nashorn…. I know lots of folks aren’t fans of it, however I’ve used it many times to solve hard indexing problems.

Someday we’ll have proper pipelines for updates and queries!

> On Aug 12, 2020, at 4:31 AM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> I hadn't opened a ticket or PR but would as soon as I receive some support from the community.
>
>
> On Wed, Aug 12, 2020 at 1:29 AM Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <mailto:ichattopadhyaya@gmail.com>> wrote:
> +1 to removing it.
> Does the build pass if we remove that line?
>
> On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan <marcuseagan@gmail.com <mailto:marcuseagan@gmail.com>> wrote:
> Not trying to spam the list, just looking to get feedback about the goings on in the project and on some of my items before I share my Google Doc, which is damning, even of my own work and efforts.
>
> This line and subsequent lines concern me:
>
> https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265 <https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265>
>
> We should remove Nashorn and eval from our code base.
>
> One could argue that eval should've been removed eight years ago. Nashorn should have been removed in 2018 when Oracle announced it w <https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as shifting all efforts to GraalVM. Adopting GraalVm, if we feel we need it, gives the platform many capabilities and much more security that what is offered by Nashorn. Nashorn is not actively maintained anymore to my knowledge.
>
> Are there any objections to me removing Nashorn, revisiting adding GraalVM if we feel we need it, and totally removing eval from the code base. It is already mostly removed thanks to work from Kevin and Jan, I believe. I wanted to remove it back in March of 2019, but that's another story for a different email thread.
>
> Anyway, please advise.
>
> Best,
>
> Marcus Eagan
>
>
>
> --
> Marcus Eagan
>

_______________________
Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com <http://www.opensourceconnections.com/> | My Free/Busy <http://tinyurl.com/eric-cal>
Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
This e-mail and all contents, including attachments, is considered to be Company Confidential unless explicitly stated otherwise, regardless of whether attachments are marked as such.

Re: Remove/Replace Nashorn, Remove Eval [ In reply to ]

dsmiley at apache

Aug 12, 2020, 9:53 PM

Post #5 of 6 (297 views)

Permalink

That file is only used for javadocs I think? I'm unaware of any actual
_hard dependency_ on Nashorn by Solr. It's provided by the JDK and it's
loaded dynamically at runtime *if* you use that URP with Javascript which
uses the JDK's javax.scripting API which is *not* going away. You can even
plug in GraalVM as a JS impl! This blog explains it well:
https://golb.hplar.ch/2020/04/java-javascript-engine.html

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

On Wed, Aug 12, 2020 at 6:34 AM Eric Pugh <epugh@opensourceconnections.com>
wrote:

> Doesn’t the StatelessScriptUpdateProcessorFactory require this? I poked
> around a bit, and it didn’t seem like there was a direct replacement for
> Nashorn…. I know lots of folks aren’t fans of it, however I’ve used it
> many times to solve hard indexing problems.
>
> Someday we’ll have proper pipelines for updates and queries!
>
>
> On Aug 12, 2020, at 4:31 AM, Marcus Eagan <marcuseagan@gmail.com> wrote:
>
> I hadn't opened a ticket or PR but would as soon as I receive some support
> from the community.
>
>
> On Wed, Aug 12, 2020 at 1:29 AM Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
>
>> +1 to removing it.
>> Does the build pass if we remove that line?
>>
>> On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan <marcuseagan@gmail.com>
>> wrote:
>>
>>> Not trying to spam the list, just looking to get feedback about the
>>> goings on in the project and on some of my items before I share my Google
>>> Doc, which is damning, even of my own work and efforts.
>>>
>>> This line and subsequent lines concern me:
>>>
>>>
>>> https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265
>>>
>>> We should remove Nashorn and eval from our code base.
>>>
>>> One could argue that eval should've been removed eight years ago.
>>> Nashorn should have been removed in 2018 when Oracle announced it w
>>> <https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as
>>> shifting all efforts to GraalVM. Adopting GraalVm, if we feel we need it,
>>> gives the platform many capabilities and much more security that what is
>>> offered by Nashorn. Nashorn is not actively maintained anymore to my
>>> knowledge.
>>>
>>> Are there any objections to me removing Nashorn, revisiting adding
>>> GraalVM if we feel we need it, and totally removing eval from the code
>>> base. It is already mostly removed thanks to work from Kevin and Jan, I
>>> believe. I wanted to remove it back in March of 2019, but that's another
>>> story for a different email thread.
>>>
>>> Anyway, please advise.
>>>
>>> Best,
>>>
>>> Marcus Eagan
>>>
>>>
>
> --
> Marcus Eagan
>
>
> _______________________
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> <http://tinyurl.com/eric-cal>
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

Re: Remove/Replace Nashorn, Remove Eval [ In reply to ]

uwe at thetaphi

Aug 12, 2020, 10:52 PM

Post #6 of 6 (297 views)

Permalink

Hi David,

I agree with you: Unless there's a direct reference in our source code to nashorn, one can use any scripting language (also groovy, ruby, python) if heshe plugs it into class path using the SPI mechanism.

It may only fail test if it's no longer bundled with JDK, but afaik I added an assume for that long ago. Unless it was removed. So only action would be to check this, so tests don't fail with newer JDK.

The reference in the "element"/"package" list is a file from the JDK we provide to generate javadocs. It's unmodified and used as a lookup for packages which can be linked to their website. The file is copied as is to Git and removed from source distribution because of copyright (see source.tgz tasks in Ant). It's there to allow you to generate javadocs in airplane mode. ????

Uwe

Am August 13, 2020 4:53:51 AM UTC schrieb David Smiley <dsmiley@apache.org>:
>That file is only used for javadocs I think? I'm unaware of any actual
>_hard dependency_ on Nashorn by Solr. It's provided by the JDK and
>it's
>loaded dynamically at runtime *if* you use that URP with Javascript
>which
>uses the JDK's javax.scripting API which is *not* going away. You can
>even
>plug in GraalVM as a JS impl! This blog explains it well:
>https://golb.hplar.ch/2020/04/java-javascript-engine.html
>
>~ David Smiley
>Apache Lucene/Solr Search Developer
>http://www.linkedin.com/in/davidwsmiley
>
>
>On Wed, Aug 12, 2020 at 6:34 AM Eric Pugh
><epugh@opensourceconnections.com>
>wrote:
>
>> Doesn’t the StatelessScriptUpdateProcessorFactory require this? I
>poked
>> around a bit, and it didn’t seem like there was a direct replacement
>for
>> Nashorn…. I know lots of folks aren’t fans of it, however I’ve used
>it
>> many times to solve hard indexing problems.
>>
>> Someday we’ll have proper pipelines for updates and queries!
>>
>>
>> On Aug 12, 2020, at 4:31 AM, Marcus Eagan <marcuseagan@gmail.com>
>wrote:
>>
>> I hadn't opened a ticket or PR but would as soon as I receive some
>support
>> from the community.
>>
>>
>> On Wed, Aug 12, 2020 at 1:29 AM Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>>
>>> +1 to removing it.
>>> Does the build pass if we remove that line?
>>>
>>> On Wed, Aug 12, 2020 at 12:48 PM Marcus Eagan
><marcuseagan@gmail.com>
>>> wrote:
>>>
>>>> Not trying to spam the list, just looking to get feedback about the
>>>> goings on in the project and on some of my items before I share my
>Google
>>>> Doc, which is damning, even of my own work and efforts.
>>>>
>>>> This line and subsequent lines concern me:
>>>>
>>>>
>>>>
>https://github.com/apache/lucene-solr/blob/1d2749295b5378db9f54d603b581d1d9a1e3cc93/lucene/tools/javadoc/java11/package-list#L265
>>>>
>>>> We should remove Nashorn and eval from our code base.
>>>>
>>>> One could argue that eval should've been removed eight years ago.
>>>> Nashorn should have been removed in 2018 when Oracle announced it
>w
>>>>
><https://blogs.oracle.com/javamagazine/jep-335-deprecate-the-nashorn-javascript-engine>as
>>>> shifting all efforts to GraalVM. Adopting GraalVm, if we feel we
>need it,
>>>> gives the platform many capabilities and much more security that
>what is
>>>> offered by Nashorn. Nashorn is not actively maintained anymore to
>my
>>>> knowledge.
>>>>
>>>> Are there any objections to me removing Nashorn, revisiting adding
>>>> GraalVM if we feel we need it, and totally removing eval from the
>code
>>>> base. It is already mostly removed thanks to work from Kevin and
>Jan, I
>>>> believe. I wanted to remove it back in March of 2019, but that's
>another
>>>> story for a different email thread.
>>>>
>>>> Anyway, please advise.
>>>>
>>>> Best,
>>>>
>>>> Marcus Eagan
>>>>
>>>>
>>
>> --
>> Marcus Eagan
>>
>>
>> _______________________
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC |
>434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>
><https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> This e-mail and all contents, including attachments, is considered to
>be
>> Company Confidential unless explicitly stated otherwise, regardless
>> of whether attachments are marked as such.
>>
>>

--
Uwe Schindler
Achterdiek 19, 28357 Bremen
https://www.thetaphi.de