"null" value is wrapped as Undefined.

Is there a way to prevent this automatic wrapping? In the following line, "oh.customAttribute4" is null, and it's passed into isBlank() as "Undefined". And that triggers the ClassCastException. This works fine in JDK 1.8.0_91, but fails in all future versions. Is there an optional parameter or

Nashorn internal objects and assessing memory leaks

Hi ... I'm trying to assess a potential memory leak in my system that heavily uses Nashorn. When I start up a relatively simple environment (simple in terms of usage compared to our prod env), I quickly see a lot of nashorn stuff. For example: object count total sizeclass name

Re: Nashorn Standalone 15.3 engine returned is null

Can you check if this is specific to 15.3, or does it also not work with e.g. 15.2? Attila. > On 2021. Jul 15., at 12:49, Andreas Mueller wrote: > > Tested it again with listing the engine right befor getByName: > > List factories = manager.getEngineFactories(); > for (int i = 0; i <

Re: Nashorn Standalone 15.3 engine returned is null

Tested it again with listing the engine right befor getByName: List factories = manager.getEngineFactories(); for (int i = 0; i < factories.size(); i++) {     ctx.logSwiftlet.logInformation(ctx.streamsSwiftlet.getName(), "name=" + factories.get(i).getEngineName() +             ", version=" +

Re: Nashorn Standalone 15.3 engine returned is null

Here are the jar files I use: am@Mac-mini scripts % ll ../nashorn total 4968 -rwxr-xr-x  1 am  staff   121836 Jul 11 14:31 asm-7.3.1.jar -rwxr-xr-x  1 am  staff    33446 Jul 11 14:31 asm-analysis-7.3.1.jar -rwxr-xr-x  1 am  staff    71548 Jul 11 14:31 asm-commons-7.3.1.jar -rwxr-xr-x  1 am  staff

Re: Nashorn Standalone 15.3 engine returned is null

Hi Attila, thanks but didn’t work in my environment.  Tried every combination (using “nashorn”, “JavaScript” as name, using class path, using module path).  Fact is, it lists the Nashorn engine correctly: ScriptEngineManager manager = new ScriptEngineManager(); List factories =

Nashorn Standalone 15.3 engine returned is null

Hi, I’ve added Nashorn to Java 15 and it is properly displayed when listing the engines: 2021-07-13 15:14:30.233/sys$streams/INFORMATION/starting, available Scripting Engines: 2021-07-13 15:14:30.246/sys$streams/INFORMATION/name=OpenJDK Nashorn, version=15.3, language name=ECMAScript,

Re: Nashorn Standalone 15.3 engine returned is null

I’m honestly not sure. I have this very small test program: import javax.script.*; public class X { public static void main(String[] args) throws ScriptException { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine engine =

JDK-8229011 update?

Hello, A year ago I was asking for help with JDK-8229011 (https://mail.openjdk.java.net/pipermail/nashorn-dev/2020-July/007546.html) , but the bug ticket was deprioritized because Nashorn was to be removed soon. With the move to standalone, I thought I would give this another try. Unfortunatly

How to read the content of a HTTP request via Nashorn Javascript?

I’m writing some JavaScript for Nashorn under Java 8. I try to read the content from a URL. So far I can create the (Java) URLConnection object in JavaScript via ``` var con = new java.net.URL(theUrl).openConnection() con.requestMethod = "GET" ``` But how can I do the `getInputStream` call

Re: Nashorn 15.3 is out

On 01.07.2021 13:32, Attila Szegedi wrote: > Hey all, > > I just released Nashorn 15.3[0]. Check the change log[1] to easily see what’s > new. > > The most notable change is that Nashorn now works with JDK 17. > > Attila. > > [0] >

Nashorn 15.3 is out

Hey all, I just released Nashorn 15.3[0]. Check the change log[1] to easily see what’s new. The most notable change is that Nashorn now works with JDK 17. Attila. [0] https://search.maven.org/artifact/org.openjdk.nashorn/nashorn-core/15.3/jar [1]

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

> From: "Attila Szegedi" > To: "Remi Forax" > Cc: "nashorn-dev" > Sent: Mardi 29 Juin 2021 00:37:56 > Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17? >> On 2021. Jun 28., at 19:30, Remi Forax < [ mailto:fo...@univ-mlv.fr | >> fo...@univ-mlv.fr ] > wrote: >> In

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

> On 2021. Jun 28., at 19:30, Remi Forax wrote: > > > In the meantime, I think you can use Lookup.defineClass() or do you rely on > the weird security model of the anonymous classes ? Thankfully, no. Nashorn regenerates code for the same function sometimes so it was convenient having old

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

- Original Message - > From: "Attila Szegedi" > To: "nashorn-dev" > Cc: "Greg Watts" > Sent: Lundi 28 Juin 2021 19:07:38 > Subject: Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17? > Hi Greg, > > that’s a consequence of Java 17 removing the

Re: Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

Hi Greg, that’s a consequence of Java 17 removing the Unsafe.defineAnonymousClass method. Unfortunately, we don’t have an ideal replacement for it yet. MethodHandles.Lookup.defineHiddenClass is supposed to be a publicly supported replacement, but it hides the generated classes from stack

Does Nashorn (org.openjdk.nashorn) have any support for Java 17?

Dear Nashorn development team, I am trying to run an ANT build of our product using nashorn-core:15.1.1.jar with Java 17 (pre-release - build 27) and I get: BUILD FAILED java.lang.ExceptionInInitializerError at org.openjdk.nashorn.internal.runtime.Context.compile(Context.java:1509) at

Re: JDK Dynalink only works with unconditionally exported packages

On 2021. May 11., at 1:51, Thiago Henrique Hupner wrote: > > Hi all. > > I've been testing the JDK Dynalink recently and > I think I've found a bug. > > The class jdk.dynalink.beans.CheckRestrictedPackage checks > if a package is restricted. > > So, I have a class that has some static

JDK Dynalink only works with unconditionally exported packages

Hi all. I've been testing the JDK Dynalink recently and I think I've found a bug. The class jdk.dynalink.beans.CheckRestrictedPackage checks if a package is restricted. So, I have a class that has some static methods. But to Dynalink find the class, the class needs to be public. OK, I've

Re: ECMAScript 6 through the ScriptEngineManager

I’ve also been considering this idea. FWIW, there are some incompatibilities between ES5 and ES6. Most people wouldn’t ever encounter these as they typically make some things work in ES6 that wouldn’t work in ES6 For example, there’s a bunch of methods on Object prototype that in ES5 throw a

Re: ECMAScript 6 through the ScriptEngineManager

Hi Attila, On 29.03.2021 19:29, Attila Szegedi wrote: > today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements > the full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6. > Mostly for compatibility purposes though, it defaults to ES5 and ES6 features > aren’t

ECMAScript 6 through the ScriptEngineManager

Hi folks, today the most used ECMAScript version is 6 (ES6); Nashorn OTOH implements the full ECMAScript 5.1 (ES5) specification and also a subset[0] of 6. Mostly for compatibility purposes though, it defaults to ES5 and ES6 features aren’t enabled by default. So, the problem I’d like to

What do Source, LinkerCallSite, and PropertyMap instances correspond to?

Hi all - My software currently uses Nashorn heavily. We've been trying to keep track of our memory usage but recently we've noticed major bloat. We did a memory analysis to see where stuff is and we found that instances of jdk.nashorn.internal.runtime.Source and

Ad "Re: Run servlets on Nashorn written in server-side JavaScript" ...

As this may be interesting for the Nashorn community as well FYI: Forwarded Message Subject:Re: Run servlets on Nashorn written in server-side JavaScript Date: Sun, 28 Feb 2021 17:33:22 +0100 From: Rony G. Flatscher Reply-To: Tomcat Users

Re: Terminate running script thread

- Mail original - > De: "Attila Szegedi" > À: "Viktor Remennik" > Cc: "nashorn-dev" > Envoyé: Samedi 27 Février 2021 18:07:55 > Objet: Re: Terminate running script thread Hi, > No, there’s no support for that. Nashorn compiles all scripts to JVM bytecode > and runs them as such.

Re: Terminate running script thread

Thanks, by all means report back with what you found :-) Attila. > On 2021. Feb 27., at 18:59, Viktor Remennik wrote: > > I didn’t checked it yet, just wanted to ask first. It is implemented in > graal, will look there to check how. The first idea i thought, was to inject > some global var

Re: Terminate running script thread

I didn’t checked it yet, just wanted to ask first. It is implemented in graal, will look there to check how. The first idea i thought, was to inject some global var checking in loops, but i am not a big specialist in that area yet. Will study it further then, thank you! Kind regards, Viktor >

Re: Terminate running script thread

No, there’s no support for that. Nashorn compiles all scripts to JVM bytecode and runs them as such. There’s no more of a way to stop that code than any Java code. Even if there was some other way, I don’t see how would stopping a thread be materially better than what Thread#stop provides. I’m

Terminate running script thread

Is there already a way to terminate a running script? I found some old discussions and articles regarding it, is there any progress these days? It would be great to have something like CompiledScript#stop or something like interrupt handler inside the Nashorn eval, because currently I have to

Re: Question ad "arguments" and ScriptEngine.ARGV

Keep forgetting, that adding boldness breaks the text. Here the JSP text without any styling (hence without those injected asterisks): <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %> <%@ taglib uri="/WEB-INF/script-jsr223.tld" prefix="s" %>

Question ad "arguments" and ScriptEngine.ARGV

While using Nashorn from Java 8 in the context of a Java based web server for which I authored a tag library for scripting engines, I noted that "arguments" does not get set to the arguments passed via the engine ScriptContext [1] entry ScriptEngine.ARGV [2] (i.e. "javax.script.argv" a single

Re: Lowering minimum runtime requirement to Java 11

On 09.02.2021 21:03, Attila Szegedi wrote: There’s one minor point to consider: should it be compiled with Java 15 compiler, but targeting 11, or should it simply be compiled with Java 11 compiler? Is there any advantage in using javac from 15 targeting 11? I think it's usually better to

Lowering minimum runtime requirement to Java 11

Hey folks, for uniformity, some users would prefer to be able to ship standalone Nashorn with earlier Java versions. Now, I’ve known for some time now that the code compiles cleanly and all tests pass on Java 11 – that’s as far in the past we can reasonably go. Java 8 is unfortunately a no-go,

Nashorn 15.1 is out

Hey all, I just released Nashorn 15.1[0]. We also have a change log[1] now where you can easily see what’s new. The biggest change is that Nashorn can now function when loaded through classpath instead of module path. I could confirm with my little test application that this solves the issue

Re: Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

Hi, thanks for reporting this. I filed a JBS issue[0] and I have a PR[0] to fix it put up. It’ll go into the next Nashorn release. Thanks, Attila. [0] https://bugs.openjdk.java.net/browse/JDK-8258787 [1] https://github.com/openjdk/nashorn/pull/11 > On 2020. Nov 23., at 17:20, Rony G.

Re: Some Nashorn PRs need review love

Thank you! I have since added testing for non-modular Nashorn (details on the PR.) > On 2020. Dec 17., at 7:36, sundararajan.athijegannat...@oracle.com wrote: > > Hi, > > Approved 4 out of 5. Clarification sought for 1 > > Thanks, > > -Sundar > > On 17/12/20 2:40 am, Attila Szegedi wrote:

Re: Some Nashorn PRs need review love

Hi, Approved 4 out of 5. Clarification sought for 1 Thanks, -Sundar On 17/12/20 2:40 am, Attila Szegedi wrote: I have several Nashorn PRs up for review; I started working my way through the JBS bug tracker. If anyone with OpenJDK reviewer privileges feels like helping, you can contribute a

Re: RFC: enable demodularized operation?

> On 2020. Dec 16., at 11:58, Ben Evans wrote: > > Hi Attila, > > This might be being pedantic - but for folks that want to use > standalone Nashorn it is emphatically not the case that they "have not > adopted JPMS": If they're using a Java 9+ runtime then they *have* > adopted JPMS -

Some Nashorn PRs need review love

I have several Nashorn PRs up for review; I started working my way through the JBS bug tracker. If anyone with OpenJDK reviewer privileges feels like helping, you can contribute a review. Three of the five are quite trivial few-liners. Thanks! Attila.

Re: RFC: enable demodularized operation?

Hi Attila, This might be being pedantic - but for folks that want to use standalone Nashorn it is emphatically not the case that they "have not adopted JPMS": If they're using a Java 9+ runtime then they *have* adopted JPMS - they're just using a nasty compatibility mode of it to dump their

RE: Bug in extractVarNodesFromDeadCode. Variable "x" has already been declared

Hi. Since Nashorn is in development again, perhaps this bug (https://bugs.openjdk.java.net/browse/JDK-8233195) can be fixed instead of "Won't Fix" resolution? -Original Message- From: nashorn-dev [mailto:nashorn-dev-boun...@openjdk.java.net] On Behalf Of Hannes Wallnofer Sent: Wednesday,

Re: RFC: enable demodularized operation?

Hi Ben, funnily enough since I posted this I found this newly submitted issue: The reporter there argues that lots of folks might still be using Nashorn in non-modular applications. I think all module handling is restricted to three source

Re: RFC: enable demodularized operation?

Hi Attila, I'd like to put forward a counterargument: Why would this be a good use of time? Nashorn SO requires at least Java 15, so it will never need to run on a pre-modular runtime. Rather than spending effort on making it run as a non-modular JAR, I would argue that getting to the bottom of

RE: RFC: enable demodularized operation?

Dear Attila, Nice to meet you. I'm working for Yokogawa, and we're using JDK11 and Nashorn in one of our products. Our code has not adopted the java module system. They probably do that for next release (I'm not sure). We're not using spring-boot. We're using the script engine as part of

RFC: enable demodularized operation?

I’ve been thinking about the issue where Spring Boot isn’t loading Nashorn as a module, and was wondering if it’d make sense to put some effort into allowing Nashorn to operate when loaded as a non-modular JAR. Thoughts? Attila.

RFR: 8258147: Modernize Nashorn code

Hey folks, the openjdk bot for sending automated RFR emails based on PRs doesn’t work yet (Skara folks should be looking into it) so in the meantime I’ll just post PR links here for awareness: I have a PR that’s essentially code modernization from Nashorn’s mostly Java 7(!!) compliant source

Re: Nashorn + Spring Boot; help appreciated

Thanks Remi, although I don’t think that’s it. To wit, if I write a minimal executable example: --- import javax.script.*; public class X { public static void main(String[] args) throws ScriptException { ScriptEngineManager factory = new ScriptEngineManager(); ScriptEngine

Re: Nashorn + Spring Boot; help appreciated

Hi Attila, for compatibility, you have to both use the new module-info descriptor and the old META-INFO/services when you declare a service. It's a shame that jar doesn't do that by itself, it was something we (module/jigsaw EG) discussed but it was never implemented. regards, Rémi - Mail

Nashorn + Spring Boot; help appreciated

Hey folks, seems like folks are trying to use standalone Nashorn with Spring Boot, and are running into an issue where Boot doesn’t load Nashorn as a JPMS module. If anyone has expertise with this (Spring Boot loading app dependencies as JPMS modules) and can help it’d be most appreciated. I

Re: Standalone Nashorn 15.0 is out!

Congrats Attila! -Sundar On 28/11/20 12:06 am, Attila Szegedi wrote: Hey everyone, I’m happy to announce that the first standalone version of Nashorn, 15.0 is now available on Maven Central[0]! This version of Nashorn requires minimum of Java 15 to run. If you want to use Nashorn on older

Re: Standalone Nashorn 15.0 is out!

Congrats and Thank you! On Fri, Nov 27, 2020 at 4:28 PM Jamie Mansfield wrote: > Hey Attila, > > Congrats to you and team, fab news to see Nashorn back! Great effort > from you to get us here, and you have my thanks for that :) > > Best regards, > Jamie > > >

Re: Standalone Nashorn 15.0 is out!

Hey Attila, Congrats to you and team, fab news to see Nashorn back! Great effort from you to get us here, and you have my thanks for that :) Best regards, Jamie

Re: Standalone Nashorn 15.0 is out!

Congrats!  On Fri, Nov 27, 2020 at 12:36 PM Attila Szegedi wrote: > Hey everyone, > > I’m happy to announce that the first standalone version of Nashorn, 15.0 > is now available on Maven Central[0]! > > This version of Nashorn requires minimum of Java 15 to run. If you want to > use Nashorn

Standalone Nashorn 15.0 is out!

Hey everyone, I’m happy to announce that the first standalone version of Nashorn, 15.0 is now available on Maven Central[0]! This version of Nashorn requires minimum of Java 15 to run. If you want to use Nashorn on older Java version, just use the version bundled with the JDK, this version

Re: Standalone Nashorn bound to specific JVM flavors?

I’m happy to expend some effort to make it compatible with other JVMs that people want to use. It’s also entirely possible that there’s nothing specific to do! There’s nothing in Nashorn that depends on HotSpot. Nashorn is written in Java, it generates bytecode, and uses invokedynamic and

Re: Standalone Nashorn bound to specific JVM flavors?

- Mail original - > De: "BURRIS Thomas" > À: "Attila Szegedi" > Cc: "nashorn-dev" > Envoyé: Lundi 23 Novembre 2020 18:32:37 > Objet: RE: Standalone Nashorn bound to specific JVM flavors? > Hi Attila -- Just to clarify to make sure I understand... So the target JVM > flavor for

RE: Standalone Nashorn bound to specific JVM flavors?

Hi Attila -- Just to clarify to make sure I understand... So the target JVM flavor for compatibility with Standalone Nashorn will be HotSpot? And -- at least at the moment -- there are no explicit plans to make compatible with (for example) OpenJ9 (aside from turning off anon-classes)? As for

Re: Standalone Nashorn bound to specific JVM flavors?

It has exactly one dependency on sun.misc.Unsafe - a call to defineAnonymousClass. I’m not aware if that’s available on other JVMs or not, but that might be the only issue I’m aware of. FWIW, Nashorn can be used with --anonymous-classes=false to turn this feature off (it’s a bit of an

Standalone Nashorn bound to specific JVM flavors?

Hi Attila (et. al.) - is there a pre-requisite between the "standalone" Nashorn and the origin of the JVM ? For example, would it possible to run the future stand-alone Nashorn and AdoptOpenJDK with OpenJ9 (rather than HotSpot) ? Best Regards, Thomas BURRIS RDF Modeling R Software

Fix for NashornScriptEngineFactory.getOutputStatement(toDisplay) (Re: Standalone Nashorn is coming for Java 15+

Hi there, the NashornScriptEngineFactory.getOutputStatement() does not create a valid String from the toDisplay argument. As a result it is not possible to create correct Javascript statements that output strings created with that method (Nashorn creates an exception when running a statement

Re: Standalone Nashorn is coming for Java 15+

Hey ;) > I don’t know how does Gradle stack up against Maven when it comes to > signing and publishing artifacts. Gradle includes a 'signing' plugin [1] and a 'maven-publish' plugin [2] that can be combined [3] to provide sufficient metadata for the Central repository. While I'm no expert, I'm

Re: Standalone Nashorn is coming for Java 15+

Thanks Ben, FWIW, I just gave up on using Ivy in the PR; the behavior between 2.4.0 and 2.5.0 changed significantly and I decided the added value of Ivy is not proportional to the newly arisen headaches. I absolutely want to move away from Ant; once 15.0 is out I’d like to switch to either

Re: Standalone Nashorn is coming for Java 15+

Thanks Isaiah - I totally missed that point in the thread. I'll hit up some Ivy folks I know and see if they're interested in helping with this. Ben On Tue, 17 Nov 2020 at 12:50, Isaiah Peng wrote: > > FYI, the reason for using Any is specified in the thread: > > > I still need to figure out

Re: Standalone Nashorn is coming for Java 15+

FYI, the reason for using Any is specified in the thread: > I still need to figure out the minimal descriptive pom.xml (dependencies etc., no build information) in order to be able to produce Maven artifacts. Right now, Nashorn’s build and test process is highly customized set of Ant build.xml

Re: Standalone Nashorn is coming for Java 15+

Thanks for all the work you've done on this, Attila. Quick question: The project still seems to be using Ant. Is there a reason for that? Would you merge a PR that ported the build system to Maven or Gradle instead? (and if so, do you have a preference for either one?) IME, Ant is rather

Re: Standalone Nashorn is coming for Java 15+

For anyone who doesn’t want to build this from sources themselves, but want to try it, I put a preliminary prebuilt version in my Dropbox at Attila. > On 2020. Nov 15., at 18:25, Attila Szegedi wrote: > > Hi y’all, > >

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, openjdk/nashorn repo is up and its main branch is populated with the initial copy of Nashorn as it existed in JDK 14. I added a fix for wrong/missing licenses for two files (agreed with Oracle) and an initial project README on top of it. An even better news is that I have the

java.lang.NoSuchMethodException: No such function

I recently found a strange problem, I used code similar to the following in the project: public static void main(String[] args) throws ScriptException, NoSuchMethodException { ScriptEngineManager scriptEngineManager = new ScriptEngineManager(); ScriptEngine engine =

Re: Standalone Nashorn is coming for Java 15+

+1 On Sun, Oct 25, 2020 at 5:18 PM Peter Ansell wrote: > Hi Atilla, > > Nashorn-15 seems intuitive to me. > > Thanks for the regular updates! > > Peter > > On Mon, 26 Oct 2020 at 04:08, Attila Szegedi wrote: > > > > Hi y’all, > > > > trying to get into the habit of making these weekly updates

Re: Standalone Nashorn is coming for Java 15+

Hi Atilla, Nashorn-15 seems intuitive to me. Thanks for the regular updates! Peter On Mon, 26 Oct 2020 at 04:08, Attila Szegedi wrote: > > Hi y’all, > > trying to get into the habit of making these weekly updates until I have > something else to show. > > * With Remi’s, Sundar’s and Mandy’s

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, trying to get into the habit of making these weekly updates until I have something else to show. * With Remi’s, Sundar’s and Mandy’s help I fixed anonymous code loading. We’ll be using the sun.misc.Unsafe for now, with hope to transition to Lookup.defineHiddenClass somewhere down

Re: Standalone Nashorn is coming for Java 15+

Given that we use "anonymous class" for JS "evals",  a level of indirection won't hurt here. i.e., a Eval class instance (with instance would report name like "" ) that uses "hidden class" Lookup may work. -Sundar On 19/10/20 9:41 pm, fo...@univ-mlv.fr wrote: - Mail original - De:

Re: Standalone Nashorn is coming for Java 15+

On 10/19/20 11:44 AM, Remi Forax wrote: Hi Attila, * for now, I disabled anonymous code loading. It’s a funny one. Nashorn has a feature called “anonymous code loading”

Re: Standalone Nashorn is coming for Java 15+

> De: "Attila Szegedi" > À: "remi forax" > Cc: "nashorn-dev" , "mandy chung" > > Envoyé: Lundi 19 Octobre 2020 20:28:53 > Objet: Re: Standalone Nashorn is coming for Java 15+ >> On 2020. Oct 19., at 18:06, Remi Forax < [ mailto:remi.fo...@univ-eiffel.fr | >> remi.fo...@univ-eiffel.fr ] >

Re: Standalone Nashorn is coming for Java 15+

> On 2020. Oct 19., at 18:06, Remi Forax wrote: > > - Mail original - >> De: "Attila Szegedi" mailto:szege...@gmail.com>> >> À: "nashorn-dev" > > >> Envoyé: Lundi 19 Octobre 2020 17:16:55 >> Objet: Re: Standalone Nashorn is coming for Java 15+ > >>

Re: Standalone Nashorn is coming for Java 15+

- Mail original - > De: "Attila Szegedi" > À: "nashorn-dev" > Envoyé: Lundi 19 Octobre 2020 17:16:55 > Objet: Re: Standalone Nashorn is coming for Java 15+ > Hi y’all, Hi Attila, > > a quick update with regard of what’s been happening since the last post. > > * I’m talking with folks

Re: Standalone Nashorn is coming for Java 15+

Hi y’all, a quick update with regard of what’s been happening since the last post. * I’m talking with folks at Oracle about setting up the openjdk/nashorn repo. We’re hashing out what the initial content of the repo should be. * The licensing for the standalone Nashorn is confirmed to be

Maven central artifact

Hi there! Just a thought: I, for one, would love to see maven central artifacts with this new standalone Nashorn as one of the earlier priorities. I think we could transfer our Nashorn dependent apps very easily that way. (Yes, we are still a long way away from Java 14 and onwards, I know, but

Re: Stand-alone Nashorn licensing

I am not considering moving Nashorn to Apache. As to the why: I believe OpenJDK is a very robust open source organization with a good governance model. Nashorn already exists as a project in OpenJDK, and it was a natural choice to continue its development within its existing organization.

Re: Stand-alone Nashorn licensing

Not sure what you mean by “derailed probe.” Are you saying in the past you tried to move Nashorn to the Apache Software Foundation? Or you tried to get Nashorn to be licensed under the Apache license? In any case, I’m not aware of any such past efforts. Attila. > On 2020. Oct 14., at 15:49,

Re: Stand-alone Nashorn licensing

I’m talking with folks within Oracle about this topic. My assumption is that the code being lifted out of the jdk project doesn’t change its licensing, so it should continue to be GPL Version 2 with Classpath exception. A past example of a project similarly spun off from jdk was JavaFX and that

Stand-alone Nashorn licensing

Hi Attila (et. al.) - This is, indeed, good news. What specific license do you intend to release the stand-alone Nashorn under? After having been burnt by Oracle with the removal, it'd be very useful to know the targeted license. Best Regards, Thomas BURRIS RDF Modeling R Software

Re: Standalone Nashorn is coming for Java 15+

Thank you for working on Nashorn Attila. We use it extensively. Not sure what exactly we can contribute, but willing to help if we can. Thanks, Tony On Mon, Oct 12, 2020 at 9:05 AM Attila Szegedi wrote: > Hi Anamitra, > > yes, that is the exact intent of this initial standalone Nashorn

Re: Standalone Nashorn is coming for Java 15+

> On 2020. Oct 12., at 19:19, Gustavo Lopes wrote: > > On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi wrote: >> >> On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: >>> >>> * Half a dozen sandboxing tests don't pass because they require that >>> nashorn be loaded on the platform

Re: Standalone Nashorn is coming for Java 15+

On Mon, Oct 12, 2020 at 5:54 PM Attila Szegedi wrote: > > On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: > > > > * 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

Re: Standalone Nashorn is coming for Java 15+

> On 2020. Oct 12., at 18:41, Gustavo Lopes wrote: > > I had to change to the Unsafe in sun.misc rather than the internal one Yeah, forgot to address this one… So that is used for “anonymous code loading” which is an optional feature and I think for the first cut, I might just disable it.

Re: Standalone Nashorn is coming for Java 15+

Hi Gustavo! On 2020. Oct 12., at 18:41, Gustavo Lopes 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

Re: Standalone Nashorn is coming for Java 15+

I've incidentally been working on this lately. The results of my efforts are here: https://github.com/sqreen/nashorn 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

Re: Standalone Nashorn is coming for Java 15+

Hi Anamitra, yes, that is the exact intent of this initial standalone Nashorn release work. A minor point though where you mention “java application path": Nashorn used to be a JDK module, and it only works properly when put on the module path. But as long as you put it in the --module-path,

Re: New Nashorn Project Lead: Attila Szegedi

+100 from me as well. Thank you, Attilla, for picking up the torch. > On 12 Oct 2020, at 11:46, sundararajan.athijegannat...@oracle.com wrote: > > +100 :) Congrats Attila! > > -Sundar > > On 12/10/20 3:10 pm, Hannes Wallnoefer wrote: >> Excellent news, Attila! >> >> I couldn’t think of a

Re: New Nashorn Project Lead: Attila Szegedi

+100 :) Congrats Attila! -Sundar On 12/10/20 3:10 pm, Hannes Wallnoefer wrote: Excellent news, Attila! I couldn’t think of a better person for this task than you. I’m glad there is a future for Nashorn, and I hope I’ll be able to contribute something to the project somewhere down the road.

Re: New Nashorn Project Lead: Attila Szegedi

Excellent news, Attila! I couldn’t think of a better person for this task than you. I’m glad there is a future for Nashorn, and I hope I’ll be able to contribute something to the project somewhere down the road. Hannes > Am 11.10.2020 um 09:26 schrieb Attila Szegedi : > > Thank you,

Standalone Nashorn is coming for Java 15+

Folks, some good news for y'all (presumably you're on this mailing list because you are interested in Nashorn.) Since Nashorn's removal from JDK starting with Java 15, numerous people have realized that they, in fact, rely on it. To remedy the situation, Nashorn will continue as a standalone

Re: New Nashorn Project Lead: Attila Szegedi

Thank you, Vladimir! I accept the nomination[1]. Attila. [1] I read the Bylaws and they do not seem to require the candidate to declare whether they accept – or even agree with – the nomination. While I wouldn’t think anyone would ever nominate a candidate without their consent, I still

Re: Resigning as OpenJDK Nashorn Project Lead

Thank you Jim for creating Nashorn and shepherding it through the years. I remember when I joined the project that I was impressed with the quality of the original code I found there, as well as your eagerness to always help us get up to speed on it. Thanks in big part to you, it was very easy

New Nashorn Project Lead: Attila Szegedi

I hereby nominate Attila Szegedi [1] as new Nashorn Project Lead. Attila was a significant contributor to Nashorn, beginning with the introduction of the dynalink library[2]. According to the Bylaws [3] after current Project Lead resign [4] new Project lead should be nominated. As Group Lead

Re: Resigning as OpenJDK Nashorn Project Lead

Could you elaborate? I worked on both Rhino and Nashorn and have been a project admin for Rhino for a while. So did Hannes. And yet us having worked on both is the only relation between the two I can see. They certainly don’t share code and I don’t think Rhino is in any form an “original” of

Re: Resigning as OpenJDK Nashorn Project Lead

On 10/5/20 10:17 PM, sundararajan.athijegannat...@oracle.com wrote: Nashorn is not related to Rhino project at all. Nashorn is a different implementation of ES 5.1 and select few features of ES6 . Although the second sentence is true, the first is not. -- Colby Russell

Re: Resigning as OpenJDK Nashorn Project Lead

Just a clarification. You said "the original Rhino project" - which seems to suggest that Nashorn is related to Rhino. Nashorn is not related to Rhino project at all. Nashorn is a different implementation of ES 5.1 and select few features of ES6 . -Sundar On 05/10/20 11:50 pm,

Re: Resigning as OpenJDK Nashorn Project Lead

On 10/5/20 1:11 PM, Jim Laskey wrote: Nashorn was deprecated in JDK 11 [5] was removed from the OpenJDK in JDK 15 [6]. Moving forward, it is hoped that Nashorn may continue on as a standalone library in maven central. Any chance Nashorn ownership would be transferred to either the Apache

  1   2   3   4   5   6   7   8   9   10   >