On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
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?
The spec says about class declaration but not compiled class modifiers. Sun's compiler provides the "public" modifier for a local class while ECJ sets it to "private", which seems more appropriate. 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 > > >
-- Thanks, Elena
