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
