Develop Reference

Usage of jar with .java files and odd behavior of the compiler

I was curious about the differences between .jar with .class files and .jar with .java files. I partially got the answer here, But then what is the usefulness of .java files in the jar?
My guess is that the java files in the jar are like an interface that prevents compilation error, because I solved the IllegalAccessError thrown on runtime by replacing jar files with .class with jar files with .java specifically when using Xposed Framework. (Got the hint from this thread.)
Also
Thank you for your explanations and they were helpful. But I want to learn more about the differences in compiler's view, because I am wondering why my app works fine even if I only included the jar with java files, not class files (zxing). Also there are some cases that throws IllegalAccessException when I include the jar with class files, but not thrown when I include the jar with java files(xposed), even though I have to include at least one of them to make the compiler(AIDE) not complain about references, like unknown package. Why does the compiler not complain when I include only jar with java files though the compiler would not be able to resolve the actual implementation of the referred classes?

A .jar file is basically just a .zip file with another extension.
A .jar file with .class files have a special purpose and may have special meta-data (e.g. in META-INF folder).
A .jar file .java files is just a .zip file.
It is however common for open-source libraries to provide 3 .jar files:
One with .class files, to be used by your code, both to compile and to run your code.
One with .java files, to be used by your IDE, so you can drill into the library code and see it. Especially useful when stepping through the code with a debugger.
One with javadoc files (.html files), to be used by your IDE, so you can read the documentation about the classes and methods in the library. You do read the documentation, right?
None of those 3 files have to be named .jar. They could be renamed .zip so you could easily open them in your favorite Zip utility, or they could be renamed .foo just because...
They should be named .jar, to clarify that they are Java ARchives.

Its simple - *.java files are sources, *.class files are compiled classes.
What is used on runtime by JVM?? *.class files. Why would you put source files inside library? IDK, usally sources are distributed as separate jar, but all in all it is done to allow you to check library code without decompilation.

Where does the actual java code reside if I export my jar without the source file?

I am familiar with the jar structure and it will have a .class files in the classes directory as well as META-INF directory containing the information to main().
But where does the actual java code resides in a jar?
Does it resides a compiled byte code? But don't different machines have different compilers?
I know that I can extract the java code using a decompiler which might be illegal. But I am not interested in doing so. I am more interested in understanding how code is stored?
Is it encrypted? If so, what is the encryption algorithm? what is the location inside the jar ?

Unless you specify otherwise, the source code is not included in the JAR file. The JAR file normally only contain class files (compiled JVM instructions), not source code.

A JAR file is just a ZIP file, renamed to mean Java ARchive.
You can check what's inside, unzipping it. If you're on a OS that doesn't allow you to decompress that archive because doesn't appear to be a compressed file, just change the extension to ZIP.
JAR files are not encrypted.
Java Sources are compiled in a platform-neutral Java bytecode, that's a kind of intermediate binary.
Once JVM load the classes it either interprets the bytecode or just-in-time compiles it to the underlying machine. JARs usually only contain that bytecode
Usually sources are not included in the JARs, especially for distribution. Some projects deliver sources as well in a separate archive. You should check with the provider of the JAR you're dealing with to get sources.
If decompiling is illegal or not depends on the terms of the license applied to JAR. You should check those.
Decompiling a class object is not a very easy task, but a guy used to do a very good job with his JAD.
Unfortunately it's no more maintained, but there are some websites where you can still download it.
Decompiled classes will not look exactly as the real sources, and you could have to make some changes, but you'll definitely get an idea about the source.

Extracting java class files from jar

I had running executable jar of a Java project. Unfortunately I have lost all the source code but I still got the executable jar of it. Is there any possibility to extract my classes from the jar?
I have tried extracting but class files are in damaged shape.

To get source from .class files , just download a decompiler from here and get them.

Are you talking about decompiling or just receiving the class files? The class files can be extracted using any software capable of reading ZIP. If you talk about decompiling that usually will work purly. But you could try Jad which I had the best experience with.

How to convert multiple class files to one jar file?

I have decompiled a jar file,
and made two classes from it. After that, I tried to make a new jar file with these two class files, using this code
jar cvf AB.jar WinRegistry.class StartPageChangeApplet.class
The file created without any errors. However, when I look at the source code on Java Decompiler, it says "Internel Error", means that I couldn't make the jar file properly.
Where am I doing doing wrong ?

Please define "made two classes from it". Which java compiler (e.g. javac.exe) are you using? Did you just copy the source to a .class file without compiling maybe?
The java decompiler JAD actually displays source code, not class bytecode. Don't get confused by the title of the editor which is saying WinRegistry.class.
So you can't just save that as a .class. You need to save it as a .java and then compile it to .class using a java compiler:
javac WinRegistry.java StartPageChangeApplet.java
jar cf AB.jar WinRegistry.class StartPageChangeApplet.class

From Eclipse, you can do this way..

Eclipse: Is there a way to diff a jar and a project?

I have a .jar file that represents a plugin that I am trying to mess with. This is an older version of the plugin, and a newer version was written by somebody else. I have this newer version as a project.
The newer project is full of .java files, and the old plugin is full of .class files. I can import the jar as a project, but it's still all class files. The differences between the class files and the java files are not particularly large, and I would like to see the differences between them. When I do this now, however, the text comparison changes the .class file from its normal representation in the editor to a binary representation. I know that if they were the same type of file, I could select the two and hit "Compare With". How can I do this between a .class and a .java file, or how can I turn one into the other in a way that still allows me to compare the two?
What would really be best is if there were some way for me to edit the jar, by turning the .class files into .java files.

It seems like what you will need is a decompiler to convert the Java .class files (bytecode) back into their original .java source files (text). Then you could compare to the two text files. This seems like it might be useful: http://java.decompiler.free.fr

You can use SOOT (http://www.sable.mcgill.ca/soot/) to do this. Two approaches are possible:
Decompile the .class files into .java files using Dava in SOOT, and then compare the .java files.
Convert both .class and .java files into an intermediate representation called Jimple in SOOT, and compare the Jimple files.
I think the second approach is more reasonable, because:
In the first approach, some Java files are manually developed, while the others are machine generated. Doing a diff on them creates results that are difficult to read.
The Jimple representation is very close to Java source code and relatively easy to read. Reading a diff result on this unified, machine generated format is much easier. Also, if you want, you can convert all Jimple files back to Java source code (well, this is sort of the third approach...).

Because it was a plugin, I was able to import it as a plug-in project, and there was a box to include the source folder. When I checked that I got access to the .java code and was able to diff successfully.