Hi Hamlin,
66 Thread.sleep(1000L * (long)TestLibrary.getTimeoutFactor());
Now that the factor has been casted to long, it could just use 1000
instead 1000L.
Could the fraction of this factor value be greater than 0?
If so, the casting should take effect after the multiplication, like
T
some background & comment: in most of failures, the
"test.timeout.factor" is 10.0 or 8.0, so in the test code this factor
should be considered in rmi operations such unexporting an object.
Thank you
-Hamlin
On 2019/9/4 11:01 AM, Hamlin Li wrote:
Hi,
Would you please review the following pat
Hi,
Would you please review the following patch?
Bug: https://bugs.openjdk.java.net/browse/JDK-8134599
webrev: http://cr.openjdk.java.net/~mli/8134599/webrev.00/
Thank you
-Hamlin
I spent some time last week playing with the jpackage tool, using build
14-jpackage+1-35 from https://jdk.java.net/jpackage.
Overall, I can see that you’ve made good progress, but there’s still some
work to be done. I’ll start with high-level comments and questions, and
then comment on my experie
Hi Daniel
Yes, that explains it. It is a jtreg setting[1], setup in makefile.
[1] https://openjdk.java.net/jtreg/command-help.html
-timeout: | -timeoutFactor:
A scaling factor to extend the default timeout of all tests.
Typically used when running on slow
On Mon, 2019-08-26 at 17:54 +0200, Severin Gehwolf wrote:
> Hi,
>
> Please review this 8u backport. The OpenJDK 11u patch does not apply
> cleanly after path-reshuffeling due to a) test and code for jaxp are
> split in JDK 8 b) Some rejects in comments - copyright and last
> modified date. I've om
There is no reason to wait until you can post your own RFR, this needs to be
addressed separately and I've taken some steps to fix it. Here's your latest
patch (please correct me if I'm wrong) as a webrev:
http://cr.openjdk.java.net/~prappo/8228580/webrev.00/
Let's discuss it.
As I said be
I did not read the help output well enough where it says "used if no
command line arguments are given to the launcher".
This means we cannot set any default arguments to the application launcher
and support manually entered command line arguments by the user.
Is there a reason for this limitation?
I can't reproduce this problem.
In my manual examples as well as our related automated test cases the
arguments specified by "--arguments " are being
delivered to the application when it is invoked without command line
arguments. (Note: if there are any arguments given to the command to
launc
Hi Milan,
I haven't keep up with this discussion, but your log shows:
-J-Dtest.timeout.factor=4.0 \
20s x 4.0 = 80s : mystery explained - or am I missing something?
best regards,
-- daniel
On 02/09/2019 18:58, Milan Mimica wrote:
I would expect the test to fail after 20 seconds (wi
10 matches
Mail list logo
