Note you are actually creating the default format of keystore, assuming this file doesn't exist at the time you run keytool; through Java 8 the default is JKS, but from 9 up it is PKCS12. (Naming the file something.jks does not control the format, any more than naming it something.lollipop would make it a child's sweet.)
If you specify -storepass whatever on the commandline as you stated, it should not prompt for keystore password -- at least not on that operation; if you run keytool again to (re)use the same file, that will prompt unless you again specify it on that commandline. Similarly if you specify -keypass whatever on the commandline, when needed depending on the operation, it should not prompt for key password.
For JKS JCEKS and PKCS12, the password(s) are not stored at all. Doing so would be grossly insecure. Instead, the password(s) plus 'salt' (a randomized value) are processed by a one-way 'key derivation' algorithm to create the key(s) used to encrypt at least the privatekey entries in the keystore, and to authenticate (MAC) the entire keystore. PKCS12 as implemented in Java (weakly) encrypts the certificates as well as the privatekeys; JKS and JCEKS do not. PKCS12 as implemented in Java may not support a private-key password differing from the store password.
If you can't or don't supply the correct password(s) when using the keystore file it may fail depending on exactly what operation(s) you try to do, so it is your job to remember them, and if necessary transfer or distribute them. If you need to do this on a scale difficult to manage manually, there are password-management tools -- which can handle passwords for all things, not just Java keystores -- of many kinds and from lots of sources.
For non-file-based keystores, like PKCS11 on some systems or the OS-provided store on Windows, how the password is implemented and used -- if at all -- depends on the particulars of that keystore, although storing the password would usually be poor or bad practice.
