So, for these two methods:
1) obfuscation
2) convert java to real binary code (for me, we need to run it on MS
Win)

which software tools do you guys recommend most? ---- In terms of 1)
how hard it make the un-complie difficult, 2) less harm of the run time
speed.

It can be free ones, or commercial ones.

Thank you a lot!~

I thought I made it clear in my first post, but since everybody feels
obliged to basically repeat my last sentence from point 2, maybe I
should go into more detail.

First things first: if you are going to run this program on your
client's machine and your client is determined (and sufficiently
technically advanced) to reverse engineer it, there is no way to stop
him. Deal with it. If it is really an issue, then think about
implementing the critical parts of your app as a remote service (be it
RMI, web service or plain HTTP requests). Mind that if you charge your
customers fixed price or subscription price and do not limit the number
of calls they can make per second, they can make a clean-room
implementation of your service, which from business POV is just as bad
as reverse engineering (i.e. they stop paying).

Fortunately, it is very easy to make the reverse engineering if not
imposible, then unreasonably hard. As everybody else said, the
obfuscators are the first line of defence - they make your code much
harder to decompile and as bonus it will usually get smaller and faster
due to the shorter symbolic names and some aggressive optimizations
that the compilers are not allowed to make because of the JLS.

The next line is the encryption/signing. Encryption is good especially
when the code goes through third parties. On the other hand, obviously
you need some code to decrypt what is encrypted. As I said, this code
is the weak point of any scheme which relies on encrypted classloaders.
So what do we gain, you might ask?

What we gain is that now we have to cover only one spot and if we
protect it well enough, we can stop worrying about our bytecode being
visible in the wild. What we can do in this case is to implement the
bulk of this decrypting classloader in native code, using native code
the protection techniques which we all undoubtedly know. I've mentioned
some of them, like comparing the API entry points of well known
platform functions, looking at the timer to check that there are no
unreasonable time-lapses and so on. We can even use a dongle, to make
sure that the user has not tampered with the system timer. (essentially
that was 'point three' from my first mail.)

Having done this, we have increased the dificulty of reverse
engineering our Java code to that of any native code. Still it's
doable. There are hardware protocol analyzers which can replay what
went through the buss and take snapshots of the whole system memory
without stopping the CPU. There are enough smart people who can
dissasemble your carefully crafted native code if nessesary make fake
dongles and they are experts in this kind of stuff, just as some people
are in protecting the software.

The key here is to make the reversing not impossible, but unfeasible.
It's all about the balance between the price of the application, effort
to reverse, audience (nobody reverses software for cow milkers),
popularity and probably many other factors.

It is a good idea to decide on a fixed time that you are willing to
invest into protection (that is research + implementation). Otherwise,
you might spend more time working on the protection than on your
application code.

All that said, IMHO the best tradeoff is a simple obfuscator plus
password based encryption (no native launcher). It's easy to implement
and will keep away a good part of the wannabe hackers. It's not worth
trying to stop the other 10% - they are smarter than me anyway.

cheers,
Dimitar