> On Jun 5, 2017, at 10:50 PM, Alan Bateman wrote:
>
> On 06/06/2017 06:10, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8181335/webrev.00/index.html
>>
> I added this so-called "packageless" CompilerUtils some time ago. I see the
> version copied into the top-level repo is an
On 06/06/2017 06:10, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev/8181335/webrev.00/index.html
I added this so-called "packageless" CompilerUtils some time ago. I see
the version copied into the top-level repo is an older version and
doesn't specify UOE or handle the JRE case. Ca
Amy,
thanks for the comments.
On 2017/6/6 10:37, Amy Lu wrote:
sun/net/www/protocol/file/DirPermissionDenied.java
+
+ @BeforeTest
+ public void setup() throws Throwable {
+ // mkdir and chmod "333"
+ Files.createDirectories(TEST_DIR);
+ ProcessTools.executeCommand("chmod", "333", TEST_DIR.
http://cr.openjdk.java.net/~iignatyev/8181335/webrev.00/index.html
> 298 lines changed: 61 ins; 96 del; 141 mod;
Hi all,
could you please review this fix which removes packageless CompilerUtils and
updates all its users to use jdk.test.lib.compiler.CompilerUtils instead?
webrev: http://cr.openj
sun/net/www/protocol/file/DirPermissionDenied.java
+
+ @BeforeTest
+ public void setup() throws Throwable {
+ // mkdir and chmod "333"
+ Files.createDirectories(TEST_DIR);
+ ProcessTools.executeCommand("chmod", "333", TEST_DIR.toString()) Maybe just
do this with java api instead run chmod comman
Hi Paul,
Thank you for review. Modified as you suggested, it makes the test more
simple. The code was pushed.
Thank you
-Hamlin
On 2017/6/6 6:41, Paul Sandoz wrote:
I eyeballed quickly and it looks ok.
NonSerializableTest
--
59 return new String[][][] {
60 // Wri
Just as a point of information:
The HotSpot team was well aware of these issues when removing the @build
flags from the HotSpot test cases. We felt these were less evils than
random failures in our test runs. After the @build removal, the
incidence of random NoClassDefFoundError in HotSpot tes
On 6/5/17 10:52 PM, Alan Bateman wrote:
webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/
I think it's a bit confusing to have both DeleteOnClose and
DeleteOnTerminate, esp. when DeleteOnTerminate creates a file with
DELETE_ON_CLOSE. Instead couldn't DeleteOnClose just launch itself t
Thanks:-)
-Felix
On 2017/6/1 16:32, Felix Yang wrote:
Hi there,
please review the patch convert several sun/net shell tests to
plain java tests.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8181080
Webrev:
http://cr.openjdk.java.net/~xiaofeya/8181080/webrev.00/
Thanks,
Felix
From the mails I can appreciate people have wildly different opinion
about the virtue of @build :-)
But regardless of your opinion on @build, I think the issue I identified
in CODETOOLS-7901986 [1] is definitely a bug -- the bug is when a
library is compiled, it incorrectly depends on classes
> On Jun 5, 2017, at 4:52 PM, Jonathan Gibbons
> wrote:
>
> a. That will blow up the space requirements, if every test that uses a
> library gets its own compiled version of the library ... especially with the
> current trend in the jdk/hotspot repos of using deep package hierarchies.
do we h
a. That will blow up the space requirements, if every test that uses a
library gets its own compiled version of the library ... especially with
the current trend in the jdk/hotspot repos of using deep package
hierarchies.
b. Using implicit compilation will not detect changes to files that were
from my point of view, we expect to much works from test authors for little
benefits. as you can see in another email thread[1-2], sharing library classes
saves very little time. hence if it's the only benefits of having correct
explicit @build actions for library classes, I'd prefer us to remov
You cannot completely disable implicit compilation as a concept, because
it is built into javac, and has been since Day One.
But we could reduce its impact.
javac does have an option -implicit:none, which stops it *writing*
implicitly compiled classes, (but not stop it reading them). So the
c
Hi Jon,
if tests are supposed to declare all library classes they depend on, tests
start to depend on a library design, so refactoring of the library will force
us to do massive update of the tests to fix their explicit builds, but to find
all such tests, we will have to run them one by one. so
Thanks. I accidentally deleted your first message so did not read it. Apologies
for the confusion.
Paul.
> On 5 Jun 2017, at 15:43, Vladimir Kozlov wrote:
>
> To clarify. I agree with this renaming to be pushed into JDK 9.
>
> AOT testing failures will be fixed separately as fix for 8180785 b
I eyeballed quickly and it looks ok.
NonSerializableTest
--
59 return new String[][][] {
60 // Write NonSerial1, Read NonSerial1
61 new String[][] {new String[] {"NonSerialA_1", "-cp", ".",
"TestEntry", "-s", "A"}},
62 new String[][] {new String
To clarify. I agree with this renaming to be pushed into JDK 9.
AOT testing failures will be fixed separately as fix for 8180785 bug which requires changes in Graal. Renaming should be pushed first before we fix Graal to simplify Graal changes (no need to
condition for JDK 10 and 9).
Thanks,
V
On 06/05/2017 03:24 PM, Martin Buchholz wrote:
Can we find missing @build directives by running each individual jtreg
test by itself with a clean JTwork directory?
That's generally been the recommended way.
You might also be able to do run groups of tests (such as all tests that
use a given
Can we find missing @build directives by running each individual jtreg test
by itself with a clean JTwork directory?
just out of curiosity I have removed @build for all jdk.testlibary classes as
well and run :tier1, it took approximately the same amount of time[1], the
breakdown[2] shows that we spend 70 seconds more on build actions, which is not
that big comparing to total execution time.
-- Igor
[1]
real
On 05/31/2017 12:27 AM, Alan Bateman wrote:
On 27/05/2017 07:30, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html
308 lines changed: 110 ins; 40 del; 158 mod
One general comment about all these moves is that I see that many
tests are being changed t
Igor, Ioi,
I have read Ioi's mail and the supposed bug fix.
While the fix may hide the problem, the root cause is still that tests
are not providing accurate @build directives, and are relying on
implicit compilation to compile the files. This is not the way that
jtreg is intended to be used,
On 05/31/2017 01:38 AM, Alan Bateman wrote:
On 31/05/2017 09:05, Felix Yang wrote:
Hi Alan
even with explicit compilation, I also observed failures. I'm
curious what is the best practice here. IMO, there could be a
potential jtreg bug.
One of the tests listed in JDK-8181299 is
java/ne
On 6/6/17 12:11 AM, Amy Lu wrote:
Good point!
Please review the updated version:
http://cr.openjdk.java.net/~amlu/8181396/webrev.01
Sorry, I have to withdraw this version. Somehow this does not work on
Windows, the created blah*tmp will not be deleted until the launched
DeleteOnClose (by itsel
Ok, thanks,
Paul.
> On Jun 4, 2017, at 18:39, Felix Yang wrote:
>
> Hi Paul,
>
> this is from original test logic. According with the bug history, it is
> added by https://bugs.openjdk.java.net/browse/JDK-7152892 to avoid
> intermittent test failures.
>
> Thanks,
> Felix
Good point!
Please review the updated version:
http://cr.openjdk.java.net/~amlu/8181396/webrev.01
Thanks,
Amy
On 6/5/17 10:52 PM, Alan Bateman wrote:
On 05/06/2017 07:54, Amy Lu wrote:
java/nio/file/Files/delete_on_close.sh
Please review this patch to refactor the shell test to java.
bug: h
On 05/06/2017 07:54, Amy Lu wrote:
java/nio/file/Files/delete_on_close.sh
Please review this patch to refactor the shell test to java.
bug: https://bugs.openjdk.java.net/browse/JDK-8181396
webrev: http://cr.openjdk.java.net/~amlu/8181396/webrev.00/
I think it's a bit confusing to have both Dele
28 matches
Mail list logo
