On 10/26/06, Nathan Beyer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[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 > > >> > > > >> > > > > > > > > > > > > > > > -- > Thanks, > Elena > >
-- Thanks, Elena
