Next steps for Rhino after the v1.7.14 release

[p-bakker]

After the release of v1.7.14, we're onto the next version.

In the past there's been discussion to move from v1.7 to v1.8 or v2.0. The premise of that discussion is that there are (a few) things in the Rhino codebase that might require a backwards-incompatible change to the public API in order to support/fix:

• Support ES5 this handling in strict mode #940 + references linked in the case
• const does not block-scope in loop-body #326 (comment)
• Release 1.7.13 #734 (comment) & Release 1.7.13 #734 (comment)
• ES5-Test262 progress #39 (comment)

❓ Question
More things that require breaking public Java API changes to fix or implement? Let us know in the comments, so they can be included in the list

Also, fixing behavioral issues within the current Context.VERSION_ES language version already poses a problem with regards to backwards compatibility, because they would break implementations that currently already use the Context.VERSION_ES language version.

See label Ecma Incompatibilities for some identified examples.

Maybe scraping MDN and looking for non-standard stuff (like RegExp.lastParen) is a good way to find non-compatible extensions given that Rhino & SpiderMonkey (where a lot of these non-standard extensions come from) share a history. These searches on the MDN doc (source) at least reveals some: https://github.com/mdn/content/search?q={{deprecated_header}}+path:files/en-us/web/javascript/ and https://developer.mozilla.org/en-US/search?q=deprecated. This is another list the MDN tracks itself (but doesn't seem complete): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features

Another option to find incompatibilities is run the tests from test262/annexB and see which tests pass, as stuff under testing in /annexB should only be implemented by browsers

With this discussion I hope to find consensus on the plan to move forward

[p-bakker]

Personally, I think we should do something along these lines:

• Aim for the next release (1.7.15) to close the gap to EcmaScript compatibility without any breaking public Java API changes (and identify exactly which things we cannot fix w/o breaking the public Java API)
• Then switch to semantic versioning and bump the major version to v2.0.0 and:
  • make the required breaking Java API changes (if any)
  • introduce Context.VERSION_ECMASCRIPT, which:
    • offers a clean implementation of the latest EcmaScript standard, in which:
      • some features might still be missing (like Classes or async/await)
      • implemented features are standard-compliant
      • all non-spec-compliant additions are disabled, for example Continuations, E4X or all Java Interop (see below)
      • all non-spec-compliant behaviors are disabled, although we'll first need to identify them all (see a start of that with label Ecma Incompatibilities)
  • make Context.VERSION_ECMASCRIPT the default version
  • put all Java Interop extensions (Packages, direct access to classes via org/java/com, NativeJava* host objects, JavaImporter etc) behind a flag (not sure what the default for that flag needs to be)

[p-bakker]

@michbarsinai Tnx for letting us know, valuable info.

While on the topic of continuations: do you maybe have any insight on how Continuations and Promises relate to each other? We're about to land Promise support and I feel Promises and Continuations are somewhat similar, but don't have enough insight into the intricacies of Continuations to determine whether (eventually) Continuations might be replaced by Promises

[michbarsinai]

Promises are different from continuations in that they execute a function to completion (albeit on another thread) and pass the result to a callback. Continuations, on the other hand, do not run to completion, but capture the entire runtime stack+heap in the middle of a computation. The computation may be continued later by the calling program (hence "continuation"). That program might also pass a parameter to the continued computation.

I can't see how one could implement continuations using promises. It might be feasible to use continuations to implement promises, though. You could store promises as continuations in some queue, and then execute then using a single thread, as you would with Java's Runnable and ExecutorService.

In case you want to run Rhino on a single thread, the completion of a promise could trigger a continuation capture on the main JS program. Then, rhino can perform the promise callbacks, and then continue the main thread.

[p-bakker]

Tnx for your insight.

Sounds like a Continuation is more like await when making calls to async functions in JavaScript, with the difference that:

1. with async/await there's no Continuation object that you can grab hold of in JavaScript,
2. nor can you pass a parameter to the continued computation (except for the await returning the value from the awaited function)

Does that come close?

[tuchida]

Context.VERSION_ECMASCRIPT

