harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elena Semukhina" <elena.semukh...@gmail.com>
Subject Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Date Tue, 24 Oct 2006 13:05:20 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message