Error de compilación de Eclipse: la jerarquía del tipo 'Nombre de clase' es inconsistente


139

He descargado un software de código abierto escrito en Java e intenté compilarlo con Eclipse. Recibí el error: " La jerarquía del tipo 'Nombre de clase' es inconsistente " en algunos archivos. ¿Qué causa estos errores y cómo los soluciono?

Respuestas:


161

Significa que está intentando implementar una interfaz no existente o está ampliando una clase no existente.

Intenta actualizar tu Eclipse.

Si no funciona, puede significar que tiene una referencia a un JAR que no está en la ruta de compilación. Verifique el classpath de su proyecto y verifique que el jar que contiene la interfaz o la clase esté en él.


2
En el mismo sentido, tuve una dependencia de Maven que estaba causando este error en Spring Tool Suite, la solución fue hacer un Maven> Download Sourceen la dependencia en cuestión.
MrLore

felicitaciones a ti @lagrantmere
Shailesh Pratapwar

2
También verifique que el padre se esté compilando. En mi caso, sabía que la superclase existía, pero en realidad no se estaba compilando correctamente.
Joseph Rajeev Motha

2
Tuve una clase que extendía una clase abstracta que implementaba una interfaz faltante (renombrada por eclipse)
Aquarius Power

44
En mi caso, estaba extendiendo una clase que estaba en la ruta de clase (un jar), pero extendió una tercera clase que estaba en un jar diferente que no estaba en mi classpath.
JustinKSU

15

A veces sucede cuando agrega un frasco que USTED necesita, pero no incluye los frascos que necesita. En mi caso, agregar todos los frascos en tomcat / lib me ayudó a resolver este problema. Estoy trabajando en una aplicación web.


Gracias, este fue mi problema. Incluí las bibliotecas GWT, pero me faltaba el jar API de servlet de Java (servlet-api-3.1.jar de Jetty en este caso).
Jamie

13

Verifique sus errores (pestaña "marcadores"). También tuve el siguiente error:

El archivo de la biblioteca requerida en el proyecto no se puede leer ...

y cuando eso se solucionó, el "error inconsistente" desapareció.

En realidad, agregué jarras a la ruta de compilación, pero por alguna razón no se pudieron leer con error

El archivo de la biblioteca requerida en el proyecto no se puede leer o no es un archivo ZIP válido

Por lo tanto, los agregué como "Frascos externos" ¡Eso ayudó y todos los problemas de compilación ya no existían!


5

Tuve este problema después de actualizar el JDK a una nueva versión. Tuve que actualizar las referencias a las bibliotecas en Project Properties / Java Build Path.


4

Un caso más que he tenido. Proporcione la ruta correcta del proyecto e impórtela a eclipse.

Luego vaya a Proyecto -> Limpiar -> Limpiar todos los proyectos.



2

Verá este error en caso de que alguna clase en su archivo de biblioteca que tiene en classpath haga referencia a clases no existentes que podrían estar en otro archivo jar. Aquí, recibí este error cuando no agregué org.springframework.beans-3.1.2.RELEASE.jary extendí una clase desde org.springframework.jdbc.core.support.JdbcDaoSupport, que estaba en org.springframework.jdbc-3.1.2.RELEASE.jarmi classpath.


2

El problema puede ser que haya incluido frascos incorrectos. Tuve el mismo problema y la razón fue que había incluido una biblioteca JRE predeterminada incorrecta en la ruta de compilación del proyecto. Había instalado Java con otra versión e incluía archivos JRE de Java con una versión diferente. (Instalé JRE 1.6 en mi sistema y tenía la biblioteca 1.7 de JRE incluida en la ruta de compilación debido a Java instalado previamente). Puede verificar si la biblioteca JRE que ha incluido en la ruta de compilación es de la versión correcta, es decir. de la versión de Java que ha instalado en su sistema.


2

He experimentado este problema en Eclipse Juno, la causa raíz fue que, aunque algunas jarras de primavera fueron incluidas por dependencias transitorias de Maven, se incluyeron en versiones incorrectas.

