JDK-8265611 : @compile/ref comparison fails when -Djavatest.security.noSecurityManager=true is set
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2021-04-21
  • Updated: 2021-06-04
  • Resolved: 2021-06-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17
17Resolved
Related Reports
Blocks :  
Relates :  
Relates :  
Description
test/langtools/tools/javac/processing/options/XprintRepeatingAnnotations.java

When -Djavatest.security.noSecurityManager=true is set on the jtreg command line, the test above fails with:

stderr:

     ---- WARNING -----

JavaTest did not install its own Security Manager
because the property javatest.security.noSecurityManager was set.
This is not a fatal error, but it may affect the
execution of sameJVM tests

stdout:
package p;

public class P {

  public static class P1 extends p.P {

    public P1();
  }

  public static class P2 extends p.P {

    public P2();
  }

  public P();
}
/**
 * Printing of modules
 */
@java.lang.Deprecated
module printing {
  requires java.base;
  requires static transitive java.compiler;
  exports p to m.m1, m.m2;
  opens p to m.m1, m.m2;
  uses p.P;
  provides p.P with p.P.P1, p.P.P2;
}

TEST RESULT: Failed. Output does not match reference file: module-info.out, line 1
Comments
No more an issue after JDK-8268267.
04-06-2021

Since there are three tests problemlisted by this bug, it might be simplest to keep this issue open until jtreg is updated.
02-06-2021

The warning is coming from jtreg, not jtharness. It is generated by 'RegressionSecurityManager'.
01-06-2021

Also it looks like this is will go away with the latest jtharness which omits any warnings.
31-05-2021

[~jjg] while I'm not yet sure why this doesn't affect some other `@compile/ref` tests, looking at the jtreg source this seems to be working as intended as jtharness add extra output to stderr and this is included in the compare: CompileAction.java:737 // COMPARE OUTPUT TO GOLDENFILE IF REQUIRED // tag-spec says that "standard error is redirected to standard out // so that /ref can be used." Simulate this by concatenating streams.
31-05-2021

It seems noteworthy that all 3 are positive tests, and all use the javac `-Xprint` option, but they are clearly not the only 3 positive tests using @compile/ref.
21-04-2021

There are 95 tests that use either `@compile/ref` (94) or `@run compile/ref` (1), so it is not clear why these 3 should fail. There are another 1137 files that use compile/fail/ref.
21-04-2021