On 10/24/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> 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 <nbeyer@gmail.com> 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 <gshimansky@gmail.com> 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