Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

On 08/06/2015 13:37, Magnus Ihse Bursie wrote: : The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string

Re: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration)

On 05/06/2015 15:07, Magnus Ihse Bursie wrote: This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java 9, instead of Java 1.9.0. This patch is a folding of all work that has been done so far in the branch

Re: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs

On 25/06/2015 17:25, Jan Lahoda wrote: Hello, Based on the feedback I've received so far, I've uploaded an updated version of the patch: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ Notable changes: -avoided the dependency on java.desktop and java.datatransfer -adjusted the

Re: RFR 8134260: jjs in jre directory fails with Could not find or load main class jdk.nashorn.tools.jjs.Main

On 25/08/2015 14:24, Sundararajan Athijegannathan wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8134260/ for https://bugs.openjdk.java.net/browse/JDK-8134260 jdk.nashorn.tools.jjs and jdk.internal.le should exist in jre's appmodules.jimage with this change and so jjs would

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

On 16/09/2015 14:04, Magnus Ihse Bursie wrote: Does this mean that updates to modules.xml between now and the integration-to-come of jigsaw/jake do not anymore need specific approval? I think we should keep the status quo and CC jigsaw-dev when there are changes to modules.xml. If nothing

Re: Review request for JDK-8135251: Use Unsafe.defineAnonymousClass for loading Nashorn script code

On 16/09/2015 14:06, David M. Lloyd wrote: Also I could be wrong but it looks to me like the jigsaw/jake forest's equivalent module graph has evolved somewhat, and thus doesn't quite match this file anyway. jigsaw/jake is currently at jdk9-b81. There may be changes backed up in jdk9/dev

Re: RFR 8145750: jjs fails to run simple scripts with security manager turned on

On 18/12/2015 12:23, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8145750/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8145750 Adding missing permissions for jdk.dynalink module. Note that it used to be part of jdk.scripting.nashorn module

8049422: Remove @jdk.Exported

It's time to remove @jdk.Exported. As background, this annotation was introduced by JEP 179 in JDK 8 to document the supportness of JDK-specific APIs. It will become redundant and confusing once we bring the module system into JDK 9. The proposal in JEP 261 is to remove it and it seems saner

Re: RFR 8145750: jjs fails to run simple scripts with security manager turned on

On 18/12/2015 12:55, Sundararajan Athijegannathan wrote: May be, not. But I tried giving only sun.reflect package access -- didn't work. There are a few doPrivileged blocks in dynalink code as well. This needs further analysis. But dynalink code was part of nashorn and so was getting

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:43, Sundararajan Athijegannathan wrote: But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. Sure, it could go in either but we mostly treat it as a service provider. -Alan.

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk:

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 23/11/2015 16:07, Attila Szegedi wrote: : Whichever is the stronger criteria for deciding whether to place it in MAIN or PROVIDER is fine with me. Intuitively “provider” seems like a weaker category (exposes a service provider but doesn’t have its own API), so (without knowing the

Re: Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink

On 19/11/2015 23:15, Attila Szegedi wrote: Please review JDK-8141338 "Move jdk.internal.dynalink package to jdk.dynalink" for . This is basically the implementation step for integrating JEP 276. This changeset will introduce a new public API

Re: RFR 8158131: Nashorn should not use jdk.internal.module.Modules API

On 30/05/2016 11:43, Sundararajan Athijegannathan wrote: Updated nashorn webrev: http://cr.openjdk.java.net/~sundar/8158131/nashorn/webrev.01/ * Added @link in ModuleGraphManipulator.java's javadoc * Using Context.class.getModule() in all places where nashorn module is needed * Using all

Re: RFR 8152268: jjs tool makefile should use --addmods ALL-SYSTEM

On 23/03/2016 08:59, Sundararajan Athijegannathan wrote: Hi, Please review http://cr.openjdk.java.net/~sundar/8152268/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8152268 This looks okay, similar to what we had to do with appletviewer. -Alan.

Re: RFR 8154192: Deprivilege java.scripting module

On 18/05/2016 08:55, Sundararajan Athijegannathan wrote: Please review the updated webrevs. * Fixed Modules.gmk for order of modules: http://cr.openjdk.java.net/~sundar/8154192/top/webrev.01/ * From quick reading of j.u.ServiceLoader: AccessControlContext is captured in ServiceLoader

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:10, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8165595/webrev.01/ for https://bugs.openjdk.java.net/browse/JDK-8165595 I'm not sure that asking users to use -m is right here, esp. when the modules contains launchers. Also

Re: RFR 8165595: Main class should be set for nashorn modules

On 07/09/2016 13:27, Sundararajan Athijegannathan wrote: jjs does not yet support module related options. So, user modules can not be scripted directly with jjs as of now. Only way is to use to launcher with -mp along with -m for jjs main class. With the change, only module name needs to be

Re: RFR 8071588: The spec for javax.script.ScriptEngineFactory.getProgram() should specify NPEs thrown

On 19/10/2016 06:06, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8071588 jdk webrev: http://cr.openjdk.java.net/~sundar/8071588/jdk/webrev.00/ nashorn webrev: http://cr.openjdk.java.net/~sundar/8071588/nashorn/webrev.00/ This looks okay

Re: RFR 8170099: Nashorn test failures with stricter reflection access checks in jake forest

On 21/11/2016 14:14, Sundararajan Athijegannathan wrote: Please review http://cr.openjdk.java.net/~sundar/8170099/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8170099 This looks okay although you could replace the setAccessible methods in Reflector that take Method and Constructor

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

On 12/10/2016 16:11, Sundararajan Athijegannathan wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8167614 jdk webrev: http://cr.openjdk.java.net/~sundar/8167614/jdk/webrev.00/ nashorn webrev: http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.00/ In

Re: RFR 8167614: Avoid module dependency from jdk.dynalink to jdk.internal.module of java.base module

On 12/10/2016 17:31, Sundararajan Athijegannathan wrote: Updated nashorn webrev: http://cr.openjdk.java.net/~sundar/8167614/nashorn/webrev.01/ Changed to use Layer.boot().findModule. That loos okay to me. I assume that once we fix the issues in java.sql that this code can be removed. -Alan

Re: RFR 8193779: Fix copyright header in nashorn builtin scripts

On 19/12/2017 10:38, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8193799 Webrev: http://cr.openjdk.java.net/~sundar/8193799/webrev.00/ Looks fine. Will you push this to jdk/jdk10? -Alan

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

On 30/05/2018 16:06, Jan Lahoda wrote: Hi, An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/complete/ A webrev showing changes from the previous revision is here: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.01/delta/ The changes are: -updated

Re: RFR: JDK-8203827: Upgrade JLine to 2.14.6

On 25/05/2018 21:20, Jan Lahoda wrote: Hi, I'd like to upgrade the JLine used by JShell and jjs from 2.12.1 to 2.14.6. The complete webrev is here: http://cr.openjdk.java.net/~jlahoda/8203827/webrev.00/complete/ To simplify reviewing, there is: -an antipatch that removes the JDK-specific