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
