Maybe when there's something breaking in Java 10 or 11, I can do that.
Right now, that approach requires me to have a fork of my code, have
special build goop, rely on yet another Java 9 feature, and make my
relatively widely used OSS project require Java 9 to build *prior to Java
9's release -* ju
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/
The big hammer check disallowing MethodHandles::lookup be called by system
classes defined by the bootstrap class loader was added as defense-in-depth
to prevent this caller-sensitive method being called from JDK internal
Or use multi-release JARs.
On 4/25/2017 3:14 AM, Jeremy Manson wrote:
I guess I can call it reflectively.
So how long does the test typically take to run, with and without -Xcomp.
If you are running with -Xcomp /and/ a timeoutfactor, that timeout of
1200s is going to be multiplied by the timeout factor!
-- Jon
On 05/01/2017 01:44 PM, Brent Christian wrote:
The test runs in question are using an i
A timeout of 1200 seconds (20 minutes) is pretty extreme.
If you are testing configurations with -Xcomp. you might do better to
use the jtreg command-line option -timeoutfactor instead.
-- Jon
On 04/27/2017 12:08 PM, Brent Christian wrote:
Hi,
This test times out under our automated testing
On 5/1/17 12:50 PM, Mandy Chung wrote:
On May 1, 2017, at 12:47 PM, Brent Christian wrote:
>>>
One refactor you can consider by separating
them in several @run actions. The timeout will apply to each action
but that does not help shorten the test execution time.
I had the same thought, and
The test runs in question are using an increased timeout factor, but
this test still needs more time than its current timeout provides.
Thanks,
-Brent
On 5/1/17 1:22 PM, Roger Riggs wrote:
Hi,
Also, should it not be the case that running with -Xcomp should increase
the timeout factor
to avoid
Hi,
Also, should it not be the case that running with -Xcomp should increase
the timeout factor
to avoid such issues? I'm not sure how that can be assured though.
Roger
On 5/1/2017 3:47 PM, Brent Christian wrote:
On 5/1/17 12:41 PM, Mandy Chung wrote:
Looks like this test execs a new VM f
> On May 1, 2017, at 12:47 PM, Brent Christian
> wrote:
>
>
>> One refactor you can consider by separating
>> them in several @run actions. The timeout will apply to each action
>> but that does not help shorten the test execution time.
>
> I had the same thought, and concluded that without
On 5/1/17 12:41 PM, Mandy Chung wrote:
Looks like this test execs a new VM for 66 times to exhaust the
combination of with and without security manager, with a valid or
malformed policy, client & custom loader in unnamed, named, automatic
module.
Right.
I think we could take out the automatic
Looks like this test execs a new VM for 66 times to exhaust the combination of
with and without security manager, with a valid or malformed policy, client &
custom loader in unnamed, named, automatic module. I think we could take out
the automatic module case as named module would verify it. O
Hi, Joe
The typical run time of this test is ~18s (on my modestly-equipped
laptop). So the test does run within a reasonable amount of time, IMO -
under normal circumstances, anyway.
The increased timeout is to cover the less seldom test run
configurations involving Xcomp. Judging by when
12 matches
Mail list logo
