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