Adding new options will increase the number of branch in code, making testing and compatibility assurance more difficult.
In particular, -version and -opt change the behavior, so we want to keep the number of these combinations low.
For example, who would use version <= Context.VERSION_1_4?

[p-bakker]

Adding new options will increase the number of branch in code

Agree, but... :-)
If we do it right, Context.VERSION_ECMASCRIPT could be the last one we add (with EcmaScript now having a proper specification process with a lot of emphasis on backwards compatibility) and become our default.

And besides Context.VERSION_ES6 not being aptly named, we also need to differentiate between the behavior of Context.VERSION_ES6 and a proper, standard-compliant EcmaScript implementation. Context.VERSION_ES6 currently has behavior that is NOT standard-compliant, so trying to fix those under the ES6 flag would mean breaking changes.

So my proposal would be to add Context.VERSION_ECMASCRIPT, make sure whatever it supports is just EcmaScript (no Annex B stuff, no non-standard legacy JavaScript features (Array/String generics, expression closures etc etc), by default no extensions (E4X, Continuations, etc., but can be enabled through feature flags), only standard compliant features (meaning proper const impl., fixed strict mode etc.)). This new Context.VERSION_ECMASCRIPT could be added in v1.7.15, but with a big disclaimer that we'll (most likely) be making breaking changes to it before the v2.0.0 release, so don't use in production (or use at your own risk).

And Context.VERSION_ECMASCRIPT might be missing EcmaScript features (async/await, ES modules, classes etc. (although I rather see them implemented :-) )), but whatever it does support HAS to be standard compliant, in order for this whole plan to work.

For example, who would use version <= Context.VERSION_1_4
The million dollar question, also see #972 (reply in thread)

If we do all this right, then maybe in a v3.x branch we could start tossing out all the support for all language versions except Context.VERSION_ECMASCRIPT.

I know it would be easier on the development side to just toss out all that legacy now, but afraid that some implementations would then forever be stuck on v1.7.x and I think it would be best for the project to try our best to prevent that from happening

[botic]

Putting Java interop behind a flag / simple configuration sounds like a reasonable approch for RingoJS. We rely on the interoperability at a broad range. Keeping the mechanism / naming the same is crutial for us, but it should be not a big problem to ship a major release RingoJS version with Rhino 2.0 having all necessary flags enabled.

To let old ballast behind, continuations and E4X should be dropped / marked as unsupported with a 2.0 release.

[p-bakker]

I think both continuations and E4X are still heavily used by some implementations, so dropping support for them would mean forcing some Rhino integrations to stay on 1.x forever.

Not sure what the impact is of continued support of continuations and E4X on the further development of Rhino, but that imho is an important factor in deciding how to proceed with them.

But I would like them to be opt-ins, sonot enabled by default

While continuations might maybe be extracted and offered in a separate jar (maybe), for EX4 I'd think that would be a lot harder, as it's a syntax extension and thus tightly integrated in the parser and such

[botic]

Didn't know that E4X is still a thing, since every code I know using it has been rewritten in the last years to other Java-based XML libraries. But yes, I thought more about the support burden it might create. So as long as this is not the case, you are 100% right in keeping it.

[henning-meinhardt]

I am unaware of any comparable technologies (as far as ease of use, feature completeness, and runs in Rhino) for transforming xml in javascript that could be used to replace it.
We are also still using the unparalleled E4X feature in our form management system, allowing users to define logic in JavaScript, exposing a lot of missing functionality through host objects. As we also don't see any viable alternative for XML processing / transformation we'd also like to see E4X in upcoming Rhino releases!

[p-bakker]

Thnk the concensus is that features like E4X and Continuations are things that make Rhino stand out form the rest and thus should indeed remain supported

[tonygermano]

I've mentioned in a couple other issues recently that e4x is still heavily used (as is Java interop) in user written code in NextGen (Mirth) Connect, which serves the global healthcare market. Much of the user written code is transforming xml. Dropping e4x support would effectively mean that they would not be able to move past 1.7.15, as most user written code would cease to work.

