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 Wed, 25 Oct 2006 07:25:23 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message