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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
>
