[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640970#comment-16640970
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}Using it will bring all the advantages of a standard API.
{quote}
I agree with using the standard API here. However, there are a couple of slight
issues.
# The transform classes are used to transform both points and vectors, but we
can only choose one to be the type for UnaryOperator. It should probably be
points, but it seems weird to leave vectors out like that.
# The {{andThen}} and {{compose}} methods from {{java.util.Function}} don't
really provide the behavior we want when chaining transforms. The JDK versions
return new functions that invoke the original ones in the correct order. What
we want in our method is to multiply the transform matrices together to create
a new matrix that mathematically performs the same operations as if the
original matrices were applied in order. So, the end result is the same but the
internals (and performance) are quite different. I think we need a separate
method name to convey this concept. I previously proposed {{transform}} but
some other options might be {{build}}, {{combine}}, ...
{quote}Maybe, but caution still applies for anything that goes into the public
API. The fluent API is nice but we should explore the alternatives.
{quote}
Yes. I do quite like it, though, and I think it will get some good use. Did you
have any other alternatives in mind?
{quote}This is a can of worms, as it will prevent any simple implementation of
multi-threaded processing.
{quote}
I've refactored this in my working branch so that the classes are truly
immutable, ie all fields are final.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640904#comment-16640904
]
Gilles commented on GEOMETRY-14:
{quote}A.transform(B).transform(C) would logically perform A, then B, then C.
{quote}
With
[UnaryOperator|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html],
this would be expressed either as
{code:java}
A.andThen(B).andThen(C)
{code}
or as
{code:java}
C.compose(B).compose(A)
{code}
Using it will bring all the advantages of a standard API.
{quote}{{t.apply(p1.vectorTo(p2)).normalize()}} is more difficult to read.
{quote}
Maybe, but caution still applies for anything that goes into the public API.
The fluent API is nice but we should explore the alternatives.
{quote}I do not have the private fields set as final so that I can do things
like copying
{quote}
This is a can of worms, as it will prevent any simple implementation of
multi-threaded processing.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640891#comment-16640891
]
Alex D Herbert commented on RNG-57:
---
Having though about this the simulation can be modelled as a Binomial
distribution.
Each Chi square test has a probability of failure of 0.01 (if the RNG is
perfect).
Here's the CDF for a Binomial(n=500, p=0.01):
||Number of failures (k)||CDF(x <= k)||1 - CDF(x <= k)||
|0|0.0066|0.9934|
|1|0.0398|0.9602|
|2|0.1234|0.8766|
|3|0.2636|0.7364|
|4|0.4396|0.5604|
|5|0.6160|0.3840|
|6|0.7629|0.2371|
|7|0.8677|0.1323|
|8|0.9329|0.0671|
|9|0.9689|0.0311|
|10|0.9868|0.0132|
|11|0.9948|0.0052|
|12|0.9981|0.0019|
|13|0.9994|0.0006|
|14|0.9998|0.0002|
|15|0.|0.0001|
|16|1.|0.|
So the current limit of 10 will be exceeded at a rate of (1 - 0.9868) = 0.0132.
To make the test robust the p-value for failure can be set at p=0.001. Then the
limit would have to be 13 failures.
If the RNG is not perfect then the Chi square test will fail more often than 1%
of the time and this should easily be detected.
I'll collate the results from testing each provider with random seeds and see
what the failure rate would be for each at different failure thresholds.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-697) JavaDoc for FixedSizeList should warn that modifying underlying list is still allowed and is not prevented
[
https://issues.apache.org/jira/browse/COLLECTIONS-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640867#comment-16640867
]
ASF GitHub Bot commented on COLLECTIONS-697:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-collections/pull/55
> JavaDoc for FixedSizeList should warn that modifying underlying list is still
> allowed and is not prevented
> --
>
> Key: COLLECTIONS-697
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-697
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Ranjan George
>Priority: Major
>
> I just noticed that it is not explicitly mentioned in the JavaDoc that
> modifying the underlying list of a FixedSizeList would actually land up
> modifying the list of the constructed FixedSizeList. Not sure if this was by
> design, but at the very list I think the JavaDoc should caution against this.
> Following is a test case that written that you could use to check this.
> {code:java}
> public void testAllowsMutationOfUnderlyingCollection() {
> List decoratedList = new ArrayList<>();
> decoratedList.add("item 1");
> decoratedList.add("item 2");
> //
> FixedSizeList fixedSizeList =
> FixedSizeList.fixedSizeList(decoratedList);
> int sizeBefore = fixedSizeList.size();
> //
> boolean changed = decoratedList.add("New Value");
> Assert.assertTrue(changed);
> //
> Assert.assertEquals("Modifying an the underlying list is allowed",
> sizeBefore + 1, fixedSizeList.size());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-697) JavaDoc for FixedSizeList should warn that modifying underlying list is still allowed and is not prevented
[
https://issues.apache.org/jira/browse/COLLECTIONS-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640866#comment-16640866
]
ASF GitHub Bot commented on COLLECTIONS-697:
Github user asfgit closed the pull request at:
https://github.com/apache/commons-collections/pull/55
> JavaDoc for FixedSizeList should warn that modifying underlying list is still
> allowed and is not prevented
> --
>
> Key: COLLECTIONS-697
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-697
> Project: Commons Collections
> Issue Type: Bug
>Reporter: Ranjan George
>Priority: Major
>
> I just noticed that it is not explicitly mentioned in the JavaDoc that
> modifying the underlying list of a FixedSizeList would actually land up
> modifying the list of the constructed FixedSizeList. Not sure if this was by
> design, but at the very list I think the JavaDoc should caution against this.
> Following is a test case that written that you could use to check this.
> {code:java}
> public void testAllowsMutationOfUnderlyingCollection() {
> List decoratedList = new ArrayList<>();
> decoratedList.add("item 1");
> decoratedList.add("item 2");
> //
> FixedSizeList fixedSizeList =
> FixedSizeList.fixedSizeList(decoratedList);
> int sizeBefore = fixedSizeList.size();
> //
> boolean changed = decoratedList.add("New Value");
> Assert.assertTrue(changed);
> //
> Assert.assertEquals("Modifying an the underlying list is allowed",
> sizeBefore + 1, fixedSizeList.size());
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640855#comment-16640855
]
Alex D Herbert commented on RNG-57:
---
I've had a look at {{ProvidersCommonParametricTest}} and why this fails.
In summary the test runs the RNG to create a uniform sample using 1000 samples
and tests it is uniform using a Chi squared test with a critical value at 1%.
500 repeat chi square tests are made and if more than 2% fail then this is a
test fail.
This is fair.
I only found one bug in the test and that was a rounding error setting the
range of the upper bin when the max was 2305843009213693951L (Long.MAX_VALUE /
4). It was out by 1 and so not a problem with a range this big and not the
reason for the test being flaky.
I did notice that the test is usually failing when the range under test is an
integer range that is not a power of 2. So it may be failing because the test
is checking not the randomness of the entire binary bits from the RNG but the
algorithm for generating an integer that is not a power of two. This algorithm
does not use the entire binary bits but is biased to using the least
significant bits since it sets the returned value using the modulus of the
binary bits using a rejection algorithm:
{code:java}
// Excerpt from BaseProvider.nextInt(int)
do {
bits = nextInt() >>> 1;
// Here the bits returned are composed of the least
// significant bits (bar one) from the random
val = bits % n;
} while (bits - val + (n - 1) < 0);
{code}
Since I have modified {{ProvidersCommonParametricTest}} to randomly seed each
time I am running it 1000 times and logging the number of test fails for each
test, e.g.
{noformat}
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1234 (9
out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 10 (6 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 12 (8 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (3 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out
of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 2016128993
(2 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1834691456
(7 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 869657561
(7 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 1570504788
(9 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4 (0 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 11 (6 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 19 (5 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 31 (8 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 32 (4 out of
500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 2305843009213693951
(4 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 4611686018427387902
(9 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 6917529027641081853
(2 out of 500 tests failed)
org.apache.commons.rng.core.source32.Well512a: Pass for n = 578 (3
out of 500 tests failed)
{noformat}
We expect to see 5 out of 500 tests failed.
I am going to do some analysis on the output to see if the tests for non-power
of two {{nextInt(int)}} and {{nextLong(long)}} are more flaky than the others.
If correct then this may be solved by:
- increasing the tolerance for those tests (i.e. >2% fail rate)
- increasing the number of samples for those tests (i.e. >1000)
- removing those tests and just using nextBytes[]
The last idea or a modification of it is to just test the RNG produces an
acceptable random stream of bits. Although fine for the current providers it
would not cover future providers that may override nextFloat, nextDouble,
nextInt(int), nextLong(long).
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
>
[jira] [Comment Edited] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640846#comment-16640846
]
Matt Juntunen edited comment on GEOMETRY-14 at 10/6/18 7:15 PM:
{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by
the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical
to the ease of use of the API. How about this: the transform classes follow the
JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and
{{transform.apply(pt)}}. We define _apply_ here to mean "take the calling
transform and apply it to the given argument." For combining/chaining
transforms, we use a _transform_ method, which we define as meaning "take the
calling object and transform it with the argument." We would then have
{{A.transform(B)}} mean "transform A with B", which would give us the correct
order of operations, eg {{A.transform(B).transform(C)}} would logically perform
A, then B, then C. We could also use this same definition of _transform_ in the
vector/point classes. For example, {{vec.transform(t)}} means "transform vec
with t."
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point
methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of
{{t.apply(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like
{{translate}} return new instances. I do not have the private fields set as
final so that I can do things like copying the results of internal computations
back into an existing instance.
was (Author: mattjuntunen):
{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by
the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical
to the ease of use of the API. How about this: the transform classes follow the
JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and
{{transform.apply(pt)}}. We define _apply_ here to mean "take the calling
transform and apply it to the given argument." For combining/chaining
transforms, we use a _transform_ method, which we define as meaning "take the
calling object and transform it with the argument." We would then have
{{A.transform(B)}} mean "transform A with B", which would give us the correct
order of operations, eg {{A.transform(B).transform(C)}} would logically perform
A, then B, then C. We could also use this same definition of _transform_ in the
vector/point classes. For example, {{vec.transform(t)}} means "transform vec
with t."
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point
methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of
{{t.transform(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like
{{translate}} return new instances. I do not have the private fields set as
final so that I can do things like copying the results of internal computations
back into an existing instance.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640846#comment-16640846
]
Matt Juntunen commented on GEOMETRY-14:
---
{quote}Yes, but {{apply(vec)}} is as clear and more concise, and now favored by
the JDK.
{quote}
That makes sense. I think the naming of these methods is going to be critical
to the ease of use of the API. How about this: the transform classes follow the
JDK convention and have {{apply}} methods, eg {{transform.apply(vec)}} and
{{transform.apply(pt)}}. We define _apply_ here to mean "take the calling
transform and apply it to the given argument." For combining/chaining
transforms, we use a _transform_ method, which we define as meaning "take the
calling object and transform it with the argument." We would then have
{{A.transform(B)}} mean "transform A with B", which would give us the correct
order of operations, eg {{A.transform(B).transform(C)}} would logically perform
A, then B, then C. We could also use this same definition of _transform_ in the
vector/point classes. For example, {{vec.transform(t)}} means "transform vec
with t."
{quote}Usual question: Why adding to the API?
{quote}
I want transforms to be able to be applied inline with other vector/point
methods. For example, {{p1.vectorTo(p2).transform(t).normalize()}} instead of
{{t.transform(p1.vectorTo(p2)).normalize()}}, which is more difficult to read.
{quote}Does that mean that the class is mutable?
{quote}
It is immutable from outside of the class. All of the methods like
{{translate}} return new instances. I do not have the private fields set as
final so that I can do things like copying the results of internal computations
back into an existing instance.
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640740#comment-16640740 ] Gary Gregory commented on BEANUTILS-509: Weird: When I run a build with Maven and all the test or only the one test, the test times out and the build fails: mvn clean test -Dtest=Jira509TestCase. When I run the test from Eclipse, it completes in 12 seconds. My loop boundary is set to 10_000_000. > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640734#comment-16640734 ] Gary Gregory commented on BEANUTILS-509: Would you say that a side issue here would be for [collections] to provide a "ConcurrentWeakHashMap"? > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640723#comment-16640723
]
Gilles commented on RNG-57:
---
bq. I am wondering if the ProvidersList should make a better attempt at
creating a full length seed.
As you note, the "scramble" method is supposed to avoid obvious pitfalls like
the seed being mostly zeroes or other periodic set of bits.
If only full length seeds were necessary to make tests that use a few generated
numbers pass, I'd guess that it would indicate an expectation problem (thus
change the test) or a dysfunctional RNG (thus fix the RNG).
My preference would be to have the unit test run with different (random) seeds
at each build. Junit can take care of repeating failing tests (called "flaky")
but IIUC, it would only rerun a {{@test}} whereas in this case, it is the
{{ProvidersList}} instance that must be reloaded. So this would imply moving
the code from a {{static}} block to a regular constructor, and pass it to the
unit test classes in a different way.
Currently, I don't think this refactoring is worth the time and the possible
drawbacks.
bq. I can create a temp branch to try different seeds until it passes on Travis
then formulate an atomic PR.
Agreed; the first thing would be to "empirically" try a few seeds to ensure
that the tests pass much more often than they fail.
If that's the case; the stress tests suites will ensure (if the result are OK)
that the cache did not degrade the quality of the randomness of {{nextInt()}}.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640722#comment-16640722
]
Alex D Herbert commented on RNG-57:
---
Wow that test is hard to get to pass.
I just tried this using a 1024 byte random seed for all tests. The seed is
stored as a string and decoded using Commons Codec:
{code:java}
public class ProvidersList {
/** List of all RNGs implemented in the library. */
private static final List LIST =
new ArrayList();
/** List of 32-bits based RNGs. */
private static final List LIST32 =
new ArrayList();
/** List of 64-bits based RNGs. */
private static final List LIST64 =
new ArrayList();
/**
* Provide a random byte seed encoded as a hex string (length must be even).
*
* 1024 bytes = 2048 hex characters. This provides 128 longs and 256
integers.
*/
private static final String HEX_SEED =
"75d1fb070512e503f9635706318f2dabbd6e2120addbd50c8ff8272654f3082c"
+ "edf244845db03415bf661051d9a487c622b6411a6773596f459465c72d59e870"
+ "c6bd90089a6fb7294d3beea8feba7d8307745cbd1233b6f85ff0294f87483d9a"
+ "ea77939ced0eb7e41617b52ac5a0d32d49c456e7b4c2485bd8d8be990f626458"
+ "86c5194aa34eb1f83efc38808ebf1fcd813667f88e7a76191dee40f662968a8c"
+ "71cf6493497ad77e00efbb59bfbf9b7664f8c32b4f5f29064329174bbce4870d"
+ "bb6bfd683415428d1c2c76eacca237df7119ecf1e6eac7cc97f3548bb10255b0"
+ "74a44010fa4811fc622104cea4ca045c674bbaa65f2273879301c4902bdb2f72"
+ "b9e7b1f5414704bb240a6a4d490a39739a557338b1e58cb5e81d8157172482d0"
+ "407795dffa92caacf3db3c848e1f2962bd5e8ddd4691a49779eea65d38d9d584"
+ "9b7ea054677618a9f56893877c34bb5d928308c8be19e07627b646cc743d0ddf"
+ "44757e64c1268eeb5e88a55a718f4fb9ba313b68ab1729efff6989192c95a2d8"
+ "42292766523b8d03e2dc10b1157b45909ecf239e59a4334eafa0b48c39a980dc"
+ "0f4238dcdaf306a57a29758a23f992eb7d13439ad982ec5a83aac630a31e05a3"
+ "0724a7babb5ebbcc00144c90a9a79c976f7cdd516fd94a432e815e3aeffdccb0"
+ "515a409dcfe7f492c0015234706eff83eda607cf76ec9b0f74a6d3050fc1f469"
+ "42475ef814847c5053fffa1e5d732f8954f1d6a678ce88e19ca92f6d5b945ac3"
+ "f872c05f3481659f27f570f3d387e1a75bc17408d454c6b4190d78c6aeac2cc5"
+ "0d8042b373ca4f149e32b81933076c23c2e3e36d7ba29079dd0e605b617c6378"
+ "ee714b66cb0959f4ff127cf1f0ad42919780fc51174c8818a630d32bfca5b03c"
+ "698e63f774dc979a27dddc795d5146ab49baf32b79014bf2e533e82d663da5d8"
+ "42d57fbe1e1a270ccb17c6daf1ea6cad92a4f6b311dee23f5362106d0cda8130"
+ "ae391221e790a610b6bbd9f64bf988783a5fde4b0d3504a417aac0a1a70b8c4a"
+ "6395ae21e41c1efa31a37737b15d4c8c77909306c41028ea9e04d7f0141b2c13"
+ "d6e0d20a0df619b575eeb1c6aebd7f03b56060c4bf4cf1fdcea3f0a9d03d8e61"
+ "54d8d9c92fb5eba0f3f3ddaa82190c766d0c5acdc52b29cf4dfe45731434e443"
+ "8652301bbba00bad464a467abfe46283adfd05bffad627171140fbbbf6d080a0"
+ "9971e17c0771abe6e354eb2e3330449080cf2133ac5b4a4240c357c50b5b144b"
+ "7c8fd76935fbb2741b4def4ea7f2455d794e600a121d16172fc4c951ba152b89"
+ "99232249e456e47ed12270959e2d5ae97a73b6d448a958e9c644e51af7199ce8"
+ "ed6a277f88a599093214e70832fe52ebf99862ce2e59da603a909075c238a8cf"
+
"42f359f7d269716bf53fcd10e04f3149b55dafce78cc8d5f2753723b1a202d86";
static {
try {
// Decode the seed into bytes.
byte[] bytes = Hex.decodeHex(HEX_SEED);
// Create long seeds
DataInputStream dis = new DataInputStream(new
ByteArrayInputStream(bytes));
long[] longSeed = new long[bytes.length / 8];
if (longSeed.length < 10) {
throw new Exception("Not enough seed bytes");
}
for (int i = 0; i < longSeed.length; i++) {
longSeed[i] = dis.readLong();
}
dis.close();
// Create int seeds
dis = new DataInputStream(new ByteArrayInputStream(bytes));
int[] intSeed = new int[bytes.length / 4];
for (int i = 0; i < intSeed.length; i++) {
intSeed[i] = dis.readInt();
}
dis.close();
// "int"-based RNGs.
add(LIST32, new JDKRandom(longSeed[0]));
add(LIST32, new MersenneTwister(intSeed));
add(LIST32, new Well512a(intSeed));
add(LIST32, new Well1024a(intSeed));
add(LIST32, new Well19937a(intSeed));
add(LIST32, new Well19937c(intSeed));
add(LIST32, new Well44497a(intSeed));
add(LIST32, new Well44497b(intSeed));
add(LIST32, new ISAACRandom(intSeed));
add(LIST32, new MultiplyWithCarry256(intSeed));
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640712#comment-16640712
]
Alex D Herbert commented on RNG-57:
---
I've closed the PR and repeated the changes in a new branch.
Do you want me to experiment with different seeds in {{ProvidersList}} until
the tests pass? A quick change to add a few more numbers to the MWC_256 seed
has fixed the test locally.
Unfortunately travis may still fail as it runs JDK 7, 8 and 9 and locally
passing tests on one machine may not transfer.
I am wondering if the {{ProvidersList}} should make a better attempt at
creating a full length seed. Perhaps this will make the test more robust.
Previously the RNGs that failed were:
||RNG||Native seed||Test seed||
|Well1024a|int[32]|int[3]|
|XorShift1024Star|long[16]|long[3]|
|MersenneTwister|int[624]|int[3]|
|MultiplyWithCarry256|int[257]|int[4]|
So the seed could be made full length for each provider.
Although each provider does expand the seed to the full length using a
scrambling method the original seed could be improved using numbers that have
more complete coverage of the bit size of the native seed type. The numbers
typed into the test are quite short and may not contribute enough entropy.
Using java.util.Random is an option. However I am not sure the implementation
is guaranteed to return the same sequence for the same seed for all future JDK
versions. So hardcoding the seed is probably better.
WDYT?
- Repeat the PR as is with it failing and leave {{ProvidersList}} for a
different change?
- Update the PR to include better seeds for {{ProvidersList}}
Applying the code changes is easy. I can create a temp branch to try different
seeds until it passes on Travis then formulate an atomic PR.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #367: Update event tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/367 [](https://coveralls.io/builds/19384615) Coverage remained the same at 95.253% when pulling **762641dcdbae9456aa2b72ec8fa1baa0acab942f on mureinik:junit-jupiter-event** into **dd761382d3cfdc11b5de0cb1246de4567cdf2fc2 on apache:master**. ---
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640698#comment-16640698
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert closed the pull request at:
https://github.com/apache/commons-rng/pull/11
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #367: Update event tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/367 Update event tests to JUnit Jupiter Upgrade the tests in the event package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, it is worth noting the tests that test thrown exceptions. Prior to this patch, this package tested for exceptions in two ways, neither of which are supported in JUnit Jupiter: 1. With the `expected` argument of the `org.junit.Test` annotation. 2. With the `org.junit.rules.ExpectedException` `@Rule` Both of these usages were replaced with calls to `org.junit.jupiter.api.Assertions#assertThrows`. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-event Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/367.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #367 commit 762641dcdbae9456aa2b72ec8fa1baa0acab942f Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update event tests to JUnit Jupiter Upgrade the tests in the event package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, it is worth noting the tests that test thrown excetpions. Prior to this patch, this package tested for exceptions in two ways, neither of which are supported in JUnit Jupiter: 1. With the "expected" argument of the org.junit.Test annotation. 2. With the org.junit.rules.ExpectedException @Rule Both of these usages were replaced with calls to org.junit.jupiter.api.Assertions#assertThrows. ---
[jira] [Commented] (RNG-57) CachedUniformRandomProvider for nextBoolean() and nextInt()
[
https://issues.apache.org/jira/browse/RNG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640697#comment-16640697
]
ASF GitHub Bot commented on RNG-57:
---
Github user aherbert commented on the issue:
https://github.com/apache/commons-rng/pull/11
This branch has too many commits. I am closing the PR and will create a new
one from master.
> CachedUniformRandomProvider for nextBoolean() and nextInt()
> ---
>
> Key: RNG-57
> URL: https://issues.apache.org/jira/browse/RNG-57
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: performance
>
> Implement a wrapper around a {{UniformRandomProvider}} that can cache the
> underlying source of random bytes for use in the methods {{nextBoolean()}}
> and {{nextInt()}} (in the case of {{LongProvider}}). E.g.
> {code:java}
> LongProvider provider = RandomSource.create(RandomSource.SPLIT_MIX_64);
> CachedLongProvider rng = new CachedLongProvider(provider);
> // Uses cached nextLong() 64 times
> rng.nextBoolean();
> // Uses cached nextLong() twice
> rng.nextInt();
> IntProvider provider = RandomSource.create(RandomSource.KISS);
> CachedIntProvider rng2 = new CachedIntProvider(provider);
> // Uses cached nextInt() 32 times
> rng2.nextBoolean();
> // This could be wrapped by a factory method:
> UniformRandomProvider rng = CachedUniformRandomProviderFactory.wrap(
> // Any supported source: IntProvider or LongProvider
> RandomSource.create(RandomSource...));
> {code}
> The implementation should be speed tested to determine the benefit for
> {{nextBoolean()}} and if {{nextInt()}} can be improved for {{LongProviders}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-59) More robust "SeedFactory"
[
https://issues.apache.org/jira/browse/RNG-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated RNG-59:
--
Description:
{{SeedFactory}} will produce the same seed when several instances of the same
program are launched in rapid successions.
In the {{static}} block of {{SeedFactory}}, an initial "random" seed is
generated using {{System.currentTimeMillis()}}.
I think that it should be replaced by retrieving data from a {{SecureRandom}}
instance.
The drawback is that instantiating such an object is necessary slower. However
if it is the way to go (to ensure different initial seeds in parallel runs of a
program), the question is whether to use only {{SecureRandom}} to create the
(relatively large) state of the RNG used by the {{SeedFactory}} or to use it
only to generate 8 bytes (and proceed with the rest of the _static_ block as it
is now).
was:{{SeedFactory}} will produce the same seed when several instances of the
same program are launched in rapid successions.
> More robust "SeedFactory"
> -
>
> Key: RNG-59
> URL: https://issues.apache.org/jira/browse/RNG-59
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.0, 1.1
>Reporter: Gilles
>Priority: Major
> Fix For: 1.2
>
>
> {{SeedFactory}} will produce the same seed when several instances of the same
> program are launched in rapid successions.
> In the {{static}} block of {{SeedFactory}}, an initial "random" seed is
> generated using {{System.currentTimeMillis()}}.
> I think that it should be replaced by retrieving data from a {{SecureRandom}}
> instance.
> The drawback is that instantiating such an object is necessary slower.
> However if it is the way to go (to ensure different initial seeds in parallel
> runs of a program), the question is whether to use only {{SecureRandom}} to
> create the (relatively large) state of the RNG used by the {{SeedFactory}} or
> to use it only to generate 8 bytes (and proceed with the rest of the _static_
> block as it is now).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BEANUTILS-509) WeakHashmap enters into infinite loop in WrapDynaClass.java
[ https://issues.apache.org/jira/browse/BEANUTILS-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640688#comment-16640688 ] Akshay Gehi commented on BEANUTILS-509: --- Hi Gary, I mentioned in the Junit that the test case is extremely hard to reproduce, we faced this after running the class for 30 hours continuously. As you know, WeakHashMap is quite unpredictable and the BeanUtils makes use of this class in a non-thread safe manner which causes the problem and I have fixed that. I cannot add any further test cases. In case someone else can pitch or have any suggestions, I can have a look. Regards, Akshay Gehi > WeakHashmap enters into infinite loop in WrapDynaClass.java > --- > > Key: BEANUTILS-509 > URL: https://issues.apache.org/jira/browse/BEANUTILS-509 > Project: Commons BeanUtils > Issue Type: Bug > Components: DynaBean >Affects Versions: 1.8.2 >Reporter: sunil >Priority: Major > Attachments: WrapDynaCache.patch, > WrapDynaCache_after_svn_commit.patch, console.log.backup > > > We noticed that our application was using too much of CPU , all the 6 cores > were used. > On capturing the thread dump we saw that large number of threads were in the > running state and in : > at java.util.WeakHashMap.get(WeakHashMap.java:403) > at > org.apache.commons.beanutils.WrapDynaClass.createDynaClass(WrapDynaClass.java:425) > > So we are suspecting that the thread has entered into indefinite while loop > and hogging all the CPU resources. > I have attached the thread dump for reference. > > what is the solution for this issue? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-14) AffineTransform?D Classes
[
https://issues.apache.org/jira/browse/GEOMETRY-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16640689#comment-16640689
]
Gilles commented on GEOMETRY-14:
{quote}the API would be a bit more awkward, assuming that by A.compose(B) we
mean "perform B then perform A"
{quote}
It's not what I'd assume; so I see the possible confusion. ;)
Couldn't we leverage the [JDK
API|https://docs.oracle.com/javase/8/docs/api/java/util/function/UnaryOperator.html]?
I.e. have something like
{code:java}
public class AffineTransform3D implements UnaryOperator
{code}
{quote}{{transform.applyTo(vec)}} [because] they are applied _to_ points and
vectors.
{quote}
Yes, but {{apply(vec)}} is as clear and more concise, and now favored by the
JDK.
{quote}The vector and point classes have corresponding {{vec.apply(transform)}}
{quote}
Usual question: Why adding to the API?
Furthermore, this one is fairly counter-intuitive: to be consistent it should
have been {{vec.isAppliedToBy(transform)}}.
{quote}translate is an instance method and applies a translation to the current
transform.
{quote}
Does that mean that the class is mutable? :(
> AffineTransform?D Classes
> -
>
> Key: GEOMETRY-14
> URL: https://issues.apache.org/jira/browse/GEOMETRY-14
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
>
> We should create AffineTransform?D classes that implement matrix-based affine
> transforms. They should have simple methods for creating translations,
> rotations, and scaling and calculating the inverse.
>
> Pull Request #1: https://github.com/apache/commons-geometry/pull/14
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang issue #366: Update concurrent tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/366 Thanks! ð ---
[GitHub] commons-lang pull request #366: Update concurrent tests to JUnit Jupiter
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/366 ---
[GitHub] commons-lang issue #366: Update concurrent tests to JUnit Jupiter
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/366 [](https://coveralls.io/builds/19384033) Coverage increased (+0.007%) to 95.253% when pulling **dd761382d3cfdc11b5de0cb1246de4567cdf2fc2 on mureinik:junit-jupiter-concurrent** into **6191dedf35e1afe784fac9b4845f699749037346 on apache:master**. ---
[GitHub] commons-lang pull request #366: Update concurrent tests to JUnit Jupiter
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/366 Update concurrent tests to JUnit Jupiter Upgrade the tests in the concurrent package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike `org.junit.Test`, `org.junit.jupiter.api.Test` does not have an `expected` argument. Instead, an explicit call to `org.junit.jupiter.api.Assertions.assertThrows` is used. This call allows the test to pinpoint the exact statement that is expected to throw the exception and allows making the tests a bit stricter by preventing false-positives that could occur if the setup code would throw the expected exception instead of the statement that was supposed to throw it. Another notable change was performed in `MemoizerTest`. JUnit Jupiter does not support JUnit 4's runners, and EasyMock has no equivalent `@Extension`, so a setup method was added and the mock was explicitly initialized. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made more elegant with Jupiter's new features, but that work is left for subsequent patches. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang junit-jupiter-concurrent Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/366.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #366 commit dd761382d3cfdc11b5de0cb1246de4567cdf2fc2 Author: Allon Mureinik Date: 2018-10-02T03:41:37Z Update concurrent tests to JUnit Jupiter Upgrade the tests in the concurrent package to use JUnit Jupiter as part of the effort to remove the dependency on the Vintage Engine. While most of these changes are drop-in replacements with no functional benefit, there are some non-obvious changes worth mentioning. Unlike org.junit.Test, org.junit.jupiter.api.Test does not have an "expected" argument. Instead, an explicit call to org.junit.jupiter.api.Assertions.assertThrows is used. This call allows the test to pinpoint the exact statement that is expected to throw the exception and allows making the tests a bit stricter by preventing false-positives that could occur if the setup code would throw the expected exception instead of the statement that was supposed to throw it. Another notable change was performed in MemoizerTest. JUnit Jupiter does not support JUnit 4's runners, and EasyMock has no equivalent @Extension, so a setup method was added and the mock was explicitly initialized. It's also worth noting this is a minimal patch for migrating the package's tests to Jupiter. There are several tests that can be made made more elegant with Jupiter's new features, but that work is left for subsequent patches. ---
[GitHub] commons-lang pull request #365: Travis: Also build with openjdk-ea
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/365 ---
[GitHub] commons-lang issue #365: Travis: Also build with openjdk-ea
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/365 [](https://coveralls.io/builds/19383591) Coverage decreased (-0.007%) to 95.246% when pulling **a3a1904e5964a97a20d5132569beb2901d2cd919 on PascalSchumacher:travis_openjdk_ea** into **8e507bd0b188b497ed371b8a6772b0e6ad9bd1cd on apache:master**. ---
[GitHub] commons-lang pull request #365: Travis: Also build with openjdk-ea
GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-lang/pull/365 Travis: Also build with openjdk-ea You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-lang travis_openjdk_ea Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/365.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #365 commit a3a1904e5964a97a20d5132569beb2901d2cd919 Author: pascalschumacher Date: 2018-10-06T08:30:32Z Travis: Also build with openjdk-ea ---
[GitHub] commons-lang pull request #363: Update builder tests to JUnit Jupiter
Github user mureinik closed the pull request at: https://github.com/apache/commons-lang/pull/363 ---
[GitHub] commons-lang issue #363: Update builder tests to JUnit Jupiter
Github user mureinik commented on the issue: https://github.com/apache/commons-lang/pull/363 > Thanks! ð > > Merged in [729adb6](https://github.com/apache/commons-lang/commit/729adb624d3e720afb8686093814ab2bcc2d2f13) > > Not sure why this pull request was not auto-closed even-though I fast-forward merged the branch. > > Could you please close the pull request? > > Thanks! Closing, thanks @PascalSchumacher ---
[GitHub] commons-lang issue #363: Update builder tests to JUnit Jupiter
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/363 Thanks! ð Merged in https://github.com/apache/commons-lang/commit/729adb624d3e720afb8686093814ab2bcc2d2f13 Not sure why this pull request was not auto-closed even-though I fast-forward merged the branch. Could you please close the pull request? Thanks! ---
[GitHub] commons-lang pull request #359: these 2 links seem to be broken
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/359 ---
[GitHub] commons-lang issue #359: these 2 links seem to be broken
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/359 Thanks! ð ---
