The name of the control panel is different depending on whether you are using the Oracle JDK or OpenJDK.

Search for "control panel" in the dash. If you're using the Oracle JDK, you'll see the Oracle Java 7 Plugin Control Panel. If you're using OpenJDK, you'll see the Iced Tea Web Control Panel.

In version 7 and 8, I used to have to edit a java.security file located “/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/java.security” on Debian systems to add the ability to create random data “securerandom.source=file:/dev/./urandom”. However, this path no longer exists in version 9.

Has it been relocated, or is this functionality no longer needed?

The reason for urandom was because a virtual machine doesn’t produce enough random data from what I read and so some applications would just stop responding. Adding this in would prevent this issue.

Yes the comment character is # on all systems. The webpage you link is about security policy files, for the SecurityManager (originally designed for applets and now little-used); java.security is not a security policy file.

Yes do all 3 lines. The continuation syntax (backslash-eol) only works on uncommented lines, so to comment an item continued over multiple (physical) lines, comment each line.

However, since you now make clear the error is on the protocols, it would be safer to only delete the offending protcol(s) (almost certainly TLSv1(.0) and/or TLSv1.1 -- SSLv3 has been disabled since 8u31 in 2015 after it was catastrophically broken by POODLE) and leave the rest.

Are you by chance trying to use an old version of javamail? There was a (mis)feature for a while which defaulted secure mode to TLSv1(.0) (only) and triggered this symptom when 8u291 and several other versions came out; we have several existing Qs about it, just search "javamail no appropriate protocol". While removing or reducing the disabledAlgorithms setting (or regressing below 8u291) will allow the client to attempt a TLS1.0 connection, many servers today will not accept it because TLS1.0 is considered broken; that's why Java is now changed to disable it by default. In this case it would be better to upgrade javamail or to explicitly configure mail.{smtp,imap,pop3}.ssl.protocols to a value suitable today probably TLSv1.2,TLSv1.3.

(Other) Alternatives: in general instead of changing things in JRE/lib/security/java.security which affects all JVMs, you can set system property java.security.properties to point to a different (modified) file separately for each/any JVM e.g. with -D on commandline, or you can call Security.setProperty() in your code sufficiently near the beginning.

1. Please don't set the security level to Medium! This is a battle I've been fighting; there's no need to do this. Just specify the URL (See "Workaround").
2. This is a good thing. It's requiring legitimately signed certs and a permissions manifest attribute (See "Cause") (Details).
3. If you aren't aware, there are ways to push out this config uniformly by doing this (Or more succinctly, this).