No. You can obfuscate your code, or possibly try to create a native executable rather than a jarfile but both of these are equally useless. If someone wants your code they are going to get it.

The only way you prevent them getting your code is to not distribute it. In otherwords provide a web service or web site so that the consumer never gets your code onto his computer. But even then, reverser engineering can still be performed by determined people.

Yea, like someone in serious need of "homework help".

Jars are just another archive-type file.. The purpose is to hold a number of files under a common name, "myfile.jar", to keep organized and to make it easier for the system to keep related class files all together. That could be reworded, but we know what I mean.

The best option is to create custom jar files and to place only the .class files inside the jar. Of course someone could still decypher the logic in the program by analyzing the compiled bytecode, but why? That's why commercial businesses compiles exe's, and not class files, no?

No, exes too can be easily decompiled and the source analysed (by someone who knows how).

ALL programs can be decompiled by someone who is determined enough.
The only reason some people ship what looks like executables when they ship Java programs is to enable them to be run on systems that have no JVM installed.
If you were to analyse those exes, you'd find that they're typically a JVM with all the classes added to the end as a jar file that's just copied into the exe and deflated at runtime.

Simple fact of life: The vast majority of peope couldn't care less about decompiling your program.
The vast majority of people (usually kids, almost never professionals) who think they need to "secure" their classes write code that's completely uninteresting to anyone who would look at it. There's nothing very clever or groundbreaking there that would give someone a business advantage for example.
The rest won't be stopped by anything.

If you don't want people to ever have the ability do decompile and read your sources, don't ship them.
Deliver your product/service through a web interface for example, or as a SOAP service.

Good thoughts. I've always been a strong supporter of the "open source" concept, even though (as you've made it clear) the source need not be distributed for another programmer to find out how the software was coded (logic, algorithms, etc). Just goes to show - you can't hide something if you give it away. And you're right. Code security does not beat performance and simplicity.

I'm not talking open source here, just common sense.
The best protection for your intellectual property is not letting it out the door.
If that's not possible, make sure your customers know what they're licensed to do and what the penalties are for doing things they shouldn't (like decompilation and illicit redistribution).

Thank you guys ...Finally i have decided to Opt this one to go ahead....

product/service through a web interface or as a SOAP service.

yup, that's a good way to do it. Do take into account the cost of running a stack of SOAP servers though in your price when you sell your service