Validate Java Classes Inside Jar

Question

Java class files inside jars can be easily replaced and modified. For instance, the following command can be used to replace a compiled class file within a jar:

jar uf JarFile.jar com\something\Class.class

If the class file was replaced with a file such that no dependencies were broken, then the code is still able to execute. The same happens with class files that are not inside jars.

Is there any way to validate a set of class files (whether inside a jar or not) to see if all their dependencies are present and not broken?

I do not want to prevent class files from being modified but rather to be able to verify that changes are valid (with respect to dependencies). The compiler does this check (dependency-check) at compile time, but once the classes are compiled, how can one verify the class files themselves?

Answer 1

Just loading the class will ensure that.

Answer 2

You might have sealing and signing JARs in mind.

Update:

Apparently I've missed the mark with my first guess.

What do you plan to do if they're not? If they're a 3rd party, I'd say that you've got little choice besides reporting to the bug database that the download is bad.

If you mean "I want to make sure that all their 3rd party JAR dependencies are correct", you've got a much bigger problem. Most downloads that I know of (e.g. Spring) make dependencies available using Maven. That's the best you can do.

If you mean you want to check your own dependencies, I'd say that testing would reveal any errors you've made.

Answer 3

no, you cannot.

at least: not really. the problem is that java loads classes at runtime only when needed. so eventually it might be alright to remove a class from the jar file and as long as no code referencing that class is executed things run very smoothly.

consider this example:

class A{ public static void main( String args[] ){ out.println( "hello" ); } }
class B{}

compile this, put it in a jar, remove the B.class from it, no problem there :)

now you might think you can go through each .class file, check what classes it references and see if the files are all there. not only is this painful, it is also incomplete. you will never quite catch files loaded with reflection because their class names might be constructed just at runtime.

my advice: don't go there. if someone removes a class file it's their own fault. the best thing you can do is (but only if this really really worries you) try to catch ClassNotFoundExceptions at runtime (look into thread.setUncaughtExceptionHandler)