Hi, This is a fix for a subtle test bug caused by a logger being GCed.
bug id: https://bugs.openjdk.java.net/browse/JDK-8156153 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8156153/webrev/ This test has been seen failing in hs integration with the following error: ---------------------------------------- ... *** With Security Manager, without permissions ... ----------System.err:(24/1937)---------- java.lang.RuntimeException: identical backend loggers at DefaultLoggerBridgeTest.test(DefaultLoggerBridgeTest.java:404) ... ---------------------------------------- The main runs the same test sequentially in 3 different configurations: - without security manager, - with security manager and no permissions granted, - with security manager and permissions granted. The test attempts to first create a lazy logger for a system class, then a logger for an application class. It expects that the second concrete logger will be created first - because it should not be wrapped in a lazy logger. However, since the loggers are not referenced outside of the test method, then it can happen that the application logger gets garbage collected between one scenario and the next, which will invert the creation sequence (or more exactly pseudo-creation sequence in this case) in the next scenario. To fix this I propose to run each scenario in its own VM - by using three different @run main lines. This way each scenario will start with a clean slate. best regards, -- daniel
