Question: I would like to give an executable jar file to my client and I have a code in it to expire after a certain time. But if the client uses some decompiler and reads the class file, he can modify and make the code to work Is there any way I can stop this from happening.

Can I use deleteOnExit() or some other technique ???

Answer: 
In the past, I've used [Zelix KlassMaster](http://www.zelix.com/) to perform obfuscation. It does a very good job, however, you have to spend time to configure it such that it works properly for your needs. If you use reflection, then you have to ensure that it doesn't obfuscate those class/method/property names, etc. One of its strong suits is that it will obfuscate strings as well.

All that being said, the end result is that your client will still have your code, alebit in a very difficult-to-understand format. However, if he truly has the time and effort, he can reverse engineer it.

A lot also depends on exactly what it is that you are trying to protect. If you are trying to protect the actual IP then obfuscation will help you out. If you are trying to protect licensing, then obfuscation just makes it a little more challenging for someone to figure out where your licencing module(s) are and how to circumvent them. In the latter case, I would then suggest that you use something like [AspectJ](http://www.eclipse.org/aspectj/) to weave in licensing checks in several different classes just to make it more difficult to break. However that too is not fail-proof.

As others have already said, the only fool-proof system is to not give the client the code in the first place and change to a SAAS (Service as a software) solution.
What about using a modified classloader that is able to load your classes from an encrypted storage. As you do not directly expose the jar and the classes inside it might help but as all others said above - it won't be bulletproof.