Thank you for your reply.

Those are reasonable questions. So let me explain what I am trying to
do.

I have made a multiplayer game that is being deployed using Java Web
Start. Like many games we run into occasional problems with cheaters
who use speed-cheats, fake packets or in extreme cases even decompress
and decompile the jars included in the game to achieve unfair
advantages through some small changes. I can deal with the first two
in several ways and have already done so.

But I'm still looking into ways to make simple decompression +
decompilation less useful for cheating. I already obfuscate my JAR and
that is certainly helpful! However, I'm trying to develop a way for
the game server to verify whether a client is using a different
version of the game code or resource JARS. I know this can never be
foolproof. I know this will never stop a determined and skilled
cheater. Yet, the majority of those attempting to cheat are neither
particularly skilled, nor determined. So I'm just looking for ways to
put up some minor obstacles.

One of those things I was thinking of was too simply check the date
and size of the JAR. If they do not match, I can assume there has been
some tampering going on. Again, I know this will not be foolproof.
They can alter the decompiled code to fool there server, but this will
still serve as a decent obstacle, especially since the code is
obfuscated. So thats why I was wondering about accessing the JARS on
the classpath.

But by all means, if anyone has any suggestions on how to detect
whether a JAR has been tampered with I'd gladly hear it. Again, I'm
not looking for completely security, I just want to put up some minor
barriers. So to answer your question: "What does this information
offer the end user?". I hope it will offer them a more enjoyable game!

Thanks :)

..at least until you deliver them by web start to a client
that has the JCP configured to store cached resources
with 'no compression'.  ;-)