To the question of "you're not requiring a password now, isn't that a bad (less secure) thing?" I reply:
My first agrument is that of symmetry. For C/C++/Python programs (anything using openssl), a trust store is a plain-text file containing certificates. No password required, and indeed there is not even a way to password-protect it. So this "protection" in java has never been thought worthy of a feature in openssl. Note that since all our certificates need to be in both pem and jks format the passwordless trust stores will continue to exist in pem format regardless of what we do in java programs.
My second argument is that the truststore password is worthless anyway. It could in theory be useful in the limited world of keytool generating a truststore, but when you actually go to use that truststore it all falls apart. The reason is that hadoop clients need the trust store in order to trust the server that they're talking to. Since the client needs it, the client has to be able to fully use the trust store. If the trust store password is given, then the client (anyone who connects to the hadoop cluster, that is) then knows the trust store password. There is no way around this: even if we try to encrypt that password, we would have to give the client the decryption key. Even if we tried to obfuscate that password, we'd have to unobfuscate the password before using it.
The other thing to consider here is that customers frequently re-use the trust store password to be the same as the keystore password. This is dumb, but it happens, and now the password is spread far and wide. The "benefit" is that the integrity of the truststore is cryptographically verified. But since essentially anyone can learn that password, anyone could write to the truststore, so... who cares?
My third argument is that the global trust store on the system has a well known password of "changeit" (even though changing it is pointless) and no software ever accesses the global trust store using this password - because it would provide no benefit.