Re: RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link

2016-05-19 Thread Hannes Wallnoefer 

+1

Am 2016-05-19 um 14:28 schrieb Sundararajan Athijegannathan:

Please review http://cr.openjdk.java.net/~sundar/8157310/ for
https://bugs.openjdk.java.net/browse/JDK-8157310

What is this fix?

* When unreflecting caller sensitive methods, dynalink uses specific
Lookup of actual caller (instead of publicLookup) - in nashorn's case
it's be the Lookup of script class.

* Script class may not have read link to the module of the class (of
caller sensitive member). If there is any IllegalAccessError, dynalink
adds the read link and tries to

unreflect again. We don't want unnecessary module link read in such
cases. Check has been added whether the package is exported from
declaring module. Note that there is no security issue here.  Even
before the fix, module read edge does not give any capability. unreflect
call after adding unnecessary read line would still fail for
non-exported package case. There were unnecessary module read links
created - which is being avoided now.

* Additional "API" in Lookup.java slipped from jigsaw code into
jdk9-dev. Those unreflectCallerSensitive and
unreflectConstructorCallerSensitive were meant to be 'interim' somehow
slipped.  Now, only unreflect and unreflectConstructor in Lookup. Caller
sensitiveness is hidden in the implementation.  These methods were never
APIs when dynalink API was created.

Thanks,

-Sundar

RFR 8157310: jdk.dynalink.linker.support.Lookup should have more checks before adding module read link

2016-05-19 Thread Sundararajan Athijegannathan 
Please review http://cr.openjdk.java.net/~sundar/8157310/ for
https://bugs.openjdk.java.net/browse/JDK-8157310

What is this fix?

* When unreflecting caller sensitive methods, dynalink uses specific
Lookup of actual caller (instead of publicLookup) - in nashorn's case
it's be the Lookup of script class.

* Script class may not have read link to the module of the class (of
caller sensitive member). If there is any IllegalAccessError, dynalink
adds the read link and tries to

unreflect again. We don't want unnecessary module link read in such
cases. Check has been added whether the package is exported from
declaring module. Note that there is no security issue here.  Even
before the fix, module read edge does not give any capability. unreflect
call after adding unnecessary read line would still fail for
non-exported package case. There were unnecessary module read links
created - which is being avoided now.

* Additional "API" in Lookup.java slipped from jigsaw code into
jdk9-dev. Those unreflectCallerSensitive and
unreflectConstructorCallerSensitive were meant to be 'interim' somehow
slipped.  Now, only unreflect and unreflectConstructor in Lookup. Caller
sensitiveness is hidden in the implementation.  These methods were never
APIs when dynalink API was created.

Thanks,

-Sundar

Re: RFR 8157241: Remove javac warnings of Nashorn "ant clean test"

2016-05-19 Thread Marcus Lagergren 
+1

> On 18 May 2016, at 14:01, Sundararajan Athijegannathan 
>  wrote:
> 
> Please review http://cr.openjdk.java.net/~sundar/8157241/ for
> https://bugs.openjdk.java.net/browse/JDK-8157241
> 
> Thanks,
> 
> -Sundar
>

Re: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth

2016-05-19 Thread Marcus Lagergren 
+1

> On 18 May 2016, at 18:36, Hannes Wallnöfer  wrote:
> 
> Please review JDK-8066229: Fuzzing bug: Can't find scope depth
> 
> http://cr.openjdk.java.net/~hannesw/8066229/webrev/
> 
> This adds a test case for bug that is already fixed. It also removes the 
> EXPECTED file added in the previous commit (JDK-8157250).
> 
> Thanks,
> Hannes

Re: Review request for JDK-8066229: Fuzzing bug: Can't find scope depth

2016-05-19 Thread Michael Haupt 
Hi Hannes,

lower-case thumbs up.

Best,

Michael

> Am 18.05.2016 um 18:36 schrieb Hannes Wallnöfer :
> 
> Please review JDK-8066229: Fuzzing bug: Can't find scope depth
> 
> http://cr.openjdk.java.net/~hannesw/8066229/webrev/
> 
> This adds a test case for bug that is already fixed. It also removes the 
> EXPECTED file added in the previous commit (JDK-8157250).
> 
> Thanks,
> Hannes

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment

Re: Review request for JDK-8157263: Octane svn repository no longer exists

2016-05-19 Thread Michael Haupt 
Hi Hannes,

lower-case thumbs up.

Best,

Michael

> Am 18.05.2016 um 19:50 schrieb Hannes Wallnoefer 
> :
> 
> Please review JDK-8157263: Octane svn repository no longer exists:
> 
> http://cr.openjdk.java.net/~hannesw/8157263/webrev/
> 
> Thanks,
> Hannes

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment