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. > >
