You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexey Varlamov <al...@gmail.com> on 2006/08/28 11:41:18 UTC
[kernel][reflect] Should we copy bug of RI JVM ?
There is a test[1] in classlib, which verifies that reflection access
from enclosing class to a private member of a nested class results in
IllegalAccessException.
However, this is against the language specification (para 6.6.1 of the JLS3):
"if the member or constructor is declared private, then access is
permitted if and only if it occurs within the body of the top level class (§7.6)
that encloses the declaration of the member or constructor."
Moreover, the following test reveals inconsistency between standard
access control and reflective one:
---------------------------------
class NestedAccessTest {
static class A {
private static int x = 123;
}
public static void main(String... s) throws Throwable{
System.out.println(A.x);
System.out.println(A.class.getDeclaredField("x").get(null));
}
}
--------------------------------
>java -showversion NestedAccessTest
java version "1.5.0_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
123
Exception in thread "main" java.lang.IllegalAccessException: Class
NestedAccessTest can not access a member of class NestedAccessTest$A
with modifiers "private static"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
at java.lang.reflect.Field.doSecurityCheck(Field.java:954)
at java.lang.reflect.Field.getFieldAccessor(Field.java:895)
at java.lang.reflect.Field.get(Field.java:357)
at NestedAccessTest.main(NestedAccessTest.java:7)
----------------------------------
I found out, this is an acknowledged bug of RI [2], and is ranked TOP#6.
The good news, however, that DRLVM is free of this defect. OTOH, it
surely cannot pass the aforementioned test of the classlib.
So the question: should we fix the test and will IBM VME address this
issue? What is appropriate JIRA category for it?
[1]<testcase classname="tests.api.java.lang.reflect.FieldTest"
name="test_getLjava_lang_Object"/>
[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
--
Alexey Varlamov
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [kernel][reflect] Should we copy bug of RI JVM ?
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Vladimir Gorr wrote:
> On 8/28/06, Alexey Varlamov <al...@gmail.com> wrote:
>>
>> There is a test[1] in classlib, which verifies that reflection access
>> from enclosing class to a private member of a nested class results in
>> IllegalAccessException.
>> However, this is against the language specification (para 6.6.1 of the
>> JLS3):
[SNIP]
>>
>> I found out, this is an acknowledged bug of RI [2], and is ranked TOP#6.
>> The good news, however, that DRLVM is free of this defect. OTOH, it
>> surely cannot pass the aforementioned test of the classlib.
>>
>> So the question: should we fix the test and will IBM VME address this
>> issue? What is appropriate JIRA category for it?
>
>
> I suppose this test should be modified after IBM VME will behave in
> accordance with the specifications if any.
I agree, if IBM will fix it, if they have the problem.
> Certainly, if there are no any objections. IMO we should avoid any bugs
> known for the RI, shouldn't we?
I think that we should fix this, since it's a known bug of the RI that
may be fixed...
I know that Alexey setup a JIRA for it, so we can revisit...
geir
>
> Thanks,
> Vladimir.
>
> [1]<testcase classname="tests.api.java.lang.reflect.FieldTest"
>> name="test_getLjava_lang_Object"/>
>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
>>
>> --
>> Alexey Varlamov
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [kernel][reflect] Should we copy bug of RI JVM ?
Posted by Alexey Varlamov <al...@gmail.com>.
I've created HARMONY-1309 to track this issue.
--
WBR,
Alexey
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [kernel][reflect] Should we copy bug of RI JVM ?
Posted by Vladimir Gorr <vv...@gmail.com>.
On 8/28/06, Alexey Varlamov <al...@gmail.com> wrote:
>
> There is a test[1] in classlib, which verifies that reflection access
> from enclosing class to a private member of a nested class results in
> IllegalAccessException.
> However, this is against the language specification (para 6.6.1 of the
> JLS3):
> "if the member or constructor is declared private, then access is
> permitted if and only if it occurs within the body of the top level class
> (§7.6)
> that encloses the declaration of the member or constructor."
>
> Moreover, the following test reveals inconsistency between standard
> access control and reflective one:
> ---------------------------------
> class NestedAccessTest {
> static class A {
> private static int x = 123;
> }
> public static void main(String... s) throws Throwable{
> System.out.println(A.x);
> System.out.println(A.class.getDeclaredField("x").get(null));
> }
> }
> --------------------------------
> >java -showversion NestedAccessTest
> java version "1.5.0_06"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode)
> 123
> Exception in thread "main" java.lang.IllegalAccessException: Class
> NestedAccessTest can not access a member of class NestedAccessTest$A
> with modifiers "private static"
> at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65)
> at java.lang.reflect.Field.doSecurityCheck(Field.java:954)
> at java.lang.reflect.Field.getFieldAccessor(Field.java:895)
> at java.lang.reflect.Field.get(Field.java:357)
> at NestedAccessTest.main(NestedAccessTest.java:7)
> ----------------------------------
>
> I found out, this is an acknowledged bug of RI [2], and is ranked TOP#6.
> The good news, however, that DRLVM is free of this defect. OTOH, it
> surely cannot pass the aforementioned test of the classlib.
>
> So the question: should we fix the test and will IBM VME address this
> issue? What is appropriate JIRA category for it?
I suppose this test should be modified after IBM VME will behave in
accordance with the specifications if any.
Certainly, if there are no any objections. IMO we should avoid any bugs
known for the RI, shouldn't we?
Thanks,
Vladimir.
[1]<testcase classname="tests.api.java.lang.reflect.FieldTest"
> name="test_getLjava_lang_Object"/>
> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4071957
>
> --
> Alexey Varlamov
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>