Review request for JDK-8141338: Move jdk.internal.dynalink package to jdk.dynalink
szegedia at gmail.com
Mon Nov 23 16:07:03 UTC 2015
> On Nov 23, 2015, at 4:40 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 23/11/2015 15:27, Attila Szegedi wrote:
>> I integrated the changes Mandy suggested; please review these (build related) changes:
>> jdk9 top level: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> jdk9/jdk: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9.top.2/index.html>
>> For the sake of completeness, the jdk/nashorn changes are here: <http://cr.openjdk.java.net/~attila/8141338/webrev.jdk9> but they have already been reviewed by Hannes and Sundar; only the above two (jdk9 and jdk9/jdk) have been modified compared to the original review request.
>> Sundar was kind enough to verify that JDK9 builds fine with these changes.
> The jdk repo looks okay (just had to change your link to find it :-)
D’oh. I was doublechecking those links few times and still managed to bungle it… thanks for figuring it out.
> In the top-level repo then you've moved jdk.scripting.nashorn from PROVIDER_MODULES to MAIN_MODULES. The reason that we've had it in PROVIDER_MODULES is because we treat it as a service provider module (it provides an implementation of javax.script.ScriptEngineFactory).
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 particulars of the use of these *_MODULES variables) it seems to me Mandy’s suggestion is correct to reclassify Nashorn into a MAIN module.
More information about the nashorn-dev