On Wed, 9 Aug 2017 23:48:30 +0100, sebb wrote:
On 9 August 2017 at 23:19, Gilles <gil...@harfang.homelinux.org>
wrote:
On Wed, 9 Aug 2017 15:46:54 +0100, sebb wrote:
On 9 August 2017 at 13:51, Gilles <gil...@harfang.homelinux.org>
wrote:
Hi.
Build with Java 8 runs fine:
https://travis-ci.org/apache/commons-math/jobs/262647212
But with Java 7:
https://travis-ci.org/apache/commons-math/jobs/262647211
Is anyone willing to debug this failure?
1) Bug in maven-jgit-buildnumber-plugin - rather noisy when it
cannot
find the current git info
That's not what makes the build fail since it happens in both.
2) Bug in JVM - buffer overflow.
That's the issue.
[I should have mentioned that I had also read the job log,
before posting.]
Yes, that would have saved others some effort.
Hmm, when asking for help to "debug the issue", I thought that
it was obvious that reading the log was involved necessary but
not sufficient...
Both of these could happen with any Java version.
Or is this a hint for making Java 8 the minimum supported
version for the next release?
That is not a valid conclusion from the evidence.
How do you draw that conclusion?
Because there is no proof that the failure is caused by using Java 7
rather than because the test uses a specific version of the Java 7
JVM.
JVM crashes tend to be specific to particular implementations.
It any case, a test that fails with a JVM crash is not a failure of
the code being tested but of the JVM itself.
Sure. Never implied that the problem was in the Java code...
More to the point, my request is: What to do to fix the negative
advertisement for the project which this Travis issue propagates
(see badge):
https://github.com/apache/commons-math
No idea. Ask a Travis guru.
More more to the point, that's the purpose of my posting here!
The negative publicity belongs to the specific Java 7 JVM which is
crashing.
Sure. Never implied anything else.
Commons Math should really be praised for exposing the bug.
And what will we do of it?
That was the "hint" referred to above: if there is no interest in
fixing that bug in a Java7 JVM, we should at least stop submitting
that job to Travis.
You are, of course, right that we do not have to target Java 8.
My point was: Is there anyone reading this interested in keeping
Java 7 compatibility?
And, if yes, then _those_ people should IMHO be interested in
fixing the problem reported here.
I think this just shows that automated checks are only useful if it
is
clearly understood how the checkers measure success/failure.
I don't follow. [Or do you suggest that Travis should report
"success" because the code succeeded in crashing the JVM ;-) ].
Gilles
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
