I think we have several different items/questions to discuss:
1) Is it legal to generate "private" modifier to a local class? The Java Language Specification, Third Edition part 14.3 states <snip> It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. </snip> So it seems a compiler isn't allowed to put "private" modifier. Thoughts? 2) getEnclosingClass and isLocalClass doesn't give correct result when compiled with ECJ. It seems to be a seperate problem but this can affect the algorithm which determines member accessibility. Seems this should be resolved first. 3) Elena and I looked at the algorithm which determines member accessibility and found a problem in it. To resolve the problem we need to fix getEnclosingClass. So I propose to concentrate on this method for now. Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> 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? -Nathan 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 >