I am unaware of any comparable technologies (as far as ease of use, feature completeness, and runs in Rhino) for transforming xml in javascript that could be used to replace it. Should there be any effort to allow version 2.x to run in the same JVM as 1.7.x to allow for transitioning legacy user code to the newer engine?

Also, how do you do anything network related without Java interop? Rhino doesn't have any of the mechanisms found in the browser or node.js to do anything network related.

[p-bakker]

Dropping e4x support would effectively mean that they would not be able to move past 1.7.15

Yeah, something we should try prevent. The only condition I guess under which we have to decide to drop E4X support (completely) would be (imho) if continued support for E4X causes such a burden on further development that we cannot realistically keep supporting it. But as far as I can see that isn't the case

Should there be any effort to allow version 2.x to run in the same JVM as 1.7.x to allow for transitioning legacy user code to the newer engine?

Something to be looked into, I guess. No idea what that would entail though.

Also, how do you do anything network related without Java interop? Rhino doesn't have any of the mechanisms found in the browser or node.js to do anything network related.

In one of the apps where we use Rhino, (end)users can write scripts to automate stuff and no network related stuff is needed and if that would become a requirement at some point, we'd expose a host object offering the needed functionality into the scope where the user scripts are executed

[tonygermano]

Regarding networking, once Promises are in, would it make sense/be possible to implement the fetch API as a native object in Rhino?

[p-bakker]

Similar to setTimeout(...) the fetch api isn't part of EcmaScript, but part of the Web API.

As such, I'm of the opinion that it shouldn't be part of the core of Rhino/be there by default, but depending on your use-case, it would be handy to have (and not have everyone reimplement the same thing over and over again).

Not sure what the best way would be to go about it. Neither GraalJS or NodeJS offers it in the code, but utilize the node-fetch package. Maybe, if there is enough interest, someone could setup a side project to that provides the relevant Web API's as additional built-ins

[gbrail]

Probably worth a separate issue, but I'd prefer that the "fetch" API be in a separate package that can be optionally included, for a number of reasons: 1. Embedders not only won't use it, but can't have it because it'll introduce a brand new security hole. It must be something that an embedder turns on by default. 2. I'm not even sure it should be a default part of the Rhino shell, again because of security. 3. It'll depend on some HTTP client library, and to date Rhino has no dependencies and should stay that way. setTimeout, however, doesn't have any of those limitations. I'm thinking of adding it to the "Global" object (which is used by the shell and is used in the tools package.) It's a good way to exercise the Promise code more, and in fact the tests in kangax/compat-table require it, or at least did the last time I looked.

…

On Wed, Jun 30, 2021 at 12:41 PM Paul Bakker ***@***.***> wrote: Similar to setTimeout(...) the fetch api isn't part of EcmaScript, but part of the Web API <https://developer.mozilla.org/en-US/docs/Web/API>. As such, I'm of the opinion that it shouldn't be part of the core of Rhino/be there by default, but depending on your use-case, it would be handy to have (and not have everyone reimplement the same thing over and over again). Not sure what the best way would be to go about it. Neither GraalJS or NodeJS offers it in the code, but utilize the node-fetch package. Maybe, if there is enough interest, someone could setup a side project to that provides the relevant Web API's as additional built-ins — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I26BWE7FFWEMH2QFXX3TVNXOZANCNFSM47R2QNUQ> .

[p-bakker]

Indeed setTimeout is something very useful with Promises.

Question is if We'd go for a very clean Context.VERSION_ECMASCRIPT that is really only what EcmaScript specifies and then flag/options/xxx for embedders to add more stuff as they wish (E4X, Continuations, Java Access etc etc), whether setTimeout is one of those opt-ins, or something that we just add by default. GraalJS doesn't, NodeJS does. I'm leaning towards not adding it by default

Same could be argued about console

[gbrail]

For optional stuff like setTimeout, console, load, etc, I like the current approach -- by default, Rhino has none of that, and you can even use the "runtime" JAR and not even have it in your classpath. But you can instead use the full JAR and load the Global object and then you get all of them. Do we think that there's a case in which a user would want setTimeout but not "print," etc? That would then call for a more modular implementation.

