hg: jigsaw/jake/langtools: Fix langtools/tools/jdeps/APIDeps.java to reference internal type

Changeset: f7876cd903aa Author:mchung Date: 2015-11-23 22:02 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/langtools/rev/f7876cd903aa Fix langtools/tools/jdeps/APIDeps.java to reference internal type ! test/tools/jdeps/APIDeps.java ! test/tools/jdeps/VerboseFormat/JdepsDependen

hg: jigsaw/jake/jdk: Throw IAE if the proxy module can't access interface

Changeset: 89fb05b6e864 Author:mchung Date: 2015-11-23 19:22 -0800 URL: http://hg.openjdk.java.net/jigsaw/jake/jdk/rev/89fb05b6e864 Throw IAE if the proxy module can't access interface ! src/java.base/share/classes/java/lang/reflect/Proxy.java ! test/jdk/jigsaw/reflect/Proxy/ProxyC

Re: RFR 8135972: Implement new tests for native libjimage library

Hi All, http://cr.openjdk.java.net/~jlaskey/8135972/webrev.01/index.html There are a minimal set of passing cleanly tests which does not explore bad values touching memory addresses. Please review. Thanks, Sergi On 13.11.2015 17:12, Alan Bateman wrote: On 13/11/2015 13:50, Sergei Pikale

Re: A way to opt out of access restrictions on non-exported members.

> On Nov 23, 2015, at 4:24 PM, Alex Buckley wrote: > > I know there is considerable effort going into replacement public APIs for > JavaFX -- see http://openjdk.java.net/jeps/253 > from May and the openjfx-dev thread > "Understanding the com.sun.* APIs being

Re: A way to opt out of access restrictions on non-exported members.

On 11/23/2015 9:58 AM, Alan Snyder wrote: My use case is a platform specific Swing look and feel. To work, it needs access to platform specific features of the AWT. I’m trying not to be pessimistic or cynical, but I cannot assume that Oracle/OpenJDK will be motivated to create a public API for al

Re: RFR: 8139430

Hi Shura, I have pushed the changeset to jdk9/dev. Mandy > On Nov 19, 2015, at 8:40 AM, Alexandre (Shura) Iline > wrote: > > Yes, sorry. > > Since the methods do not have any work to complete before interrupting and > also methods are not used anywhere currently, I assume re-throwing the >

Re: A way to opt out of access restrictions on non-exported members.

> There are rather a lot of libraries out there that access private > members via reflection. I posit that almost all such libraries break > without an easy way to fix the problem, if there is no way to use > reflection to access non-exported members. I agree with Reinier that there are situations

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

> On Nov 23, 2015, at 8:42 AM, Alan Bateman wrote: > > We need to do a bit of clean-up in Images.gmk to make things clearer as this > MAIN vs. PROVIDER topic has caused confusion on a few cases. If we can keep > the lists separate to the list of modules for the compact profile builds then > t

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 particul

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

> On Nov 23, 2015, at 7:40 AM, Alan Bateman wrote: > > > > 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: >>

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

But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. -Sundar On 11/23/2015 9:10 PM, Alan Bateman wrote: On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please revi

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

But, in addition to providing service, jdk.scripting.nashorn module also "exports" nashorn specific APIs in jdk.nashorn.api.* packages. -Sundar On 11/23/2015 9:10 PM, Alan Bateman wrote: On 23/11/2015 15:27, Attila Szegedi wrote: Folks, I integrated the changes Mandy suggested; please revi

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

Folks, I integrated the changes Mandy suggested; please review these (build related) changes: jdk9 top level: jdk9/jdk: For the sake of complete

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

+1 for the Nashorn/Dynalink changes. The top level changes look good to me but I'd prefer to leave reviews to those who are more familiar with the build/modules infrastructure. Hannes Am 2015-11-20 um 00:15 schrieb Attila Szegedi: Please review JDK-8141338 "Move jdk.internal.dynalink package

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

> On Nov 23, 2015, at 4:40 PM, Alan Bateman wrote: > > > > 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: >>

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: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

+HYPERLINK "mailto:security-...@openjdk.java.net"security-...@openjdk.java.net From: Siba Sahoo Sent: Monday, November 23, 2015 4:56 PM To: jigsaw-dev@openjdk.java.net; jdk-security-dev_ww_grp; Sean Mullan Subject: [9] RFR:8130360: Add tests to verify 3rd party security providers if they are

[9] RFR:8130360: Add tests to verify 3rd party security providers if they are in signed/unsigned modular JARs

Hi, Please help me with your review of this test for JBS: https://bugs.openjdk.java.net/browse/JDK-8130360, Webrev: http://cr.openjdk.java.net/~asmotrak/siba/8130360/webrev.01/ Description Tests to verify 3rd party security providers if they are in signed/unsigned modular JARs. The