Why class named saved directly with .class extension without compiling is not get executed by JVM. Is there any kind of Metadata or something else is attached to .class file so then only JVM recognised as valid .class file ?
Please Help me to clarify
Thanks in advance
A Java class file is a compiled intermediate form called bytecode. Bytecode is interpreted by the JVM and executed. It is not human readable text.
If you need that capability, I suggest you look into Groovy and Scala (both are JVM hosted languages, and both can run as scripting languages).
If you have a text file it isn't a .class (and no the class-loader will only load valid class files). Try looking at the bytecode of an existing class; you can decompile it with javap -v so u can see the differences between two files.....
.class filrs have a specific format. There's no reason why the jvm should execute anything other than this format just because it's also called .class.
Related
Similar to C or C++ where you can get the intermediate files are there any commands to get same for Java Code?
For example,
C file can generate,
Preprocessed File (Hello.i)
Compilation file (Hello.s)
Assembly File (Hello.o)
Executable File through Linker (Hello.exe)
In java we do,
Executing --> Filename.java
we obtain --> Filename.class
and then we run this class file for output.
Is there a way to generate Preprocessed, compiled and assembly files for Java code?
No. The Java compiler generates bytecode (contained in .class), there are no intermediary steps.
The JIT compiler(s) then generate assembly and machine code, and those can be seen with suitable flags given while running the program.
The .class file is already an 'intermediate' file. The Java Virtual Machine then takes this and executes it (interpreting or compiling as it sees fit, often both!)
If the class file is not obfuscated, you can easily disassemble the contents with a decompiler, as all/most symbols are preserved ( like debug symbols in C/C++). Some IDEs allow you to open a .class file and see the disassembled code (IntelliJ and NetBeans come to mind)
IntelliJ shows the decompiled code as if you're looking at a regular .java file, although with no comments and sometimes 1-letter variables. You can view the bytecode (disassembly) using a menu option (even of your own source code as long as it's compiled).
NetBeans shows it, afaik, only as byte code, but still grouped by method.
In my situation I have many .jar files being created from a build process. Before I do any debugging I want a way to quickly verify that my .java source matches the .class found in a .jar.
I figure that if I unzip the .jar and find the .class which matches my .java file then I should be able to determine if they're functionally the same.
How can I do this?
The first thing to realize is that compilation doesn't just use the specific .java file for the class being compiled. The compiler also uses information from the other .java and .class files available at compile time. For example, it may inline static final constants. Also, stuff like method overloading depends on which methods have been defined.
That being said, if you compile the same source file with the same compiler as before, you'll probably get the same, or a very similar class file. However, even with identical source files, different compilers (javac vs eclipse) and different versions of the compiler will produce different results.
Therefore, what I'd recommend is first try compiling everything and see if the classfiles match. If the class files don't match, try disassembling them with the Krakatau disassembler and do a diff on the diassemblies to see what the differences are. That will help you see if the difference is unimportant (such as a reordering of the constant pool) or if there are substantive changes to the bytecode.
You can use a java decompiler like http://jd.benow.ca/ in order to be able to view the corresponding source of your class file then you will be able to compare it with your java file
Maybe it would be enough for you if you can use a decompiler? Like one from IntelliJ IDE to see how is the source for you compiled class. You can even debug over the decompiled source.
What I don't get is how does Java know the methods of a jar that is referenced? If it is compiled just for running and you can't read it I don't see how you can see the methods still. An example of my question is like if you made a jar that makes a box show up on the screen using a method called
"ShowABox". And you add it to another Java project. Then how does the IDE know that a method called
"ShowABox" exists since the jar was already compiled? You can't read class files in an IDE so why can it read methods?
All the information you are referring to is actually stored in the class files precisely for this reason.
As to seeing the code in class files, you can certainly do so, and it will also prove that the information was kept. Have a look at Java Decompiler. Note you can even build this into eclipse if you want to see it directly there.
Compiled classes contain bytecode. Methods still has their real names, but their code compiled to JVM instructions.
You can read java class file format specification on wiki, read "The constant pool" paragraph, methods names (as other class information) contains in constant pool.
Just try to open some .class file in text editor, you will find methods names there. (.class files are often in project/bin folder, or open .jar as archive and get .class file from there)
A JAR is nothing more than all the class files zipped in a single file with a manifest attached. Each class file completely describes its public interface.
JAR-files have a very specific format — see http://en.wikipedia.org/wiki/JAR_(file_format) — and they contain class-files, which also have a very specific format — see http://en.wikipedia.org/wiki/Java_class_file. This format, in addition to providing the Java Virtual Machine with the information it needs to execute code, also provides IDEs and compilers with the information they need to find classes, interfaces, fields, methods, and so on.
A jar is nothing but an archive containing Java compiled .class binaries compressed for compactness into a single file. Its contents are compiled binaries organized in a directory structure. So you can think of it as a directory with files but compressed into a single archive (just like a zip file). A jar itself is not a binary ("exists since the jar was already compiled") -- it doesn't get compiled itself but it rather contains compiled elements.
Is this possible to convert a .class file (from .jar external library) to a .java file? I'm trying to figure out whether it is possible or not because the source of the external library is unavailable.
What are the steps I need to take to do this?
use a java decompiler like "Cavaj". It will open the class into a txt format, copy the code to a file and save as .java
Use jad. Download it from here. It works fine with classes compiled up to SDK 1.4... 1.5, if I recall correctly.
The javap command takes class-names without the .class extension. Try
javap -c ClassName
javap will however not give you the implementations of the methods in java-syntax. It will at most give it to you in JVM bytecode format.
To actually decompile (i.e., do the reverse of javac) you will have to use proper decompiler.
http://download.cnet.com/Cavaj-Java-Decompiler/3000-2213_4-10071619.html
or may be this be of some help Java Decomilers
it is Possible to convert a class file to java file without using any tools . e.g Decompiler or something else ?
Why javac looks for .java extensions in filenames.
While java doesn't look for .class in its argument? And goes to the .class file by itself automatically?
Is there any reason for this?
There's no automatic adding of .class: you just run java specifying which class to use as main. The details of classloading and classpath are on a different level of abstraction: it is possible that there's no .class file, or e.g. it's in a JAR.
If you look closer, by the way, you'll find that java does not ask you for a path: there are no slashes (or, worse yet, backslashes) in the parameters, only the proper dots separating package names. So it's never a "file."
javac, on the other hand, does indeed work with files, hence you need to specify those.
I don't think there is a very sound reasoning behind this decision except for the fact that .java files are created by the programmer whereas .class files are compiler generated. If this question is meant to be purely for educational purposes, the answer "just because that's how it was meant to be" should be pretty good. :)