harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Evgueni Brevnov" <evgueni.brev...@gmail.com>
Subject Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Date Tue, 24 Oct 2006 04:07:07 GMT
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
It is a compile-time error if a local class declaration contains any
one of the following access modifiers: public, protected, private, or
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.


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
> >

View raw message