It has been decided to not allow insecure system properties to be specified via deployment.properties at all, due to what would be necessary inconsistencies between platforms, in particular Windows Vista and everything else. This has been addressed in a different fashion under 6643379. Closing this as a duplicate of that one for tracking purposes.
A user on the java.net forums indicated that debugging of applets
doesn't work with the new Java Plug-In. Normally users specify -Xdebug
-Xrunjdwp:... via the Java Control Panel to enable debugging of
applets. It is likely that in the build they were testing they were
receiving ClassNotFoundExceptions due to the specification of the
insecure -Xrunjdwp command-line argument. In build 10 the fix for
6643379 inadvertently further broke this functionality, since the
insecure -Xrunjdwp command-line argument would be filtered out.
To solve this problem, the JVMParameters class was refactored to
contain two sets of arguments: trusted and untrusted. Trusted
arguments come from deployment.properties and are specified via the
Java Control Panel. Even insecure JVM arguments may be specified here
without affecting the "secure" status of the target JVM. Any arguments
specified via the java_arguments HTML parameter go into the untrusted
set and have the same semantics as before. Introduced a separator
argument ("--") used to indicate to the JP2Launcher on Windows Vista
the boundary between the trusted and untrusted arguments.
Additionally, a check for the -Xdebug flag was added and the
browser-side heartbeat thread (which is only a last safety measure to
avoid browser hangs) disabled if it is present, to avoid having the
target JVM abruptly torn down if the debugger is stopped at a
breakpoint for a long period of time.
Tested with a new regression test as well as the regression tests for
6625351, 6640436, 6643379, and the unit test for the JVMParameters
class, both with and without the use of the JP2Launcher normally used
only on Windows Vista.