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 15:05:27 GMT
Hi Elena,

The changes look reasonable to me. Good work! Hope to see it committed soon.

Thanks
Evgueni

On 10/24/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> I attached the patch to H-1931 which fixes algorithm of checking
> accessibility. Please review!
>
> On 10/24/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> >
> > 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
> > >
> >
>
>
>
> --
> Thanks,
> Elena
>
>

Mime
View raw message