Community
Participate
Working Groups
package foo; class Base { abstract void method1(); } package foo; class BaseImpl { void method1() {} } package bar; class ExtendedImpl extends BaseImpl { //This class reports false error. }
Your testcase is indeed incorrect, and we correctly report this error. BaseImpl.method1() isn't visible from ExtendedImpl since it is package private. We may have incorrectly accepted such code in the past though. Both javac 1.4.1 and jikes are also correctly rejecting such code.
In the original example posted to the news group differs a liitle bit, please check this example also: Name of the psoting to eclispe.tools: "Compiler Bug (?) in M5" Hello I believe there is a bug in the Java compiler of M5: In my programms exits code like the following and it compiles without errors for years, but now it don't compile: SOURCE 1 (compiles without error) -------------------------------------------------------------------------- package de.neze.bugreport.eclipse1; public abstract class Main { abstract void abstractMethod(); public static class InnerMainExtension extends Main { public void abstractMethod() { } } } class EtensionOfInnerMainExtension extends Main.InnerMainExtension { } -------------------------------------------------------------------------- SOURCE 2 (compiles with error) -------------------------------------------------------------------------- package de.neze.bugreport.eclipse1.related; import de.neze.bugreport.eclipse1.*; public class EtensionOfInnerMainExtension extends Main.InnerMainExtension { } // Compiler Error Message: // Error This class must implement the inherited abstract method Main. // abstractMethod(), but cannot override it since it is not visible from // EtensionOfInnerMainExtension. Either make the type abstract or make the // inherited method visible. EtensionOfInnerMainExtension.java // WSW-Test/src/de/neze/bugreport/eclipse1/related line 3 --------------------------------------------------------------------------
I see, and confirm we have a bug on the second testcase. Likely a regression caused by fix for bug 30805. Good find, will investigate asap.
Fixed in latest. Will post a patch.
*** Bug 31450 has been marked as a duplicate of this bug. ***
Is bug 31450 *actually* a duplicate of this bug? It involves neither inner classes nor the problematic previous source code. Does the fix for this bug also fix 31450?
*** Bug 31344 has been marked as a duplicate of this bug. ***
Philippe, I didn't understand your first comment. I can get this code to compile clean on JDK 1.4. there is no reason that ExtendedImpl needs visibility to "method1()" because the method is not abstract. Then later on you state that the fix is released. Is the fix for the original bug, or for the second test case that was appended later?
The code in the original post does not compile with javac, but for reasons unrelated to the bug. Here is code that compiles with javac (1.4.1) and not under Eclipse. If BaseImpl.method1() is package protected, Eclipse has no problem with it, but if you widen the visibility to protected, you get a false error. ----------------------------- package foo; abstract class Base { abstract void method1(); } ----------------------------- package foo; public class BaseImpl extends Base { protected void method1() {} } ----------------------------- package bar; public class ExtendedImpl extends foo.BaseImpl { //This class reports false error. }
Is it because I had a typo? BaseImpl extends Base, but I forgot the extends part.
*** Bug 31475 has been marked as a duplicate of this bug. ***
I got a "good find" for my psoting and that makes me bold enough to ask a totally useless question: Why is the first (foo/bar) example not compiled by most compilers? Reason for this question: I know situation where this construction is usefull.
Randy - indeed the missing 'extends Base' did make the difference and fooled me into not seeing the actual regression in our compiler. Markus(?) - maybe I am missing something obvious, but I don't see how the original example would be a useful pattern. I'd rather think that the multiple inheritance would rather make sense here, so you could inherit an implementation separately from an abstract method, however this would require an interface, and their abstract methods are public, so a public implementation must therefore exists. The bug we had was related to abstract methods with package default visibility.
Sorry I don't read the first example completly. I talked about a modifed version of the example above: ----------------------------- package foo; abstract class Base { abstract void method1(); } ----------------------------- package foo; public class BaseImpl extends Base { void method1() {} } ----------------------------- package bar; public class ExtendedImpl extends foo.BaseImpl { //This class reports false error. } ----------------------------- If this compiles I have no further question ... . I compiled this pattern with javac a few weeks ago and I had to add the public modifier to the method1() implementation. Sorry again.
No problem. The modified example compiles clear now (as it does with javac1.4.1 and jikes1.18). You don't have to make the method public.
*** Bug 31591 has been marked as a duplicate of this bug. ***
*** Bug 31809 has been marked as a duplicate of this bug. ***
*** Bug 32083 has been marked as a duplicate of this bug. ***
*** Bug 32545 has been marked as a duplicate of this bug. ***
Verified.
*** Bug 32579 has been marked as a duplicate of this bug. ***
