harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [kernel][reflect] Should we copy bug of RI JVM ?
Date Mon, 28 Aug 2006 11:18:54 GMT
On 8/28/06, Alexey Varlamov <alexey.v.varlamov@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message