Develop Reference

How do external java libraries(jars) actually work?

A lot of times in Java we want to use some functionality that is given to us in the form of JARs(ex. some external library). Most often than not I've noticed that JARs contain .class files.
Since .class files represent compiled bytecode ready for use by the JVM, my question is the following:
How is it that .class files are all that's needed for us to make use of an external library? Maybe a certain JAR contains the class file called: Person.class. How am I able to reference this class in my code when all that the JAR file exposes is a .class file. Isn't the source code(.java file) what's important and what's needed? In the same way that I can have two classes in the same package, I'm able to reference one from the other, because the two .java files(not .class files) are in the same scope(just to give an example).
Excuse me if it's a dumb question, but I really want to understand this.

Even if you write your source code in .java files, they are eventually compiled to form .class files which store bytecode that can be interpreted easily. When you use the jar files in your project, all the class files inside those jar files are included in your classpath, hence enabling you to use them.
So in a JAR package, .class files are sufficient to be used as a dependency.

The Java compiler takes your Java code, which is something that humans can understand, into .class files, which is something that the Java Virtual Machine (JVM) can understand. The JVM then takes the .class files and runs them on your machine.
A .jar file is effectively a collection of .class files packaged up (under the hood, it's really little more than a .zip in disguise). When you add a .jar onto your classpath, you are telling the JVM that it is one more place it should look when it needs a particular class.

I am not sure if I totally got your question, but the JARs are simply compiled javacode, which means, that the semantic/logic etc of the code has not been changed. You need to be able to access the functions/classes etc of the java code you want to use, because otherwise you would not gain any advantage of using a JAR.
One advantage of the JARs is, that the source code of these libraries is already compiled. Since these .class files are compiled .java files, they are all you need to access the functions that were written in the .java file.

Compare .java file to .class file

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.

How does Java know the methods of an external jar?

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.

Why javac requires .java extension and java doesn't require .class extension

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. :)

Java and compiling when not using a IDE

I understand in java that you are forced into a single file per class.
So if I have classes like:
/my_project/main.java
/my_project/classes/user.java
/my_project/classes/other.java
And my main.java references the user and other files, how would I compile this via the command line?
If I was to have external .jar's that I was referencing, and I placed them in a particular folder, how could I also include this in my compiling? (or is there a general place I can put them where they will be picked up automatically like how python does this)

to compile, you will need to specify each source file, from the my_project folder:
javac classes/user.java classes/other.java main.java
You can also specify jar files for your classpath with the -cp option:
javac -cp myjarfile.jar main.java
You may also need to fiddle with the -cp flag to make sure your classes folder is in the classpath.

First of all it's poor style to make Java classes starting with lowercase.
Only public classes need to be in their own file, but you can add as many package-private classes as you like to the same file (although this is seen as poor style).
That said, the easiest way would to compile your code would be:
javac /my_project/main.java /my_project/classes/user.java /my_project/classes/other.java
In any case, proper code layout should be that classes are in a directory structure matching their package.
EDIT: There is a fairly good explanation of conventions here http://www.particle.kth.se/~lindsey/JavaCourse/Book/Part1/Java/Chapter05/packagesImport.html

In addition to the above answer, you can use something like Apache Ant, for easier configuration of your build (if it gets complicated).

Look at the documentation for javac. You can pass multiple source files, or specify the source directory.