[GitHub] [commons-io] TarCV commented on issue #31: DirectoryUtils - isEqual to compare directories
TarCV commented on issue #31: DirectoryUtils - isEqual to compare directories URL: https://github.com/apache/commons-io/pull/31#issuecomment-557734622 This would be great to have to do integration testing of libraries generating some file trees. Is there any plans on merging this PR? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] coveralls commented on issue #74: [RNG-124]: Add fixed increment PCG generators.
coveralls commented on issue #74: [RNG-124]: Add fixed increment PCG generators. URL: https://github.com/apache/commons-rng/pull/74#issuecomment-557729900 [](https://coveralls.io/builds/27188578) Coverage increased (+0.003%) to 99.508% when pulling **ad8052e6eff0a81b28f493c8da789129f0ddde29 on aherbert:improvement-RNG-124** into **a07fc4377bacbd5868728390ac3c2cd9855a7981 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #74: [RNG-124]: Add fixed increment PCG generators.
aherbert opened a new pull request #74: [RNG-124]: Add fixed increment PCG generators. URL: https://github.com/apache/commons-rng/pull/74 Adds a single Long argument constructor to: AbstractPcg6432 PcgXshRr32 PcgXshRs32 PcgRxsMXs64 Adds RandomSource: PCG_XSH_RR_32_OS PCG_XSH_RS_32_OS PCG_RXS_M_XS_64_OS OS = One Sequence This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (RNG-124) Create fixed increment PCG generators
Alex Herbert created RNG-124:
Summary: Create fixed increment PCG generators
Key: RNG-124
URL: https://issues.apache.org/jira/browse/RNG-124
Project: Commons RNG
Issue Type: Improvement
Components: core, simple
Affects Versions: 1.3
Reporter: Alex Herbert
Assignee: Alex Herbert
The increment of the PCG generator serves to select the underlying linear
congruential generator (LCG) from 2 classes of related generators. Thus
initialisation of generators using different increments can result in PCG
output with massive correlations. The result is that seeding with 128-bits does
not reduce the chance of correlated output over seeding with just 64-bits and
using a fixed increment. See RNG-123.
Create a fixed increment version of the three PCG generators which currently
accept the increment in their seed:
{noformat}
PCG_XSH_RR_32=> PCG_XSH_RR_32_OS
PCG_XSH_RS_32=> PCG_XSH_RS_32_OS
PCG_RXS_M_XS_64 => PCG_RXS_M_XS_64_OS
{noformat}
Here the {{_OS}} suffix represents One Sequence. The equivalent PCG generators
in the reference c++ source code have a _oneseq suffix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980349#comment-16980349 ] contextshuffling edited comment on LANG-1500 at 11/22/19 5:48 PM: -- [~ggregory] -In the change log, the description text seems to be incorrect (copied direct from the line above)- NVM, looks good to me! was (Author: contextshuffling): [~ggregory] In the change log, the description text seems to be incorrect (copied direct from the line above) > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] contextshuffling closed LANG-1500. -- LGTM > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16980349#comment-16980349 ] contextshuffling commented on LANG-1500: [~ggregory] In the change log, the description text seems to be incorrect (copied direct from the line above) > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?focusedWorklogId=348222&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-348222 ] ASF GitHub Bot logged work on LANG-1500: Author: ASF GitHub Bot Created on: 22/Nov/19 17:15 Start Date: 22/Nov/19 17:15 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 348222) Time Spent: 0.5h (was: 20m) > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1500. --- Fix Version/s: 3.10 Resolution: Fixed In git master, please verify and close. > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Fix For: 3.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] garydgregory merged pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api
garydgregory merged pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?focusedWorklogId=348215&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-348215 ] ASF GitHub Bot logged work on LANG-1500: Author: ASF GitHub Bot Created on: 22/Nov/19 16:51 Start Date: 22/Nov/19 16:51 Worklog Time Spent: 10m Work Description: coveralls commented on issue #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480#issuecomment-557607997 [](https://coveralls.io/builds/27179891) Coverage decreased (-0.01%) to 95.365% when pulling **d5d01c2191f4e2a801f07d0a37ffcba183071e25 on contextshuffling:test-inhance** into **1163e177137f5c57ce80092c0743209b28d33400 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 348215) Time Spent: 20m (was: 10m) > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls commented on issue #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api
coveralls commented on issue #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480#issuecomment-557607997 [](https://coveralls.io/builds/27179891) Coverage decreased (-0.01%) to 95.365% when pulling **d5d01c2191f4e2a801f07d0a37ffcba183071e25 on contextshuffling:test-inhance** into **1163e177137f5c57ce80092c0743209b28d33400 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Resolved] (MATH-1503) cumulativeProbability of LevyDistribution returns NaN for values out of domain, while others return 0
[
https://issues.apache.org/jira/browse/MATH-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski resolved MATH-1503.
---
Resolution: Won't Do
Thanks for the report. I made the change in the ["Commons Statistics"
project|http://commons.apache.org/proper/commons-statistics/] where the
distributions now belong (most of the package {{o.a.c.m.stat.distribution}} has
been moved there and will be removed from the next major version of Commons
Math).
You are most welcome to review and test the ported code.
> cumulativeProbability of LevyDistribution returns NaN for values out of
> domain, while others return 0
> -
>
> Key: MATH-1503
> URL: https://issues.apache.org/jira/browse/MATH-1503
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: WFR
>Priority: Minor
>
> LevyDistribution.cumulativeProbability returns Double.NaN for values that are
> outside of its domain (x < mu in this case), while GammaDistribution returns
> 0.0 (for x <= 0). Both cases are hard-coded.{color:#ffc66d}
> {color}
> A consistent behaviour would be desirable.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] contextshuffling updated LANG-1500: --- Description: Tests in _HashCodeBuilderTest_ depends on _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The order of fields being appended will affect the calculated HashCode. However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any specific order and thus, test can fail if the order is different, (i.e., it generates a different hash code). "The elements in the returned array are not sorted and are not in any particular order" (reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the order of fields returned by the api. was: Tests in _HashCodeBuilderTest_ depends on _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The order of fields being appended will affect the calculated HashCode. However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any specific order and thus, test can fail if the order is different, (i.e., it generates a different hash code). "The elements in the returned array are not sorted and are not in any particular order" (reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] This affects HashCodeBuilderTest.testReflectionHashCodeExcludeFields and HashCodeBuilderTest.testReflectionHierarchyHashCode as they depend on the order of fields returned by the api. > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects _HashCodeBuilderTest.testReflectionHashCodeExcludeFields_ and > _HashCodeBuilderTest.testReflectionHierarchyHashCode_ as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] contextshuffling updated LANG-1500: --- Description: Tests in _HashCodeBuilderTest_ depends on _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The order of fields being appended will affect the calculated HashCode. However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any specific order and thus, test can fail if the order is different, (i.e., it generates a different hash code). "The elements in the returned array are not sorted and are not in any particular order" (reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] This affects HashCodeBuilderTest.testReflectionHashCodeExcludeFields and HashCodeBuilderTest.testReflectionHierarchyHashCode as they depend on the order of fields returned by the api. was: Tests in ` HashCodeBuilderTest ` depends on `HashCodeBuilder.reflectionHashCode`. The logic of `reflectionHashCode` appends the fields returned by `java.lang.Class.getDeclaredFields`. The order of fields being appended will affect the calculated HashCode. However, `java.lang.Class.getDeclaredFields` does not guarantee any specific order and thus, test can fail if the order is different, (i.e., it generates a different hash code). "The elements in the returned array are not sorted and are not in any particular order" (reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Tests in _HashCodeBuilderTest_ depends on > _HashCodeBuilder.reflectionHashCode_. The logic of _reflectionHashCode_ > appends the fields returned by *_java.lang.Class.getDeclaredFields_*. The > order of fields being appended will affect the calculated HashCode. > However, _*java.lang.Class.getDeclaredFields*_ does not guarantee any > specific order and thus, test can fail if the order is different, (i.e., it > generates a different hash code). "The elements in the returned array are not > sorted and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > This affects HashCodeBuilderTest.testReflectionHashCodeExcludeFields and > HashCodeBuilderTest.testReflectionHierarchyHashCode as they depend on the > order of fields returned by the api. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
[ https://issues.apache.org/jira/browse/LANG-1500?focusedWorklogId=348204&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-348204 ] ASF GitHub Bot logged work on LANG-1500: Author: ASF GitHub Bot Created on: 22/Nov/19 16:16 Start Date: 22/Nov/19 16:16 Worklog Time Spent: 10m Work Description: contextshuffling commented on pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480 this fixes [LANG-1500](https://issues.apache.org/jira/projects/LANG/issues/LANG-1500) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 348204) Remaining Estimate: 0h Time Spent: 10m > Test may fail due to a different order of fields returned by reflection api > --- > > Key: LANG-1500 > URL: https://issues.apache.org/jira/browse/LANG-1500 > Project: Commons Lang > Issue Type: Bug > Components: lang.builder.* >Affects Versions: 3.8, 3.9, 3.8.1 >Reporter: contextshuffling >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Tests in ` HashCodeBuilderTest ` depends on > `HashCodeBuilder.reflectionHashCode`. The logic of `reflectionHashCode` > appends the fields returned by `java.lang.Class.getDeclaredFields`. The order > of fields being appended will affect the calculated HashCode. > However, `java.lang.Class.getDeclaredFields` does not guarantee any specific > order and thus, test can fail if the order is different, (i.e., it generates > a different hash code). "The elements in the returned array are not sorted > and are not in any particular order" (reference: > [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] contextshuffling opened a new pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api
contextshuffling opened a new pull request #480: LANG-1500 | Test may fail due to a different order of fields returned by reflection api URL: https://github.com/apache/commons-lang/pull/480 this fixes [LANG-1500](https://issues.apache.org/jira/projects/LANG/issues/LANG-1500) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (LANG-1500) Test may fail due to a different order of fields returned by reflection api
contextshuffling created LANG-1500: -- Summary: Test may fail due to a different order of fields returned by reflection api Key: LANG-1500 URL: https://issues.apache.org/jira/browse/LANG-1500 Project: Commons Lang Issue Type: Bug Components: lang.builder.* Affects Versions: 3.8.1, 3.9, 3.8 Reporter: contextshuffling Tests in ` HashCodeBuilderTest ` depends on `HashCodeBuilder.reflectionHashCode`. The logic of `reflectionHashCode` appends the fields returned by `java.lang.Class.getDeclaredFields`. The order of fields being appended will affect the calculated HashCode. However, `java.lang.Class.getDeclaredFields` does not guarantee any specific order and thus, test can fail if the order is different, (i.e., it generates a different hash code). "The elements in the returned array are not sorted and are not in any particular order" (reference: [https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--)|https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html#getDeclaredMethods--] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-410) jsvc fails to find OpenJDK11 libjvm.so on a raspberry 4 (buster)
[ https://issues.apache.org/jira/browse/DAEMON-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-410. Fix Version/s: 1.2.3 Resolution: Fixed Thanks for the patch. > jsvc fails to find OpenJDK11 libjvm.so on a raspberry 4 (buster) > > > Key: DAEMON-410 > URL: https://issues.apache.org/jira/browse/DAEMON-410 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.0.15 > Environment: Java version: > openjdk version "11.0.3" 2019-04-16 > OpenJDK Runtime Environment (build 11.0.3+7-post-Raspbian-5) > OpenJDK Server VM (build 11.0.3+7-post-Raspbian-5, mixed mode) > Java home: > /usr/lib/jvm/java-11-openjdk-armhf >Reporter: Jemine >Priority: Major > Fix For: 1.2.3 > > Attachments: location.patch > > > This is the log part of the JVM discovery: > Attempting to locate Java Home in /usr/lib/jvm/default-java > Attempting to locate VM configuration file > /usr/lib/jvm/default-java/jre/lib/jvm.cfg > Attempting to locate VM configuration file > /usr/lib/jvm/default-java/lib/jvm.cfg > Found VM configuration file at /usr/lib/jvm/default-java/lib/jvm.cfg > Found VM server definition in configuration > Checking library /usr/lib/jvm/default-java/jre/lib/arm/server/libjvm.so > Checking library /usr/lib/jvm/default-java/lib/arm/server/libjvm.so > Cannot locate library for VM server (skipping) > Found VM client definition in configuration > Checking library /usr/lib/jvm/default-java/jre/lib/arm/client/libjvm.so > Checking library /usr/lib/jvm/default-java/lib/arm/client/libjvm.so > Cannot locate library for VM client (skipping) > Found VM zero definition in configuration > Checking library /usr/lib/jvm/default-java/jre/lib/arm/zero/libjvm.so > Checking library /usr/lib/jvm/default-java/lib/arm/zero/libjvm.so > Cannot locate library for VM zero (skipping) > Java Home located in /usr/lib/jvm/default-java > +-- DUMPING JAVA HOME STRUCTURE > | Java Home: "/usr/lib/jvm/default-java" > | Java VM Config.: "/usr/lib/jvm/default-java/lib/jvm.cfg" > | Found JVMs: 0 > +--- > The real path is the following: > /usr/lib/jvm/default-java/lib/server/libjvm.so > Using Java 8 works fine: > openjdk version "1.8.0_212" > OpenJDK Runtime Environment (build 1.8.0_212-8u212-b01-1+rpi1-b01) > OpenJDK Client VM (build 25.212-b01, mixed mode) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (CLI-300) DefaultParser fails to parse token "-S=V" if short option is longer than 1 char
[
https://issues.apache.org/jira/browse/CLI-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balz Guenat updated CLI-300:
Description:
Assuming there is a short option with {{foo}} with one argument. Trying to
parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
The same scenario works fine if the short option is only one char long.
The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
(line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
option exists. IMO, this check should instead be {{isShortOption(opt)}}.
The below code demonstrates the issue.
{{Options options = new Options();}}
{{Option option = Option.builder("foo").hasArg().build();}}
{{options.addOption(option);}}
{{String[] args = new String[] \{"-foo=bar"};}}
{{DefaultParser parser = new DefaultParser();}}
{{CommandLine cmdLine = parser.parse(options, args);}}
{{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
was:
Assuming there is a short option with {{foo}} with one argument. Trying to
parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
The same scenario works fine if the short option is only one char long.
The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
(line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
option exists. IMO, this check should instead be {{isShortOption(opt)}}.
The below code demonstrates the issue.
Options options = new Options();
{{Option option = Option.builder("foo").hasArg().build();}}
{{options.addOption(option);}}
{{String[] args = new String[] \{"-foo=bar"};}}
DefaultParser parser = new DefaultParser();
{{CommandLine cmdLine = parser.parse(options, args);}}
{{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
> DefaultParser fails to parse token "-S=V" if short option is longer than 1
> char
> ---
>
> Key: CLI-300
> URL: https://issues.apache.org/jira/browse/CLI-300
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Windows 10, Java 11
>Reporter: Balz Guenat
>Priority: Major
>
> Assuming there is a short option with {{foo}} with one argument. Trying to
> parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
> The same scenario works fine if the short option is only one char long.
> The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
> (line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
> option exists. IMO, this check should instead be {{isShortOption(opt)}}.
> The below code demonstrates the issue.
> {{Options options = new Options();}}
> {{Option option = Option.builder("foo").hasArg().build();}}
> {{options.addOption(option);}}
> {{String[] args = new String[] \{"-foo=bar"};}}
> {{DefaultParser parser = new DefaultParser();}}
> {{CommandLine cmdLine = parser.parse(options, args);}}
> {{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (CLI-300) DefaultParser fails to parse token "-S=V" if short option is longer than 1 char
[
https://issues.apache.org/jira/browse/CLI-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Balz Guenat updated CLI-300:
Description:
Assuming there is a short option with {{foo}} with one argument. Trying to
parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
The same scenario works fine if the short option is only one char long.
The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
(line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
option exists. IMO, this check should instead be {{isShortOption(opt)}}.
The below code demonstrates the issue.
Options options = new Options();
{{Option option = Option.builder("foo").hasArg().build();}}
{{options.addOption(option);}}
{{String[] args = new String[] \{"-foo=bar"};}}
DefaultParser parser = new DefaultParser();
{{CommandLine cmdLine = parser.parse(options, args);}}
{{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
was:
Assuming there is a short option with {{foo}} with one argument. Trying to
parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
The same scenario works fine if the short option is only one char long.
The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
(line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
option exists. IMO, this check should instead be {{isShortOption(opt)}}.
The below code demonstrates the issue.
{{Options options = new Options();}}
{{ Option option = Option.builder("foo").hasArg().build();}}
{{ options.addOption(option);}}
{{String[] args = new String[] \{"-foo=bar"};}}
{{DefaultParser parser = new DefaultParser();}}
{{ CommandLine cmdLine = parser.parse(options, args);}}{{assertEquals("bar",
cmdLine.getOptionValue("foo"));}}
> DefaultParser fails to parse token "-S=V" if short option is longer than 1
> char
> ---
>
> Key: CLI-300
> URL: https://issues.apache.org/jira/browse/CLI-300
> Project: Commons CLI
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
> Environment: Windows 10, Java 11
>Reporter: Balz Guenat
>Priority: Major
>
> Assuming there is a short option with {{foo}} with one argument. Trying to
> parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
> The same scenario works fine if the short option is only one char long.
> The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
> (line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
> option exists. IMO, this check should instead be {{isShortOption(opt)}}.
> The below code demonstrates the issue.
> Options options = new Options();
> {{Option option = Option.builder("foo").hasArg().build();}}
> {{options.addOption(option);}}
> {{String[] args = new String[] \{"-foo=bar"};}}
> DefaultParser parser = new DefaultParser();
> {{CommandLine cmdLine = parser.parse(options, args);}}
> {{assertEquals("bar", cmdLine.getOptionValue("foo"));}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CLI-300) DefaultParser fails to parse token "-S=V" if short option is longer than 1 char
Balz Guenat created CLI-300:
---
Summary: DefaultParser fails to parse token "-S=V" if short option
is longer than 1 char
Key: CLI-300
URL: https://issues.apache.org/jira/browse/CLI-300
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.4
Environment: Windows 10, Java 11
Reporter: Balz Guenat
Assuming there is a short option with {{foo}} with one argument. Trying to
parse a token like {{-foo=bar}} results in an UnrecognizedOptionException.
The same scenario works fine if the short option is only one char long.
The reason is an if-statement in {{DefaultParser.handleShortAndLongOption()}}
(line 543 in v1.4), which checks {{opt.length() == 1}} before checking if the
option exists. IMO, this check should instead be {{isShortOption(opt)}}.
The below code demonstrates the issue.
{{Options options = new Options();}}
{{ Option option = Option.builder("foo").hasArg().build();}}
{{ options.addOption(option);}}
{{String[] args = new String[] \{"-foo=bar"};}}
{{DefaultParser parser = new DefaultParser();}}
{{ CommandLine cmdLine = parser.parse(options, args);}}{{assertEquals("bar",
cmdLine.getOptionValue("foo"));}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
