harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Date Thu, 26 Oct 2006 02:09:13 GMT
If this is a bug, have you logged an issue with Eclipse? If not,
please do so and post the bug URL here, so we can monitor it. You may
want to try compiling this with the latest ECJ JAR (3.3 nightly) to
see if it's still generating the same bytecode.

Considering that the RI can run this code fine, I'd be surprised if
this is considered a bug. I've been surprised before though. :)

-Nathan

On 10/25/06, Elena Semukhina <elena.semukhina@gmail.com> wrote:
> On 10/25/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >
> > Is this a fix or a workaround?  Is there a bug in ECJ?
> >
> > geir
>
>
> Me and Evgueni consider this a fix.
> We should adapt the algorithm of accessibility control to working with
> classes compiled with both compilers. The difference berween compilers is
> that javac does not provide any modifiers to local classes while ECJ makes
> them private. On the other hand, javac provides some data for local classes
> while ECJ does not  (and here is a bug in ECJ).
> The algorithm of checking accessibility has been modified so that it does
> not fully rely on the data provided by compiler for local classes but makes
> an additional check of local class modifiers to ensure proper accessibility
> control for local classes.
>
>
>
> Elena Semukhina 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