Renato Athaydes

FYI Nashorn can still be used on Java 17: https://github.com/openjdk/nashorn I've tested that and it works perfectly, as with Java 11, on Java 17. Performance is even quite a lot...

The code in question is this: ```java import jdk.nashorn.api.scripting.NashornScriptEngine; ... (NashornScriptEngine) new ScriptEngineManager().getEngineByName("nashorn"); ``` @grexe Are you using the https://github.com/openjdk/nashorn I posted above with JDK 17? The way I did...

I will try to use a multi-release jar to replace that class with a JDK17 specific one.

Building a multi-release jar was not hard, but it seems the Nashorn library doesn't work at all in Java 17. I tested before but it was a basic check only......

Tested with Zulu and OpenJDK 17.0.2.

False alarm!!! I got it working, there was a Java class that was being called by my JS script which still used the old Nashorn types! [Tiny fix](https://github.com/renatoathaydes/rawhttp/commit/5b51520e72e68001fe320a14b370e3ec894b40a9) and it...

100% GREEN! https://github.com/renatoathaydes/rawhttp/actions/runs/1757883520 The req-in-edit jar is now a multi-release jar, so it works on Java 8 all the way to Java 17+... for any version since Nashorn was removed,...

It's up: https://search.maven.org/artifact/com.athaydes.rawhttp/rawhttp-cli/1.4.0/jar and https://search.maven.org/artifact/com.athaydes.rawhttp/rawhttp-req-in-edit/0.3.0/jar

I decided to not use GraalVM.js for the moment being. As far as I know, JetBrains is using Nashorn, so I will keep using that, specially now that RawHTTP-CLI works...

Hi @dschulten. I agree this functionality is necessary for any proper HTTP server to do the minimum job expected from it... but when I started writing RawHTTP my idea was...