Question

In computer science I have learned that .jar files are basically a compressed set of .java files that have been compiled. So, when you have a project, instead of those 20 .java files you can have a pile of compressed classes (a .jar). Last year in CSI we worked with a .jar file called DanceStudio, which we had to use to make feet walk across the floor. This year, we are working with a different program to better understand java, so i unzipped the .jar file contained 26 classes, which I then decompiled. I wanted to try to create a program by compiling all of the .java files with the others necessary to make the program run (Walker, Foot, ETC.) When I try to compile all of these files, it will say that I have duplicate files (Walker, Foot, ETC.) What I don’t understand is why this would compile if the .jar file was basically the same thing, just in a compressed form. What also confuses me is that the Foot, ETC files in the .jar are actually more complicated and have more code.

Could someone please explain how the .jar file actually works and separates these files apart, and how it could run with a duplicate class that isn’t in the .jar file?

Answer 1

First of all, you’re missing one step in your explanation of a .jar file.

A .jar file is a collection of .class files. And .class files are what is produced by compiling a .java file.

Usually a single .java file will produce a single .class file, because it will contain a single type definition. But there are several ways for a .java file to produce more than one .class files (inner/nested classes, anonymous classes, top-level non-public classes, …), so it’s not necessarily a 1-to-1 association between .java files and .class files.

Then there’s the confusion why the decompiled Java source code looks more complicated than the original Java source. This one is easy to answer: the compilation step was not designed to be reversable.

When the Java compiler turns .java files to .class files it produces a format that is best suited for being executed. That format will not represent the exact same concepts that the Java source file does. For example: there’s no classical “if” in the Java bytecode. It will be implemented be appropriate jump commands.

All of this means that the process of converting .class files back to .java files is complicated and usually non-perfect.