…

On Wed, Jun 30, 2021 at 1:01 PM Paul Bakker ***@***.***> wrote: Indeed setTimeout is something very useful with Promises. Question is if We'd go for a very clean Context.VERSION_ECMASCRIPT that is really only what EcmaScript specifies and then flag/options/xxx for embedders to add more stuff as they wish (E4X, Continuations, Java Access etc etc), whether setTimeout is one of those opt-ins, or something that we just add by default. GraalJS doesn't, NodeJS does. I'm leaning towards not adding it by default Same could be argued about console — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I2ZRXZRKZWMIZXYNLTTTVNZXZANCNFSM47R2QNUQ> .

[p-bakker]

I'd think some would want setTimeout and console, but not print.

GraalJS adds a very few by default, but all can be disabled, see https://www.graalvm.org/reference-manual/js/JavaScriptCompatibility/#global-properties

I'd prefer to not have them enabled by default, but what to put in a separate jar and what to keep in core I'm not sure.

Anyway, getting into quite some detail now, maybe focus on the bigger picture first a bit

[tuchida]

Ecma Incompatibilities

I'll write down what I know. (Updated as needed)

JavaScript 1.8 (Mozilla extension)

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Deprecated_and_obsolete_features

Expression closures

https://developer.mozilla.org/en-US/docs/Archive/Web/JavaScript/Expression_closures

function(x) x*x

Conditional catch clause

https://esdiscuss.org/topic/conditional-catch-clause

try {
} catch (e if e === 1) {
} catch (e if e === 2) { // multiple catch clauses
}

Array comprehension

rhino/testsrc/jstests/harmony/for-of.js

Lines 114 to 116 in aac4a4e

	// Array comprehension
	assertEquals('1,4,9', [n*n for (n of [1, 2, 3])].join());
	assertEquals('5,6,7,6,7,8,7,8,9', [n+m for (n of [1, 2, 3]) for (m of [4, 5, 6])].join());

Legacy generator

function() { yield 1; } // without *

Iterator and __iterator__

__parent__

rhino/src/org/mozilla/javascript/SpecialRef.java

