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])