Por lo tanto, debe verificar si utiliza un marco modularizado como resorte que cada módulo (o al menos el más importante: núcleo, beans, contexto, aop, tx, etc.) estén en la misma versión.

Para resolver el problema, he usado exclusiones de dependencia de Maven para evitar versiones incorrectas de dependencias transitorias.


2

Error: la jerarquía del tipo "nombre de clase" es un error inconsistente.

solución: la clase OtherDepJar {} -> está dentro de "other.dep.jar" .

La clase DepJar extiende OtherDepJar {} -> está dentro de "dep.jar" .

class ProblematicClass extiende DepJar {} -> está dentro del proyecto actual.

Si dep.jar está en el classpath del proyecto, pero other.dep.jar no está en el classpath del proyecto, Eclipse mostrará el mensaje "La jerarquía del tipo ... es un error inconsistente"


1

Para mí, el problema se debió a importaciones incorrectas. De hecho, uno necesita actualizar las importaciones después de agregar la biblioteca de soporte v7.

Se puede solucionar haciendo lo siguiente, para cada clase de su proyecto :

  1. Eliminar todas las líneas con import android.[*], en cada clase
  2. Reorganice sus importaciones: en el menú contextual, seleccione Origen / Organizar importaciones o (CTRL + MAYÚS + O)
  3. Cuando se le solicite, seleccione las bibliotecas android.support.[*](y no android.[*]).

1

Definitivamente fue porque faltaban dependencias que no estaban en mi maven pom.xml.

Por ejemplo, quería crear pruebas de integración para mi implementación del sitio de demostración de comercio electrónico de hoja ancha.

Había incluido un tarro de hoja ancha con pruebas de integración del comercio de hoja ancha para reutilizar sus archivos de configuración y clases de prueba base. Ese proyecto tenía otras dependencias de prueba que no había incluido y recibí el error "jerarquía inconsistente".

Después de copiar las "dependencias de prueba" de broadleaf / pom.xml y las variables de propiedades asociadas que proporcionaron las versiones para cada dependencia en broadleaf / pom.xml, el error desapareció.

Las propiedades fueron:

    <geb.version>0.9.3</geb.version>
    <spock.version>0.7-groovy-2.0</spock.version>
    <selenium.version>2.42.2</selenium.version>
    <groovy.version>2.1.8</groovy.version>

Las dependencias fueron:

