Thank you Roger and Jon for the comments!
Change request withdrawn :-)
Thanks,
Amy
On 10/14/17 3:04 AM, Roger Riggs wrote:
Hi Amy,
I don't see a problem with the cases of 'Total tests run: 0'. It is
very explicit, no tests were selected.
Testng has a number of dynamic mechanisms for test s
Hi Amy,
I don't see a problem with the cases of 'Total tests run: 0'. It is
very explicit, no tests were selected.
Testng has a number of dynamic mechanisms for test selection such that
even files in the test directories might not have any tests to run. As
Jon pointed out that's just part of
Actual mutability of the Unix process environment is something we have to
give up when moving to multi-threaded processes. The only time you get to
change the environment is when running single-threaded, typically around
fork/exec. Learn to live with it.
The Java System.getenv() is initialized f
FWIW, this is a side-effect of taking jtreg having to take some corner
cases into account when determining what are "jtreg" tests in a
hierarchy of TestNG tests.
The underlying problem is that there is no easy reliable way to
determine if a source file contains test cases or if it is just a
l
http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8189202/webrev.00/
This proposes to add a new jdeps --print-module-deps option to print a
comma-separated list of modules that the analyzed classes depend on and
such output can be taken by jlink --add-modules option. This will make
it easy for
Hi Adam,
On 13/10/2017 10:16 PM, Adam Farley8 wrote:
Hi All,
Here's a summary of the email below (which is intended, partly, as a
summary of the emails before it).
Let me know if you agree/disagree with any of these points.
1) Exit(#) during vm startup is a bug because it should return a co
On 13/10/2017 13:16, Adam Farley8 wrote:
Hi All,
Here's a summary of the email below (which is intended, partly, as a
summary of the emails before it).
Let me know if you agree/disagree with any of these points.
:
3) One solution is to specify a new return code for JNI.
Yes, hence the need t
Hi Alan,
Alan Bateman wrote on 2017/10/12 22:17:48:
> This is better but it still not safe. You'll have to atomically set/get
> the cachedLoader or put it into a thread local to ensure that
> resolveClass picks up the loader cached by the current thread. A thread
> local could work too althou
Hi All,
Here's a summary of the email below (which is intended, partly, as a
summary of the emails before it).
Let me know if you agree/disagree with any of these points.
1) Exit(#) during vm startup is a bug because it should return a code
regardless of the state of the VM.
2) Exit(0) is an *
On 10/13/2017 08:55 AM, Christoph Dreis wrote:
Hi Peter,
Thanks for your feedback!
Method.getName() returns an interned String and String literals are interned
strings. Reference comparison is therefore possible
Good point.
The pair (declaringClass, methodName) uniquely identifies the me
Hi all,
We are observing very infrequent assertion errors originating in
getUpperBoundASTs, mostly during concurrent builds on our build
machine, when it's under a heavy load. This has been happening from
time to time with various Java versions; most recently with 1.8.0_131.
I don't see anything
11 matches
Mail list logo
