http://blog.gmane.org/gmane.comp.java.openjdk.jtreg.user hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/92 <pre>Hi Jon, I have a new test that requires that a security manager be installed, so I have: &lt; at &gt;run main/othervm -Djava.security.manager but this causes jtreg itself to encounter a security exception: Exception in thread "main" java.security.AccessControlException: access denied ("java.io.FilePermission" "/scratch/dh198349/dev-work/b11/linux-i586-dh/testoutput/jdk_util/JTwork/classes/java/util/concurrent/atomic/AtomicUpdaters.jta" "read") at java.security.AccessControlContext.checkPermission(AccessControlContext.java:364) at java.security.AccessController.checkPermission(AccessController.java:555) at java.lang.SecurityManager.checkPermission(SecurityManager.java:549) at java.lang.SecurityManager.checkRead(SecurityManager.java:888) at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:121) at java.io.FileInputStream.&lt;init&gt;(FileInputStream.java:87) at java.io.FileReader.&lt;init&gt;(FileReader.java:58) at com.sun.javatest.regtest.MainWrapper.main(MainWrapper.java:45) What can I do to fix this? Thanks, David </pre> David Holmes 2012-04-19T04:40:45 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/87 <pre>I recently discovered that using relative paths for the -jdk option fails for some of the shell script tests because they expect the jdk path to be an absolute path. (yet one more reason to hate shell tests). About 100 tests fail in jdk/test/test because of the absolute path requirement to their driver shell scripts. Is there any chance that jtreg could convert the path provided to -jdk to an absolute path? being able to use a relative path on the command line is certainly more convenient. Thanks, Mike </pre> Mike Duigou 2011-11-16T22:45:05 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/79 <pre>Hi, The UIManager.getSystemLookAndFeelClassName() runnning in the test method by jtreg returns different L&amp;Fs than it is run under JDK on the Solaris when the GNOME_DESKTOP_SESSION_ID is set. It is because the jtreg does not pass the GNOME_DESKTOP_SESSION_ID system variable to the tested JDK and so the JDK does not set the sun.desktop system variable. To check this set the GNOME_DESKTOP_SESSION_ID system variable on the Solaris and run the following code under java 1.7 and jtreg: --- TestSunDesktopSystemVariable.java --- /* * &lt; at &gt;test * &lt; at &gt;summary Check that sun.desktop variable is set in JDK if the GNOME_DESKTOP_SESSION_ID system variable is set on Solaris OS * &lt; at &gt;run main TestSunDesktopSystemVariable */ public class TestSunDesktopSystemVariable { public static void main(String[] args) { String sunDesktop = System.getProperty("sun.desktop"); System.out.println("desktop = " + sunDesktop); if(sunDesktop == null){ throw new RuntimeException("The sun.desktop system variable is not set"); } } } --------------------------------------------------- The result is &gt; java desktop = gnome &gt; jtreg ----------System.out:(1/15)---------- desktop = null ----------System.err:(13/814)---------- java.lang.RuntimeException: The sun.desktop system variable is not set To fix this the GNOME_DESKTOP_SESSION_ID system variable should be added to the DEFAULT_UNIX_ENV_VARS string array in the com.sun.javatest.regtest.Main class. Thanks, Alexandr. </pre> Alexander Scherbatiy 2011-10-21T09:49:37 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/77 <pre>I'm working on a bug that involves a lot of reflection and proxies and trying to debug it using the jtreg unit test and attaching to the process with netbeans debugger. I initially ran into problems when jtreg timed out the test after 120 seconds. I then tried increasing the timeout value but my requests for "10000000" were rejected. I'm currently using a timeout factor of 100 but it would be nice to be able to say "-timeout:never". Is there a way to disable timeouts entirely? Mike </pre> Mike Duigou 2011-07-29T21:05:16 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/76 <pre> According to http://openjdk.java.net/jtreg/faq.html#question4.1, by design, PATH is not propagated into the test's JVM; instead, * Linux and Solaris: o PATH is set to /bin:/usr/bin * Windows: o PATH is set to the MKS or Cygwin toolkit binary directory What is the rationale behind of restricting the shell tests to use commands from /bin:/usr/bin? We have tests that depend on gawk which is not installed in /bin:/usr/bin on Solaris 10 by default (instead /opt/sfw/bin) unless I add a symlink or copy them. These tests fail if I use jtreg to run them. Thanks Mandy </pre> Mandy Chung 2011-03-04T23:34:12 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/75 <pre>The copy of the jtreg tag specification posted at &lt;http://openjdk.java.net/jtreg/tag-spec.txt&gt; is an older version (1.25 06/10/24) than the version included in the online help (1.26 09/10/10) for jtreg 4.1 fcs b02. Also, a less ambiguous date format such as 2011-02-13 would be nice. :-) Cheers, Mike </pre> Mike Duigou 2011-02-13T18:28:55 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/73 <pre>I'm trying to understand what differences in usage there are for the -vmoption and -javaoption flags. From my reading of RegressionParameters.getTestVMJavaOptions() it would seem than in practice the two options are interchangeable. Is there some other distinction I am missing? The command line help includes a see also for each to the other but doesn't explain any difference. Mike </pre> Mike Duigou 2011-01-24T21:01:03 http://comments.gmane.org/gmane.comp.java.openjdk.jtreg.user/71 <pre>Hi all, I realized that OpenJDK regression test langtools/tools/javac/processing/6499119/ClassProcessor.java uses the tag "&lt; at &gt;compile" followed by tag option "process". But this tag+option pair is not mentioned (or I'm unable to find it ;-) in tag specification: http://openjdk.java.net/jtreg/tag-spec.txt I also tried to find in newest JTreg harness sources where this option is processed and it in fact exists (CompileAction.java). So I think that tag specification on openjdk.java.net should be updated. If I'm right can anybody please do it? Thank you in advance, Pavel Tisnovsky </pre> Pavel Tisnovsky 2010-11-18T11:26:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.openjdk.jtreg.user