On 3/28/19 1:39 PM, Alan Bateman wrote:
On 28/03/2019 16:43, Mandy Chung wrote:
:
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01
I think this looks okay. One minor nit is that
newIllegalAccessException doesn't throw IAE.
Thanks Alan.
CSR:
On 28/03/2019 16:43, Mandy Chung wrote:
:
Updated webrev:
http://cr.openjdk.java.net/~mchung/jdk13/webrevs/8221530/webrev.01
I think this looks okay. One minor nit is that newIllegalAccessException
doesn't throw IAE.
-Alan
On 3/28/19 7:48 AM, Peter Levart wrote:
Hi,
On 3/28/19 9:40 AM, Alan Bateman wrote:
On 27/03/2019 23:17, Mandy Chung wrote:
:
The proposed fix is to perform proper access check. When there is no
caller frame, it only allows to access to public members of a public
type
in an
On 3/28/19 8:46 AM, Peter Levart wrote:
On 3/28/19 4:08 PM, Alan Bateman wrote:
On 28/03/2019 14:48, Peter Levart wrote:
:
In addition, if access from null caller is granted and it is
performed to a member in a "concealed" package, there's no warning
displayed
The proposed check is
On 3/28/19 4:46 PM, Peter Levart wrote:
Reflection.verifyMemberAccess() is called not only from
AccessibleObject.slowVerifyAccess() but from elsewhere too.
For example, from ReflectUtil.ensureMemberAccess which is used in @CS
AtomicXxxFieldUpdater(s), or from @CS
On 3/28/19 4:08 PM, Alan Bateman wrote:
On 28/03/2019 14:48, Peter Levart wrote:
:
In addition, if access from null caller is granted and it is
performed to a member in a "concealed" package, there's no warning
displayed
The proposed check is that the package is exported unconditionally
On 3/28/19 1:40 AM, Alan Bateman wrote:
On 27/03/2019 23:17, Mandy Chung wrote:
:
The proposed fix is to perform proper access check. When there is no
caller frame, it only allows to access to public members of a public
type
in an unconditional exported API package.
The approach seems
On 28/03/2019 14:48, Peter Levart wrote:
:
In addition, if access from null caller is granted and it is performed
to a member in a "concealed" package, there's no warning displayed
The proposed check is that the package is exported unconditionally so it
will fail, no warning needed. I think
On 3/28/19 3:48 PM, Peter Levart wrote:
In addition, if access from null caller is granted and it is performed
to a member in a "concealed" package, there's no warning displayed
(the further logic in the AccessibleObject is skipped).
What would it look like if AccessibleObject was left
Hi,
On 3/28/19 9:40 AM, Alan Bateman wrote:
On 27/03/2019 23:17, Mandy Chung wrote:
:
The proposed fix is to perform proper access check. When there is no
caller frame, it only allows to access to public members of a public
type
in an unconditional exported API package.
The approach seems
On 27/03/2019 23:17, Mandy Chung wrote:
:
The proposed fix is to perform proper access check. When there is no
caller frame, it only allows to access to public members of a public type
in an unconditional exported API package.
The approach seems reasonable to me and we should, at some point,
Hi Mandy,
This sounds quite reasonable to me. If there is no calling context then
only public entities of publicly accessible packages should be
accessible. JNI itself does not apply access checks so JNI code should
be using direct field access, and not core reflection, if it needs to
bypass
Looks good.
-Sundar
On 28/03/19, 4:47 AM, Mandy Chung wrote:
This is to fix a regression introduced in JDK 12 by JDK-8206240.
This impacts only native application that creates JVM via JNI
and also invokes Field::getField (or other reflection API) via
JNI that triggers reflection access check
This is to fix a regression introduced in JDK 12 by JDK-8206240.
This impacts only native application that creates JVM via JNI
and also invokes Field::getField (or other reflection API) via
JNI that triggers reflection access check against the caller class.
The regression happens only when there
14 matches
Mail list logo
