¿Hay alguna razón específica por la que las interfaces no se compilan en MyInterface.java compiladas en el archivo .interface? ¡Cualquier clase se compila en el archivo .class!Por qué las clases se compilan en .class pero la interfaz no lo hace. Interfaz
Java trata las interfaces casi como clases, por ejemplo, comparten el mismo espacio de nombres (no puede tener una interfaz que tenga el mismo nombre que una clase) y una interfaz compilada es casi idéntica a una clase abstracta compilada.
De modo que no tendría sentido almacenarlos en un formato diferente o con una extensión de archivo diferente. Por el contrario, esto haría que muchas cosas fueran más difíciles. Por ejemplo, cuando carga una clase o interfaz por nombre (Class.forName ("my.class.name")) Java no sabe si se trata de una clase o una interfaz. Si hubiera dos extensiones diferentes, Java habría intentado encontrar un archivo "mi/clase/nombre.clase" y luego "mi/clase/nombre.interfaz", en lugar de solo probar el primero.
Al cargar, el cargador de clases no debe saber si se trata de una clase o una interfaz. Puede cargar varias sobrecargas para cargar los archivos. Concepto de OOP que ves :) – Ravisha
Me parece que esta extraña "interfaz compilada es casi idéntica a una clase abstracta compilada" ? Las clases abstractas pueden tener variables, definiciones de métodos, etc. – fastcodejava
Class.forName() no puede saber si el argumento es una clase o una interfaz, cuando se le da solo el nombre como cadena. De lo contrario, necesitaría otro método para las interfaces (o un parámetro para decirle al cargador de clases qué cargar, o una clase especial para las interfaces). Por supuesto, Java podría haber sido diseñado para manejar interfaces completamente diferentes a las clases. Pero, ¿por qué complicarlo si hay una solución más fácil? –
En java, tiene archivos fuente, llamados .java y binarios llamados .class. Es solo una elección de nombrar.
También para las clases de Java y las interfaces no difieren demasiado (una clase solo contiene mucha información adicional como cuerpos de métodos).
Lo que quiero decir es que, si bien vamos a través de la reflexión basada en la extensión de archivos, será claramente distinguible. Solo un aspecto del mismo. de todos modos mi pregunta aún permanece, ¿las personas que desarrollaron java (previoulsy OAK) no quisieron distinguir en función del sistema de archivos? – Ravisha
La representación física del código de bytes en el sistema de archivos no es importante.
Es la realización lógica (ya sea de clase o interfaz) que importa.
La respuesta correcta, creo, por lo que recuerdo de la especificación del lenguaje Java, cómo la salida del compilador está almacenada en el sistema de archivos no es realmente parte de la definición del lenguaje.Es solo una convención común. Pero los archivos de clase podrían escribirse directamente en alguna base de datos funky. –
Así decidieron los diseñadores de idiomas.
Tiene sentido de varias maneras:
.class archivos son un subproducto que normalmente no ve o manipular a mano.Francamente, no puedo pensar en una buena razón para tener diferentes extensiones para las clases compiladas y las interfaces. ¿Por qué sería importante distinguir entre ellos?
@ Eli, es la única duda que tengo porque el primer momento que veo un archivo .class supongo que es una clase (Sólo mi opinión errónea puede ser) – Ravisha
Es solo una elección que hicieron. No me molestaría sobre eso. Es un archivo binario de todos modos. Una forma de pensar es "Incluso es una interfaz, todavía está en un archivo .java".
Porque el punto es indicar que el archivo es código de bytes Java (y .class fue la extensión elegida para eso), no la construcción del lenguaje específico.
Por la misma razón que un objeto 'java.lang.Class' puede representar una clase, una interfaz, un tipo de anotación o un tipo enum. –
Y el nombre del archivo siempre es ".java" independientemente del tipo de la clase. – fastcodejava