Pass -Djava.security.manager=allow in kt_rules_test

[Bencodes]

#1129

[restingbull]

I tried this:

Error occurred during initialization of VM
--
  | java.lang.Error: Could not create SecurityManager
  | at java.lang.System.initPhase3([email protected]/System.java:2065)
  | Caused by: java.lang.ClassNotFoundException: allow
  | at jdk.internal.loader.BuiltinClassLoader.loadClass([email protected]/BuiltinClassLoader.java:581)
  | at jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass([email protected]/ClassLoaders.java:178)
  | at java.lang.ClassLoader.loadClass([email protected]/ClassLoader.java:522)
  | at java.lang.Class.forName0([email protected]/Native Method)
  | at java.lang.Class.forName([email protected]/Class.java:398)
  | at java.lang.System.initPhase3([email protected]/System.java:2050)

There is some more subtlety here, haven't had a chance to dig in.

[Bencodes]

@restingbull we can also pass this at the bazelrc level which I believe solves the issue, at least locally.

[restingbull]

@restingbull we can also pass this at the bazelrc level which I believe solves the issue, at least locally.

Not as far as I can tell? The flag doesn't seem to do what we want it to in the later jvm versions -- that message is from the buildkite pass on this pr. The problem is that allow is not valid pre-18, according to the associated jep. Instead, it's considered to be an alternative security manager... I'm not clear on how we can sniff the java verio

e.g. this fails on 11, but passes on 18+. Until such time as it doesn't exist. This is why I moved us to junit5, and am in consideration how to fix the prod issue. The deprecation is gonna get us, one way of another.

Nevermind, figured it out. Have a patch momentarily.

[Bencodes]

👍