Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Alexey, I didn't mean to fix getEnclosing method impl itself. Yes the compiler should provide such info. Sorry for confusion... Evgueni On 10/30/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: 2006/10/30, Nathan Beyer <[EMAIL PROTECTED]>: > I see that one of the ECJ bugs has been fixed [1], but the other was > closed awaiting more information [2], but may be resolved as well. > > The fix should be available to test from a nightly build of the > Eclipse 3.3 stream. Would someone like to verify that the discussed > issues are resolved? Nathan, I've verified [2]. Elena, Evgueni, The H-1931_ReflectExporter.patch is really the proper fix, thank you. Regarding the question 3) of Evgueni's earlier post, I believe there is nothing to fix in getEnclosingClass() impl: if compiler did not care to provide such info, there is no reliable way to determine it (using class name etc). And provided [1] is fixed in ECJ, Elena's tests should pass. -- Alexey > > [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356 > On 10/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > > Elena Semukhina wrote: > > > 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. > > > > See also > > https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 > > > > which I have cross-referenced to Bug#162356. > > > > Regards, > > Tim > > > > -- > > > > Tim Ellison ([EMAIL PROTECTED]) > > > > >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
2006/10/30, Nathan Beyer <[EMAIL PROTECTED]>: I see that one of the ECJ bugs has been fixed [1], but the other was closed awaiting more information [2], but may be resolved as well. The fix should be available to test from a nightly build of the Eclipse 3.3 stream. Would someone like to verify that the discussed issues are resolved? Nathan, I've verified [2]. Elena, Evgueni, The H-1931_ReflectExporter.patch is really the proper fix, thank you. Regarding the question 3) of Evgueni's earlier post, I believe there is nothing to fix in getEnclosingClass() impl: if compiler did not care to provide such info, there is no reliable way to determine it (using class name etc). And provided [1] is fixed in ECJ, Elena's tests should pass. -- Alexey [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356 On 10/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: > Elena Semukhina wrote: > > 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. > > See also > https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 > > which I have cross-referenced to Bug#162356. > > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
I see that one of the ECJ bugs has been fixed [1], but the other was closed awaiting more information [2], but may be resolved as well. The fix should be available to test from a nightly build of the Eclipse 3.3 stream. Would someone like to verify that the discussed issues are resolved? -Nathan [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=162356 On 10/26/06, Tim Ellison <[EMAIL PROTECTED]> wrote: Elena Semukhina wrote: > 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. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 which I have cross-referenced to Bug#162356. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Elena Semukhina wrote: > 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. See also https://bugs.eclipse.org/bugs/show_bug.cgi?id=162296 which I have cross-referenced to Bug#162356. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED])
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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.
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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. 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. :) -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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Is this a fix or a workaround? Is there a bug in ECJ? geir 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 >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Hi Elena, The changes look reasonable to me. Good work! Hope to see it committed soon. Thanks Evgueni On 10/24/06, Elena Semukhina <[EMAIL PROTECTED]> 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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote: Nathan,I tend to agree with you. I believe even with "private" modifier setIllegalAccessException should not be thrown in the test case. What really worries me is why getEnclosingClass returns null...it is a bugdefinitelyI 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? EvgueniOn 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: > On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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> > > > It is a compile-time error if a local class declaration contains any> > one of the following access modifiers: public, protected, private, or > > static.> > > > 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 <[EMAIL PROTECTED]> 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 <[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 spec
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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 definitelyI think it should be resolved first... Evgueni On 10/24/06, Nathan Beyer <[EMAIL PROTECTED]> wrote: On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 > > It is a compile-time error if a local class declaration contains any > one of the following access modifiers: public, protected, private, or > static. > > 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 <[EMAIL PROTECTED]> 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 <[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 > > > > > >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/24/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. 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 <[EMAIL PROTECTED]> 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 <[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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
On 10/23/06, Evgueni Brevnov <[EMAIL PROTECTED]> 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 It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. 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 <[EMAIL PROTECTED]> 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 <[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 > > >
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 It is a compile-time error if a local class declaration contains any one of the following access modifiers: public, protected, private, or static. 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 <[EMAIL PROTECTED]> 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 <[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 >
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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 <[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
Re: [drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
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
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. -Nathan On 10/21/06, Elena Semukhina <[EMAIL PROTECTED]> wrote: Hi all, after classlib build system has switched to use ECJ, one test in swing module started to fail on drlvm (win/linux). Actually the failure is not related to swing functionality. I've filed JIRA issue https://issues.apache.org/jira/browse/HARMONY-1931 and attached a simple test to reproduce the failure. All interested parties are welcome to look at this issue! -- Thanks, Elena
[drlvm][eclipse compiler] the test compiled with ECJ fails on drlvm
Hi all, after classlib build system has switched to use ECJ, one test in swing module started to fail on drlvm (win/linux). Actually the failure is not related to swing functionality. I've filed JIRA issue https://issues.apache.org/jira/browse/HARMONY-1931 and attached a simple test to reproduce the failure. All interested parties are welcome to look at this issue! -- Thanks, Elena
