Hi Elena, The changes look reasonable to me. Good work! Hope to see it committed soon.
Thanks Evgueni On 10/24/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
I attached the patch to H-1931 which fixes algorithm of checking accessibility. Please review! On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: > > I think getEnclosingClass returns null not because of the "strange" > name but because it doesn't generate the enclosing method attribute > for local classes. > > Evgueni > > On 10/24/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > On Tuesday 24 October 2006 05:12 Nathan Beyer wrote: > > > By "inner class" you mean an automatic/local class in this case; a > > > class declared inside a method. It would seem appropriate that a local > > > class is declared private. Only the method that contains the class > > > declaration can see it. > > > > > > Do you disagree with what ECJ is generating? > > > > After reading this thread I think you are right and it is ok to generate > > private attribute for inner classes. > > > > There is another difference between compilers output. Sun compiler and > ECJ > > generate different class names for Test1931_2.java inner class. Sun > compiler > > creates Test1931_2$1LocalClass.class while ECJ creates > > Test1931_2$1$LocalClass.class. > > > > It might be not the cause of the bug in this case, but I wonder whether > naming > > of inner classes is specified somewhere. Shouldn't names be the same for > all > > compilers? > > > > > On 10/23/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote: > > > > On Sunday 22 October 2006 01:08 Nathan Beyer wrote: > > > > > I haven't had a chance to look at the issue (JIRAs down right now, > > > > > probably part of the infrastructure move), but have you tried > > > > > comparing the actual class files of the problematic class or > classes. > > > > > > > > > > I'd suggest compiling the files using ECJ, save them off, compile > with > > > > > Sun/BEA/etc, save them off and then run javap from a single JDK on > > > > > each of the class files and compare them for differences. > > > > > > > > Yes, it is quite interesting how different compilers produce > different > > > > class attributes, it looks like this is the main problem with the > code. > > > > ECJ insists on marking inner classes private. Elena was kind to send > me > > > > another test which she wrote while JIRA was down and it shows even a > > > > bigger difference between the compilers - it produces different > output on > > > > RI. In the 2nd test ECJ creates an inner in anonymous class > > > > Test1931_2$1$LocalClass while Sun creates Test1931_2$1LocalClass. > This > > > > gives different output from cc.getEnclosingClass and cc.isLocalClass > > > > where cc is the used inner class. > > > > > > > > Nevertheless RI allows the access to the inner private class it > seems. It > > > > doesn't throw the exception which drlvm does. The exception source > is > > > > drlvm's kernel class ReflectExporter and the method in question is > > > > allowAccess which calls allowClassAccess at line 113. This check is > the > > > > one and the only chance to return true in this case. > > > > > > > > I've debugged the code with recently implemented debugging support > of > > > > drlvm using eclipse (jdwp agent has to be build for this from > > > > HARMONY-1410, also kernel classes for drlvm aren't compiled with > debug > > > > support, build script has to be hacked) but I just don't know all of > the > > > > access checks specification statements to make a decision which one > is > > > > not correct. > > > > > > > > P.S. I used ecj 3.2 which we use for current classlib compilation. > > > > -- > > Gregory Shimansky, Intel Middleware Products Division > > > -- Thanks, Elena