Line 39 in aac4a4e

} else if (name.equals("__parent__")) {

__noSuchMethod__

rhino/src/org/mozilla/javascript/ScriptRuntime.java

Line 2575 in 3e205d7

Object noSuchMethod = ScriptableObject.getProperty(thisObj, "__noSuchMethod__");

toSource

1..toSource()

uneval

E4X

https://developer.mozilla.org/en-US/docs/Archive/Web/E4X

for each-in

Other

Syntax sugar of JavaAdapter

rhino/src/org/mozilla/javascript/Parser.java

Lines 2683 to 2691 in aac4a4e

	// Experimental syntax: allow an object literal to follow a new
	// expression, which will mean a kind of anonymous class built with
	// the JavaAdapter. the object literal will be passed as an
	// additional argument to the constructor.
	if (matchToken(Token.LC, true)) {
	ObjectLiteral initializer = objectLiteral();
	end = getNodeEnd(initializer);
	nx.setInitializer(initializer);
	}

a = new java.util.HashMap() { b: 1 } // {b=1.0}

__proto__ is not property

delete Object.prototype.__proto__ // do'nt work in Rhino

rhino/src/org/mozilla/javascript/SpecialRef.java

Line 37 in aac4a4e

if (name.equals("__proto__")) {

Continuation

rhino/src/org/mozilla/javascript/NativeContinuation.java

Line 11 in 520d594

public final class NativeContinuation extends IdScriptableObject implements Function {

[tuchida]

Expression closures

Syntax sugar of JavaAdapter

These appear to be relatively easy to rewrite to standard specifications.
Is there anyone who would be bothered by the loss of these?

[p-bakker]

Is there anyone who would be bothered by the loss of these?

Well, that's the 1 million dollar questions, isn't it :-)

With Rhino being around for such a long time and being used in many different scenarios, who knows what kind of (legacy) Js code is out there still being run in Rhino...

From a code maintenance perspective we'd like to toss out all obsolete/non-standard stuff (not taking about Continuations/E4X/TCO, but stuff like Array/String generics, let expressions, expression closures), but that might break existing code.

Maybe we ought to think about:

1. in the v1.7.x line release a version where we log warnings if any of these obsolete/non-standard things are encountered, so they can be removed in the v2.0.0 branch
2. and/or having some tool to run all JavaScript code through that would be executed in Rhino to analyze it for usage of stuff that will be/has been removed in a v2.0.0 branch

Regarding 1: would entail first upgrading to the latest v1.7.x release, before moving onto a v2.x release and some things might be hard to create warnings for

Regarding 2: some things might be hard to statically analyze though

Just thinking out loud, its a thorny problem to solve...

[tuchida]

Backward compatibility is very important.
However, without major changes, it will probably be difficult to get TDZ and dstr-assign to work as specified.
It might be a good idea to try to toss them little by little, starting with the ones that seem to have the least impact.

[p-bakker]

Not familiar with dstr-assign, care to elaborate?

Regarding TDZ: haven't looked in detail what it would entail to implement that, so if you say that requires major changes, I'm all ears :-) That's exactly the stuff we need to identify: where are major and/or breaking changes required to:

1. get to EcmaScript compliancy
2. clear hurdles that currently stop us from improving performance and/or the codebase

[tuchida]

Not familiar with dstr-assign, care to elaborate?

I don't remember which test case it was, but I remember giving up trying to get this to meet the specification.

var {} = null;

I think the problem is that the assignment is parsed by IRFactory instead of Parser.

[p-bakker]

@gbrail didn't you have ideas on possible ending support for Java 8 at some point, as to be able to be able to take advantage of newer JVM features that would enable ways to improve performance?

@rbri think you mentioned before that you've run into things you'd like to fix, but that that would mean breaking the public Java API. Care to add?

[p-bakker]

@gbrail Should we also look at your proposals to remove serialization (#704) and synchronization (#705) in this context?

[p-bakker]

As for optional additions: another thing that might be interesting for some would be having the ability to add the API as used by Nashorn and GraalJS for interacting with Java classes: both seem to have chosen a different approach to what Rhino has always done.

If offered as an add-on, it might aid in people trying out Rhino

[tuchida]

What about Tail call optimization(TCO)?
The specification has been finalized for ES6, but only Safari is supported.
tc39/proposal-ptc-syntax#23

Rhino only supports this in Interpreter mode. (I haven't checked to see if it meets the specifications.)

rhino/src/org/mozilla/javascript/CodeGenerator.java

Lines 622 to 629 in 3e205d7

	// Only use the tail call optimization if we're not in a try
	// or we're not generating debug info (since the
	// optimization will confuse the debugger)
	if (type == Token.CALL
	&& (contextFlags & ECF_TAIL) != 0
	&& !compilerEnv.isGenerateDebugInfo()
	&& !itsInTryFlag) {
	type = Icode_TAIL_CALL;

[p-bakker]

Is there a way in the parser to throw deprecated warnings for non-standard syntax before we would actually drop them?

I think that is feasible.

I would propose to, after release of v1.7.14, to:

1. add Context.VERSION_ECMASCRIPT, which if used writes a big warning out into the logs that Context.VERSION_ECMASCRIPT is only going to be finalized in v2.0.0 and that if used with v1.7.14(_snapshot) there might be breaking changes between v1.7.14 and v2.0.0
2. Make a comprehensive list of all the non-standard things (excluding E4X, Continuations) in Rhino
3. start adding warnings in the parser and/or at runtime when non-standard things are being used when languageVersion < CONTEXT.VERSION_ECMASCRIPT
4. throw proper Syntax/Type/... Errors in the parser and/or runtime when non-standards are being used and the languageVersion == CONTEXT.VERSION_ECMASCRIPT

Maybe there should be a flag to suppress the warnings that would be logged under item 3, as to not pollute logs when v1.7.14(_snapshots) would be used in production

[tonygermano]

I do think we need to differentiate between syntax related to runtime features, such as those mentioned in this thread, and syntax that is purely alternative grammar because the standard did not yet exist. I think the former should be controlled by context flags other than the language version, while the latter could be disabled with language version.

[p-bakker]

Could you give an example of both? Cause the only additional feature I can think of atm would be one to toggle continuation support.

All other non-standard (that isn't already controlled by feature flags) are all obsolete/outdated JavaScript things that ought to be outright removed in Context VERSION_ECMACRIPT (and possibly eventually (v3.0.0?) From the codebase altogether)

[tonygermano]

Apologies, I had missed that you said "excluding E4X." That was primarily what I was thinking of as a non-standard runtime feature that also required syntax extensions.

I would say Expression Closures would be an example of syntax sugar. There's nothing there you cannot accomplish with standard syntax.

[p-bakker]

Just to make sure I understand you correctly: you're saying the Expression Closures are indeed something we can just stop supporting in a Context.VERSION_ECMASCRIPT and potentially remove entirely from the codebase in a v3.0.0, correct?

And to add to my previous comment: with v2.0.0 I would also propose to switch the default language version for both embedded usage and the shell to Context.VERSION_ECMASCRIPT (and potentially in a v3.0.0 completely remove support for languageVersion as we'd just support the latest version of EcmaScript)

[p-bakker]

Another area where we have incompatibilities, see #213

Flagging such cases with label Ecma Incompatibilities

[michbarsinai]

Point 1 is spot on. As for 2, I think you could use continuations to implement await, in the following way: When reaching an `await` keyword: 1. start the awaited-for promise in another thread 2. capture a continuation of the main program at the `await` (technically that would involve implementing `await` as a continuation capture) 3. Wait for the promise to resolve in some promise-handling thread. 4. Invoke the continuation from step 2 with the resolved value from step 3.

…

On 5 Jul 2021, at 12:10, Paul Bakker ***@***.***> wrote: Tnx for your insight. Sounds like a Continuation is more like await when making calls to async functions in JavaScript, with the difference that: with async/await there's no Continuation object that you can grab hold of in JavaScript, nor can you pass a parameter to the continued computation (except for the await returning the value from the awaited function) Does that come close? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOZIJHW6LOG3WM56A5ZF5LTWFZIBANCNFSM47R2QNUQ>.

[p-bakker]

Above comment related to #972 (reply in thread)

Tnx for your input @michbarsinai

[p-bakker]

Should probably also change the default value of WrapFactory.javaPrimitiveWrap from true > false in a context.VERSION_ECMASCRIPT, so Java primitives are exposed in JS land as JavaScript primitives, instead of as wrapped Java objects.

Begs the question if we should also do something similar with Java primitives that map onto BigInt or one of the TypedArray variants

Or Date instances, see #89 (comment)

[p-bakker]

Also see #638 (there are more similar cases)

[p-bakker]

More non-standard stuff can be found by looking at the release notes for Mozilla's JavaScript versions, see New in JavaScript, for example Array and String generics in New in JavaScript 1.6

[p-bakker]

MDN is no longer hosting old/archived content. However, its still available in one of their GitHub repo's: https://github.com/mdn/archived-content/tree/main/files/en-us/archive/web/javascript/new_in_javascript

[p-bakker]

Am planning to, in a few weeks, wrap up this discussion and try to create a proposal on how to move forward on this.

@gbrail and @rbri: could you share their thoughts on area's you know of where, in order to move the needle forward on Rhino, we might have to break backwards compatibility?

Also, would be great if some of the previous maintainers/contributors of Rhino, like @hns, @szegedi and @anba could chip in and give us their insight on this topic, as they all have tried to move the needle in the past, but ran into having to break backwards compatibility in order to do so (I believe)

[gbrail]

That makes sense to me too. Glad to hear from users of those features!

…

On Wed, Sep 29, 2021 at 12:54 AM Paul Bakker ***@***.***> wrote: Thnk the concensus is that features like E4X and Continuations are things that make Rhino stand out form the rest and thus should indeed remain supported — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#972 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD7I26F2Q3QRVKRHICYXGLUELA4ZANCNFSM47R2QNUQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[rPraml]

I would like to annunce #827 for v1.8/v2.0 as it introduces an API change in the WrapFactory.
I also have some ideas in my pipeline how to implement better security with a Java security manager.
It would be much easier, if there is a release, where API changes are allowed, as I need to modify interfaces like ClassShutter. See #861

[tonygermano]

FYI, security manager is deprecated for removal in java 17 https://openjdk.java.net/jeps/411

[rPraml]

@tonygermano thanks for that information, that are bad news for us...
We planned to use security manager to limit File and Network IO and other critical things.

We have a web application, where we plan, that end users may enter javascript for computations and we have LiveConnect enabled.
Currently, we use javascript to generate pdf/xlsx reports with PdfBox and Apache-POI. (The javascript has the ability to query the database and create an excel worksheet with the data)
Of course, we can do the same in java, but Rhino was perfect for this task, as we easily can change the report without redeplopying a new version of the application.

Unfortunately code expressions like java.lang.System.exit() and new java.io.File('/etc/passwd').delete() do what they say and will harm the application or even the server.

We tried to use "classShutter" and overridden WrapFactories, custom wrappers with class whitelist to prevent malicious code from execution and disallow classes like java.io.File. That did work until we discovered PDDocument.save(String) - this method is whitelisted, because we need to manipulate PDFs. Unfortunately, you can overwrite any file on the disk.

With a proper SecurityManger setup, I can compile the javaScript code to be untrusted and I'll get an AccessControlException when any code called from that script tries to access a file.

I see the following options:

• disable LiveConnect for simple computation formulas (like firstName + ' ' + lastName)
• review each class that is accessible with LiveConnect and provide wrappers for dangerous ones (like PDDocument)
• do not allow, that javaScript code can be entered/changed by the end user.

I understand, that it may not make sense to implement something that is based on a known deprecated api,
On the other hand, there is no alternative, yet. And as far as I understand, Rhino supports the security manager API.

What do you (and others) think about my use case and how to solve it.
(I can move that discussion also to an other place if you want)

[p-bakker]

I suggest indeed moving this discussion to the Discussions section. And I guess we'll need a case to remove the dependancy on the Security Manager from the Rhino codebase at some point

[rPraml]

Discussion is here: #1045

[p-bakker]

As per https://openjdk.java.net/jeps/411: the Java Security Manager is going to be deprecated for removal, so to keep Rhino compatible with newer Java versions, We'll need to remove the dependancy on the Java SecurityManager (in RhinoSecurityManager) at some point as well

[p-bakker]

Another pointer to a partial list of things where Rhino adds non-standard stuff: https://wiki.openjdk.java.net/display/Nashorn/Rhino+Migration+Guide#:~:text=the%20JavaScript%20method.-,Compatibility%20script,-There%20are%20few

[p-bakker]

Maybe we ought to, at some point, also add the same API as Graal(/Nashorn) for interacting with Java, as per https://www.graalvm.org/reference-manual/js/JavaInteroperability/#access-java-from-javascript

[szegedi]

I also maintain a description of this API (I keep it in the wiki of my own fork of Nashorn 'cause OpenJDK org doesn't support wikis on its projects on GitHub…) The Nashorn team at Oracle I was in at the time designed and implemented most of this API for Nashorn, which then Graal reimplemented for compatibility. I'm happy to answer questions about it.

[p-bakker]

FYI: I've setup 2 projects, v1.7.15 and v2.0.0 as a start to convert everything that has been said in this discussion into cases and group them into projects/releases.

[p-bakker]

Locking this discussion: all (still relevant) idea's & comments have been put into cases somewhere

[gbrail]

This is a long long discussion, but I'm ready to say that Rhino can move beyond Java 8 after 1.7.14. Later Java versions are getting pretty ubiquitous, and the log4j thing helped push some people along.

I'd like to propose Java 11 as the new baseline going forward, with support for newer versions of course.

Does that make sense?

[p-bakker]

As this discussion is locked, I've started a new discussion with your question, so people can comment: #1169

[p-bakker]

To all that participated in this discussion, see the follow-up discussion: #1363