<dependency>
            <groupId>org.broadleafcommerce</groupId>
            <artifactId>integration</artifactId>
            <type>jar</type>
            <classifier>tests</classifier>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.broadleafcommerce</groupId>
            <artifactId>broadleaf-framework</artifactId>
            <version>${blc.version}</version><!--$NO-MVN-MAN-VER$ -->
            <classifier>tests</classifier>
        </dependency>
        <dependency>
            <groupId>com.icegreen</groupId>
            <artifactId>greenmail</artifactId>
            <version>1.3</version>
            <type>jar</type>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.11</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymock</artifactId>
            <version>2.5.1</version>
            <type>jar</type>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.easymock</groupId>
            <artifactId>easymockclassextension</artifactId>
            <version>2.4</version>
            <type>jar</type>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.testng</groupId>
            <artifactId>testng</artifactId>
            <version>5.9</version>
            <type>jar</type>
            <classifier>jdk15</classifier>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.codehaus.groovy</groupId>
            <artifactId>groovy-all</artifactId>
            <version>${groovy.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.gebish</groupId>
            <artifactId>geb-core</artifactId>
            <version>${geb.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.gebish</groupId>
            <artifactId>geb-spock</artifactId>
            <version>${geb.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.spockframework</groupId>
            <artifactId>spock-core</artifactId>
            <version>${spock.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-support</artifactId>
            <version>${selenium.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-firefox-driver</artifactId>
            <version>${selenium.version}</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.seleniumhq.selenium</groupId>
            <artifactId>selenium-chrome-driver</artifactId>
            <version>${selenium.version}</version>
            <scope>test</scope>
        </dependency>
  <!-- Logging -->
            <dependency>
                <groupId>log4j</groupId>
                <artifactId>log4j</artifactId>
                <version>1.2.12</version>
                <type>jar</type>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-log4j12</artifactId>
                <version>1.6.1</version>
                <type>jar</type>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>jcl-over-slf4j</artifactId>
                <version>1.6.1</version>
                <type>jar</type>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-api</artifactId>
                <version>1.6.1</version>
                <type>jar</type>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.hsqldb</groupId>
                <artifactId>hsqldb</artifactId>
                <version>2.3.1</version>
                <type>jar</type>
                <scope>test</scope>
            </dependency>

1

Si la clase extendida tiene el problema, se mostrará el mensaje de error anterior.

Ejemplo

class Example extends Example1 {

}

solucionar los problemas en Example1


1

Tuve el mismo marcador de problema exacto y lo resolví eliminando la anotación @Override de un método que, de hecho, fue la primera implementación (el "super" es un método abstracto) y no una anulación.


1

En mi caso, las referencias de importación en muchas de las clases contenían una palabra adicional. Lo resolví editando todos los archivos para tener las importaciones correctas. Empecé a hacer las ediciones manualmente. Pero cuando vi el patrón, lo automaticé con un hallazgo ... reemplazar en eclipse. Esto resolvió el error.



0

También estaba teniendo este problema ... descubrí que la jerarquía de la clase que estaba lanzando esta excepción, no puede rastrearse desde su clase raíz por eclipse ... Explico:

En mi caso, tengo 3 proyectos java: A, B y C ... donde A y B son proyectos maven y C un proyecto de eclipse java normal ...

En el proyecto A, tengo la interfaz "interfaceA" ... En el proyecto B, tengo la interfaz "interfaceB" que extiende "interfaceA" En el proyecto C, tengo la clase concreta "classC" que implementa "interfaceB"

El "proyecto C" incluía el "proyecto B" en su ruta de compilación pero no el "proyecto A" (por lo que esa fue la causa del error) .... Después de incluir el "proyecto A" dentro de la ruta de compilación de "C" , todo volvió a la normalidad ...


0

Tuve una clase que extiende LabelProvider en un proyecto con OSGi, allí ocurrió el error. La solución fue: Agregar org.eclipse.jface a los complementos requeridos en el manifiesto.mf en lugar de importar los paquetes individuales como org.eclipse.jface.viewers


0

si está importando el proyecto eclipse solo 1. Vaya a la configuración de ruta de compilación de Java en las propiedades del proyecto. 2. En caso de que la biblioteca del sistema JRE tenga un signo de error adjunto, haga doble clic para abrir la ventana Editar biblioteca 3. Cambie el entorno de ejecución a la versión correcta de Java del sistema o elija editar las otras configuraciones marcando la asignación de botones de radio a ellos 4. Haga clic en finalizar


0

Al importar un proyecto GWT en Eclipse sin instalar "Google Plugin for Eclipse", esto ocurrirá. Después de instalar "Google Plugin para Eclipse", este error desaparecerá.


0

Haga clic derecho en la carpeta del proyecto y seleccione "Java Build Path". En "Java Build Path" debería poder ver las bibliotecas. Eclipse mostrará errores en cualquiera de esas bibliotecas. La solución de esos problemas ayudará a resolver el problema.


0

Tuve este error después de hacer una fusión de git desde una rama donde mis clases extendieron una nueva interfaz. Fue suficiente para actualizar (F5) el árbol de archivos en el marco del Explorador de paquetes de Eclipse.

Parece que Eclipse no actualizó todo correctamente y, por lo tanto, las clases estaban ampliando una interfaz aún no existente. Después de actualizar, todos los errores desaparecieron.


0

Tuve que cambiar de Eclipse Oxygen que obtuve de IBM y usé IBM JDK 8 a Eclipse Photon y Oracle JDK 8. Estoy trabajando en personalizaciones de Java para .

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.