The blockers of this bug should be: 1. packages calling java/javac/jar etc. without inheriting the java-pkg-2 eclass. Without the eclass, we cannot control e.g. which JDK is used for the building and set its environment (including sandbox addpredicts) properly, and the results of such build might e.g. be unusable for reverse dependencies. 2. packages using java-pkg-opt-2 eclass, which control use of java through a USE flag. With the flag disabled and java/javac/jar still called, this is similar to the first case. The probably most common problem for packages in the second group (and also sometimes in the first group) is that configure scripts check for usability of java/javac/jar commands, even with something like --disable-java is passed. This might not be a big problem, until a JDK 7 is set as system VM, which results in sandbox violations under /proc. With proper use of java eclasses this is not a problem, as the eclass handles addpredict itself. We did not add a global /etc/sandbox.d file for the purpose of discovering these kinds of bugs.
Because of certain dev doesn't want to acknowledge that calling java stuff without java eclasses is an issue, permanent sandbox.d exceptions are added to the jdk7 ebuilds. We won't catch the java misuse so easily now, and e.g. configure checks trying java stuff are not considered an issue in themselves. Still, building *and installing* java stuff without the eclasses is wrong and should be tracked here.
No more blockers. Closing this tracker.
