oah yeah and I know about obuscaters, but that doesn't almost nothing to protect your code, just makes it really decently hard to copy

Wouldn't you encrypt the password? How exactly does this program run? Is it an applet or a JFrame that the user has?

For the update you could have a servlet that reads the password from the xml DD. I think it's the servlet context you would have to set onn that though.

what are you trying to achieve?
Is the password entered by the users and the program checks it (with the users getting a new password mailed every week)?
If so the solution is simple: save the password in the form of an MD5 hash and compare the MD5 hash of the password the user enters with the hashed password you stored.
That way the application never knows the password at all (as it will get the hash from the generator, also removing the risk of a man in the middle attack fetching the unencrypted password during transmission).

No language is completely safe from decompilation, and network attacks can catch your passwords being transmitted also independently from the language used.

You can add further safeguards in your Java environment like custom classloaders that use an encrypted table of hash codes (or more likely serial version IDs) of your classes and compare those with the ones calculated from the actual classfiles to check whether there has been tampering, classfile encryption, etc. etc. but of course nothing is ever completely safe from the dedicated cracker.

What you always (in any environment) need to ask yourself is how much effort/money is the worth of your data security and how to best spend it.
Often the conclusion will be that there's no real need to go further than a stern license and removing debugging information from the compiled code.
In a high security environment you'll often find that the best way to work is to not have the end user have access to your software (or at least the secure bits) at all.
You'll be acting like an application service provider, with your customer through some interface contacting the software which is running on your own machines at a secure location you control and getting back only the results.
That way the application (and your firewalls) can prevent anyone from calling the application who is not at a known customer site. Add password security and only people at that site with the required credentials can call the application.
And only people at your site have access to the compiled binaries, so noone can decompile anything who you don't have explicit knowledge of.

yes i would encrypt the password, but if you can view my source code, then you can view how it was encrypted, and thus decrypt it, I thought about having 2 passwords, one is the software to make sure it has been updated, the other is the users, but if a program can be decompiled and recompiled then how would i stop some malicious user from creating some methods to save the user passwords before they are sent to the server?

If you use a one-way encryption algorithm like MD5 there's precious little chance of it being decrypted (as the algorithm doesn't support it).

I know someone in China is doing work towards decrypting MD5 but it's so far not a threat (at most their method will give you an idea where to look for the password, some hints towards its composition).

As far as encryption is considerd it is onlly solution and as said MD% is one way encryption algorithm and even if someone decompiles it it cannot decrypt it !!

And If you r so concerd about security during network their is combination of public private key encryption used during networks and a software cannot be secure more than that even dedicated cracker will be able to crack windows security which is having both software and hardware support you just have software security though :p