Community
Participate
Working Groups
Build Identifier: 20100617-1415 create a 1) baseInterface extends genericInterface<ConcreteClass> 2) abstract abstractClass implements baseInterface 3) abstract abstractSubClass extends abstractClass 4) concreteClass extends abtractsubclass abstract subclass gives - The hierarchy of the type AbstractSubClass is inconsistent Reproducible: Always
Created attachment 174625 [details] eclipse project showing the problem
Can you report the full version & build id by copying & pasting from Help + About Eclipse SDK, including any prefixes (M/I etc). I don't see any problems if I create a java project by importing the files from the attached archive. I did clean & build several times to no avail. This is on 3.6 as well as HEAD. This looks like a duplicate of bug# 294057 : Indeed if I back out the fix for that bug, I get the problem you cite consistently.
here's the eclipse version Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415
AbstractubClass should show the error
(In reply to comment #3) > here's the eclipse version > Eclipse Java EE IDE for Web Developers. > > Version: Helios Release > Build id: 20100617-1415 I have downloaded these exact bits and tested it with the test case you have supplied by importing the project. I don't see the problem. I assume you were trying to isolate & put together a small test case from your project that was showing the problem: If so, could you verify if the problem does show up on this small case you have ? I would suggest you start with a clean workspace, import project from the zip in comment#1 and see. Anything else that could be peculiar to your set up that would explain why I am not seeing the problem ? Jay, can you try your hand at reproducing it with 3.6 as well as the EE IDE ? TIA.
(In reply to comment #5) > (In reply to comment #3) > > here's the eclipse version > > Eclipse Java EE IDE for Web Developers. > > > > Version: Helios Release > > Build id: 20100617-1415 > > I have downloaded these exact bits and tested it with the > test case you have supplied by importing the project. I > don't see the problem. > > I assume you were trying to isolate & put together a small > test case from your project that was showing the problem: If so, > could you verify if the problem does show up on this small case > you have ? I would suggest you start with a clean workspace, > import project from the zip in comment#1 and see. > > Anything else that could be peculiar to your set up that would > explain why I am not seeing the problem ? > > Jay, can you try your hand at reproducing it with 3.6 as well > as the EE IDE ? TIA. I am able to reproduce every time on the Helios build I mentioned. on windows Vista, and Ubuntu 10.04 with JDK1.6_18 and 1.6_20
Would it be possible for you to test against the eclipse classic (eclipse-SDK-3.6-win32.zip) version, using out of the box settings in a new, clean workspace with just the offending case ? I wonder if it is some settings on your side that somehow triggers it. Can you attach the file org.eclipse.jdt.core.prefs from the .settings folder of the test case project ?
(In reply to comment #7) > Would it be possible for you to test against the eclipse > classic (eclipse-SDK-3.6-win32.zip) version, Actually, Jay (Thanks!) showed me how to see the problem. I was looking at the problems view and since there was nothing there, I concluded it is not reproducible. The problem does show up in the editor. I'll investigate and see what is going on here.
(In reply to comment #8) > Actually, Jay (Thanks!) showed me how to see the problem. > I was looking at the problems view and since there was > nothing there, I concluded it is not reproducible. The > problem does show up in the editor. > I'll investigate and see what is going on here. Then this means it is a reconciling issue only.
You can actually reproduce it using the plain compiler by doing the following steps: 1) Put all 5 files into a folder called d:\tests\src. 2) Compile all files at once and put the output into a folder bin. Compiler arguments are: d:\tests\src -classpath d:\tests\src;d:\tests\bin -d d:\tests\bin -1.6 3) All .class files will be created. 4) Now run the following compilation. d:\tests\src\AbstractSubClass.java -classpath d:\tests\src;d:\tests\bin -d d:\tests\bin -1.6 You should get the following error: [compiled 20 lines in 469 ms: 42.6 lines/s] [3 .class files generated] ---------- 1. ERROR in D:\tests\src\AbstractSubClass.java (at line 2) public abstract class AbstractSubClass extends AbstractClass { ^^^^^^^^^^^^^^^^ The hierarchy of the type AbstractSubClass is inconsistent ---------- ---------- 2. ERROR in D:\tests\src\ConcreteClass.java (at line 2) extends AbstractSubClass { ^^^^^^^^^^^^^^^^ Cycle detected: a cycle exists in the type hierarchy between ConcreteClass and AbstractSubClass ---------- 2 problems (2 errors) If the second compilation is only retrieving dependent types from binary, then it works fine. The reconciler is getting dependent types from source. And the step (4) would "reproduce" the way the reconciler works. This might make it easier to debug. I'll provide a regression test inside the GenericTypeTest suite.
Released disabled regression test for this bug. See org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#_test1465. The test should compile, but it reports an error right now.
(In reply to comment #10) > You can actually reproduce it using the plain compiler by doing the following > steps: > 1) Put all 5 files into a folder called d:\tests\src. > 2) Compile all files at once and put the output into a folder bin. > Compiler arguments are: > d:\tests\src > -classpath d:\tests\src;d:\tests\bin > -d d:\tests\bin > -1.6 In fact these steps are not needed. As soon as you compile the d:\tests\src\AbstractSubClass.java file alone with the dependant files on the classpath, the problem occurs. This is what the regression test is doing. Hope this help.
(In reply to comment #12) > (In reply to comment #10) [...] > This is what the regression test is doing. > Hope this help. Yes, Thanks, will follow up.
The same problem is also easily reproducible with serializable JPA Entities and Spring Roo. 1. Install STS 2.8.0 and Spring Roo (1.1.5.RELEASE) 2. Create a Roo project (File->New->Other->Spring Roo Project) 3. Set up persistence with Roo command (type into Roo console): persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY 4. Create an abstract base entity: entity --class ~.entities.Base --abstract --mappedSuperclass 5. Create a concrete entity: entity --class ~.entities.Concrete --extends ~.entities.Base 6. Open Base.java in editor and change "public abstract class Base" to "public abstract class Base implements java.io.Serializable" 7. Open Concrete.java in Editor 8. "The hierarchy of the type Concrete is inconsistent error" will appear on type definition line. No error markers will be visible neither in Markers tab or in the project explorer.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
