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 Thu, 26 Oct 2006 07:12:57 GMT
On 10/26/06, Nathan Beyer <nbeyer@gmail.com> wrote:
>
> 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.


Nathan, here is the bug URL:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356
I tried ecj.jar 3.3 and still was able to reproduce the bug.

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. :)


The test I submitted to Eclipse bugzilla fails on RI, IBM VM and DRLVM when
compiled with ECJ and passes being compiled with javac.

The fix submitted to H-1931 takes this bug into account and relies on the
private modifier of a local class which is provided by Eclipse compiler (but
not provided by javac). So the accessibility control algorithm takes
different branches for the classes compiled with javac and ECJ for now.



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



-- 
Thanks,
Elena

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message