Java overwrites the default keystores on every update (well, most of the times it installs on a new location and erases the previous one), so every time you update your packages it would delete any private key a user had created (as the update could also contain changes in the default truststores to drop untrusted CA, etc), so the default (and most sane way) is to store things on the user's folder. That way it issolates from the updates. Also, it would be a security issue if every user on the same machine could access any other user's private keys or manipulates the default truststore to allow custom CA.
Windows certs behave in a similar way: the default is to show the personal storage for the current user. New private keys or trusted certs would only affect the current user, but the machine will still have the defaults Windows was shipped with (and every update will change those defaults like new CA or untrusted ones).
What a user does, should not affect any other users on the same machine.
As for the JRE and JDK, the first is for the
running environment (that is, for the standar usage of applications), whereas the later is for
development and has different needs. An application server will need the JDK as it needs to "compile" pages like
*.jsp and such on the fly. The JDK includes it's own JRE, so it has it's own copy of everything that JRE needs for it to work. As you might need to provide support for clients (users) differently than for the server (i.e. the JRE and the JDK could be using different versions), sharing common pieces could interfere.
You can change the keystore (name and location) with
-keystore file.jks in the same command you typed, but you will need to refer to the same file in any other command or configuration in order for java to use that same keystore. As you have named the alias
tomcat, I assume you will use it as a keystore for an application server, so in the server.xml (or catalina.xml) file you will need to configure the keystore location.
Keystores for a server should be in a directory with a restricted access (only readable by the user the server is running with) such as
/etc/ssl/ and the like.
As for the contents of the file itself, as you need it signed, the first is to create a self-signed keypair (as you did) and then create a CSR (certificate signing request) to send to the CA. After that, you should import the whole chain (the newly signed cert and the chain of certs of your CA) into the same alias in the same keystore. That would still be a single entry in the keystore, but it will have several certs (and a private key) under that alias.
If your server does not need to connect to another server, that keystore should not contain any other cert. And even if it needs to, you should have a separate truststore (a second keystore, but only with CA's in them, just like the cacerts file) instead (or rely on the default truststore of the JRE, or even include the CA in the same keystore).