So my question is: Is this a security bug? It's like having self-signed certs? Several domains struggle with correct HTTPS settings regarding having the "www" prefix or not.
Have a look at the actual error message:
It is a server misconfiguration. But in this case this is not a direct security issue because both domains belong to the same company. (It is an indirect one because it teaches people to ignore this kind of error message).
What happens here is this:
But your browser does not want to talk to www.java.com, it was told to connect to java.com.
If both domains are not under the control of the same people, this is an issue (think of <something>.dyndns.org):
The connection is encrypted just fine, but you had a secured connection to the attacker. The attacker would then read and possible modify it before passing it on to the real server. When the attacker gets the answer, he can again read and modify it, before he sends it to you. This is called a Man in the middle attack.
Therefore this warning is important in the general case.
What to do?
To be on the safe side you should do this: Look at the domain in the error message. If it is likly that the domain is a valid destination for where you wanted to go (e. g. added or missing "www"), type that domain into the address bar. Do not copy it because some special character may look like valid characters, so you could end up elsewhere on a phishing side.
The SSL certificate for that site is for www.java.com, so your browser is correctly telling you that it doesn't match the domain java.com. It's not a security bug, as security is not compromised, but it's a usability issue -- they ought to have a redirect from java.com to www.java.com.
The certificate should either have a "Subject Alternative Name" or be a Wildcard to address this particular issue. Here is a SAN example
Many issuers will configure a certificate this way. In your particular example, Sun Microsystems has a private issuer that is responsible for this this certificate. That server neglected to add the common SAN names in the request.
You say there several domains that struggle with this issue. Take a look at the issuing CA, and if it's private or is common among several problem sites, then the administrative practices are likely to blame.