Is there any specific reason why interfaces are not compiled into MyInterface.java compiled into .interface file?But any class is compiled into .class file.!
+2
A:
In java, you have source files, called .java and binaries called .class. Its just a choice of naming.
Also for java classes and interface's don't differ that much (a class just contains a lot of extra information like method bodies).
Thirler
2010-02-10 11:58:20
Why i am saying is that while we go via reflection based on file extension it will be clearly distinguishable.Only one aspect of it.anyway my question still remains ,did the people who developed java(previoulsy OAK) didn want to distinguish based on file system?
Ravisha
2010-02-10 12:04:14
+3
A:
The physical representation of the byte-code on the file system doesn't matter.
It's the logical realization (whether class or interface) that matters.
Bozho
2010-02-10 11:59:48
The right answer, I think - from what I remember of the Java language spec, how the compiler output is stored on the file system is not actually part of the language definition. It's just a common convention. But class files could be written directly into some funky database instead.
Daniel Earwicker
2010-02-10 12:20:15
+2
A:
Java treats interfaces almost like classes, eg they share the same namespace (you can't have an interface that has the same name as a class) and a compiled interface is almost identical to a compiled abstract class.
So it would not make any sense to store them in a different format or with a different file extension. On the contrary, this would make many things harder. For example, when you load a class or interface by name (Class.forName("my.class.name")) Java does not know whether it is a class or an interface. If there would be two different extensions, Java would have try to find a file "my/class/name.class" and then "my/class/name.interface", instead of only trying the first one.
Tim Jansen
2010-02-10 12:00:43
While loading shouldn the class loader know whether its a class or an iterface.It can have tow differernt overloads to load the files.OOP concept you see:)
Ravisha
2010-02-10 12:06:42
I find this strange "compiled interface is almost identical to a compiled abstract class"? Abstract classes can have variables, method definitions, etc.
fastcodejava
2010-02-10 12:44:48
Class.forName() can't know whether the argument is a class or an interface, when given only the name as string. Otherwise you would need another method for interfaces (or a parameter to tell the classloader what to load, or a special class for interfaces).Of course, Java could have been designed to handle interfaces completely different than classes. But why make it complicated if there is an easier solution?
Tim Jansen
2010-02-10 12:46:57
+3
A:
That's the way the language designers decided.
It makes sense in several ways:
.classfiles are a byproduct that you don't normally see or manipulate by hand.- The less different extensions a program uses, the easier it is to maintain.
- In many cases, there's no distinction in the code between a class and an interface, so it's logical that the binary files look alike.
Frankly, I can't think of a good reason to have different extensions for compiled classes and interfaces. Why would it be important to distinguish between them?
Eli Acherkan
2010-02-10 12:06:10
@ Eli ,its just the doubt i got becuase the very first moment i see a .class file i assume it to be a class (Just my wrong opinion may Be)
Ravisha
2010-02-10 12:08:24
+1
A:
It is just a choice they made. I wouldn't bother about it. It is a binary file anyway. One way to think is "Even it is an interface it is still in a file.java".
fastcodejava
2010-02-10 12:16:30
+8
A:
Because the point is to indicate that the file is Java byte code (and .class was the extension chosen for that), not the specific language construction.
Bruno Rothgiesser
2010-02-10 12:51:02