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 <[email protected]>: >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 ><[email protected]> >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 <[email protected]> >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 < >> [email protected]> 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 ><[email protected]> >>> 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
