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 04:55:15 GMT
Nathan,

I tend to agree with you. I believe even with "private" modifier set
IllegalAccessException should not be thrown in the test case. What
really worries me is why getEnclosingClass returns null...it is a bug
definitely....I think it should be resolved first...

Evgueni


On 10/24/06, Nathan Beyer <nbeyer@gmail.com> wrote:
> On 10/23/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
> > I think we have several different items/questions to discuss:
> >
> > 1) Is it legal to generate "private" modifier to a local class?
> > The Java Language Specification, Third Edition part 14.3 states
> > <snip>
> > It is a compile-time error if a local class declaration contains any
> > one of the following access modifiers: public, protected, private, or
> > static.
> > </snip>
> > So it seems a compiler isn't allowed to put "private" modifier. Thoughts?
>
> This is the part I was commenting, so I put my thoughts here. This is
> from the language specification and only applies to Java syntax and
> yes, that's an error and it makes sense. But from the class file
> (bytecode) perspective, a local class must be defined in its own file
> and this class is not accessible by any other class in the package
> (not default or package-private scope), so I would think that it
> should be marked private.
>
> My reasoning would be that the language spec is saying a class
> modifier is illegal for a local class because within the scope of a
> method there is no concept or more or less accessible than the method.
> Thus, if we promoted this concept to an inner class, it would be
> conceptually the same as a private inner class because it would be off
> limits from other classes in the same package.
>
> I think what the language specification is say here is much like the
> scope identifiers of methods on an interface. If the interface is
> public, all methods are public, even if they aren't declared public.
>
> >
> > 2) getEnclosingClass and isLocalClass doesn't give correct result when
> > compiled with ECJ. It seems to be a seperate problem but this can
> > affect the algorithm which determines member accessibility. Seems this
> > should be resolved first.
> >
> > 3) Elena and I looked at the algorithm which determines member
> > accessibility and found a problem in it. To resolve the problem we
> > need to fix getEnclosingClass. So I propose to concentrate on this
> > method for now.
> >
> > Evgueni
> >
> > On 10/24/06, Nathan Beyer <nbeyer@gmail.com> 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?
> > >
> > > -Nathan
> > >
> > > 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
> > > >
> > >
> >
>

Mime
View raw message