You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Evgueni Brevnov <ev...@gmail.com> on 2006/10/24 06:07:07 UTC
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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?
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 <nb...@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 <gs...@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
> >
>
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Posted by Elena Semukhina <el...@gmail.com>.
On 10/24/06, Evgueni Brevnov <ev...@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?
The spec says about class declaration but not compiled class modifiers.
Sun's compiler provides the "public" modifier for a local class while ECJ
sets it to "private", which seems more appropriate.
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 <nb...@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 <gs...@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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Posted by Elena Semukhina <el...@gmail.com>.
On 10/24/06, Evgueni Brevnov <ev...@gmail.com> wrote:
>
> 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...
I attached a test that demonstrates the bug in ECJ. It does not provide
enclosing method and enclosing class info for local classes so we cannot
rely on Class.getEnclosingClass() until the bug is fixed. May we hope for
the quick fix?
Evgueni
>
>
> On 10/24/06, Nathan Beyer <nb...@gmail.com> wrote:
> > On 10/23/06, Evgueni Brevnov <ev...@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 <nb...@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 <gs...@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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Posted by Evgueni Brevnov <ev...@gmail.com>.
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 <nb...@gmail.com> wrote:
> On 10/23/06, Evgueni Brevnov <ev...@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 <nb...@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 <gs...@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
> > > >
> > >
> >
>
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Posted by Nathan Beyer <nb...@gmail.com>.
On 10/23/06, Evgueni Brevnov <ev...@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 <nb...@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 <gs...@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
> > >
> >
>