Hi Gustavo! On 2020. Oct 12., at 18:41, Gustavo Lopes <gust...@sqreen.com> wrote: > > I've incidentally been working on this lately. > > The results of my efforts are here: https://github.com/sqreen/nashorn
Yeah, Sqreen was one of the businesses that indicated they’d need this. > The tests that don't require external js libraries all pass, with some > exceptions: > > * I couldn't get the tests requiring jemmy to pass. IIRC, the original ant > files pointed to some urls of jars that don't exist anymore and I couldn't > find the exact jemmy and jemmyjfx versions expected. Maybe that’s gone for good… > > * Half a dozen sandboxing tests don't pass because they require that nashorn > be loaded on the platform classloader. More precisly, when running with a > security manager and with -Djava.security.properties= pointing to a file > restricting class loading with package.access, it seems to rely on the fact > that the platform classloader doesn't have the call to > SecurityManager::checkPackageAccess that the app classloader has I have maybe 9 test failures in my current working copy, but yeah, the checkPackageAccess issue exists. It also can just be a red herring of there being an explicit addition of Nashorn internal packages to access-checked list. I’ve been trying to figure out what to do about that. > > I haven't worked on the benchmarks. > > Most of the work was moving to gradle. I didn't have to make a lot of changes > to the codebase. I had to change to the Unsafe in sun.misc rather than the > internal one, to change the parent module layer for the scripting JPMS module > created at runtime for when nashorn isn't loaded on the boot layer, then some > tests required small tweaks but I don't remember much else. Hm. It seems to be working fine for me when I put it on --module-path without modifications but I’d be curious as to what are your changes. > I also copied the asm library to avoid having to --add-exports the internal > one, but maybe this can be changed to the mainline asm library. I changed it to mainline ASM, it’ll just declare it as a dependency. > As to the jjs executable, that was not a problem, and some tests require it > anyway, which is why I worked on it. The only difficult was that when built > separately from openjdk, the -J-XXX option is not available, but this can be > worked around with the JDK_JAVA_OPTIONS environment variable. I’ll be curious about that, as I for now haven’t really devoted time to jjs and in fact planned to initially ship the nashorn library without paying much attention to jjs. Do you already have, or can you maybe sign an Oracle Contributor Agreement[1]? That would allow me (and all other OpenJDK projects) to accept contributions from you. Attila. [1] https://www.oracle.com/technical-resources/oracle-contributor-agreement.html
