In order to convert a string representing a password (that is, a short string that a human can memorize) into a key for RC4 or other cipher, it is important for security to use a Key Derivation Function intended for key stretching, parameterized so that it is appropriately slow. It is also useful that salt is included as input to this KDF (For file or session encryption, a 16-byte random salt sent in clear at each use is fine. If that extra data is an issue, salt could e.g. be built from concatenation of the ID of the password owner, server name, and a constant server-unique value. Adding something random and secret in the salt can help; some call it pepper).
The reason NOT to use a truncated hash of the password, or any other fast and un-keyed method, is that it would makes the cryptosystem very vulnerable to brute-force password cracking, even using a standard PC. Password cracking and other brute-force key recovery seems to be a real industry, using countless kilowatts of power for CPUs and GPUs, and possibly a key (pun intended) market for such FPGA racks.
A recommendable but unfortunately not-so-standard KDF is scrypt; bcrypt would be my second choice; and PBKDF2 what I probably would end up using if in a hurry to rush the thing into production on a Java platform, assuming that SecretKeyFactory.getInstance("PBKDF2WithHmacSHA256")
is available. Beware NOT to use without careful review some code returned by querying for this, especially if it uses an iteration count of 1000 (which sadly is common, the only value mentioned in the definition of PBKDF2, and utterly insufficient nowadays facing a competent attacker). Also, adapt the key size parameter for whatever the cipher allows (that should be 256 bytes for RC4).
As rightly pointed in comment, the character set of the input is an issue that should be dealt with carefully.