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 10:21:10 GMT
I think getEnclosingClass returns null not because of the "strange"
name but because it doesn't generate the enclosing method attribute
for local classes.

Evgueni

On 10/24/06, Gregory Shimansky <gshimansky@gmail.com> wrote:
> 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 <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
>

Mime
View raw message