[jira] [Work logged] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238983&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238983
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 04:18
Start Date: 08/May/19 04:18
Worklog Time Spent: 10m
Work Description: cesartxt commented on issue #420: LANG-1453: using
toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490340797
Please, review the conversation of the pull request #340
It seems that using String#toUpperCase instead of String#toLowerCase doesn't
fix all the cases.
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: 238983)
Time Spent: 1h (was: 50m)
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 1h
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-lang] cesartxt edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
cesartxt edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490340797 Please, review the conversation of the pull request #340 It seems that using String#toUpperCase instead of String#toLowerCase doesn't fix all the cases. 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-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238982&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238982
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 04:16
Start Date: 08/May/19 04:16
Worklog Time Spent: 10m
Work Description: cesartxt commented on issue #420: LANG-1453: using
toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490340797
Please, review the conversation of the pull request #340
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: 238982)
Time Spent: 50m (was: 40m)
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 50m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-lang] cesartxt commented on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
cesartxt commented on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490340797 Please, review the conversation of the pull request #340 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-lang] coveralls edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
coveralls edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679 [](https://coveralls.io/builds/23249955) Coverage increased (+0.007%) to 95.396% when pulling **e510d425e18271019609a7495549875c5ade21ae on geratorres:LANG-1453-IdxOutBndsEx** into **6934228ded0aba917d253625aebd4efb10bbae97 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] [Work logged] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238923&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238923
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 00:59
Start Date: 08/May/19 00:59
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #420: LANG-1453: using
toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679
[](https://coveralls.io/builds/23249923)
Coverage increased (+0.007%) to 95.396% when pulling
**e510d425e18271019609a7495549875c5ade21ae on
geratorres:LANG-1453-IdxOutBndsEx** into
**6934228ded0aba917d253625aebd4efb10bbae97 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: 238923)
Time Spent: 0.5h (was: 20m)
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238924&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238924
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 01:01
Start Date: 08/May/19 01:01
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #420: LANG-1453: using
toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679
[](https://coveralls.io/builds/23249955)
Coverage increased (+0.007%) to 95.396% when pulling
**e510d425e18271019609a7495549875c5ade21ae on
geratorres:LANG-1453-IdxOutBndsEx** into
**6934228ded0aba917d253625aebd4efb10bbae97 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: 238924)
Time Spent: 40m (was: 0.5h)
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 40m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-lang] coveralls edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
coveralls edited a comment on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679 [](https://coveralls.io/builds/23249923) Coverage increased (+0.007%) to 95.396% when pulling **e510d425e18271019609a7495549875c5ade21ae on geratorres:LANG-1453-IdxOutBndsEx** into **6934228ded0aba917d253625aebd4efb10bbae97 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] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835223#comment-16835223
]
Rob Tompkins commented on LANG-1453:
There are some curiosities when dealing with Unicode characters that are
outside the standard UTF-8 character set. I’m working on a separate set of
UnicodeStringUtils due to the slow running nature of dealing with “surrogate
pairs.”
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-lang] coveralls commented on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
coveralls commented on issue #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679 [](https://coveralls.io/builds/23249560) Coverage increased (+0.007%) to 95.396% when pulling **49cf9d7c1894668025da0ca7ab00f442ba387e77 on geratorres:LANG-1453-IdxOutBndsEx** into **6934228ded0aba917d253625aebd4efb10bbae97 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] [Work logged] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238912&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238912
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 00:37
Start Date: 08/May/19 00:37
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #420: LANG-1453: using
toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420#issuecomment-490303679
[](https://coveralls.io/builds/23249560)
Coverage increased (+0.007%) to 95.396% when pulling
**49cf9d7c1894668025da0ca7ab00f442ba387e77 on
geratorres:LANG-1453-IdxOutBndsEx** into
**6934228ded0aba917d253625aebd4efb10bbae97 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: 238912)
Time Spent: 20m (was: 10m)
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835215#comment-16835215
]
Gerardo Torres Ontiveros commented on LANG-1453:
I figured out the cause of this bug and find a solution.
In StringUtils.replace the replacement process is performed based on the
indexes of the substrings on the lowercase version of the input strings. When
we have this String “İa” ([Dotted uppercase
“I”|https://en.wikipedia.org/wiki/Dotted_and_dotless_I] followed by an “a”) and
try to get the lowercase version of this String something weird occurs. As
dotted lowercase “I” doesn’t exist a lowercase “i” and a
[dot|https://en.wikipedia.org/wiki/Dot_(diacritic)] is returned (“i·a”). As you
noticed the input is 2 characters length and the output have 3 characters
length, so when the “a” is tried to be removed from the original string “İa”
the index of the “a” is taken as 2 as it is on the lowercase version “i·a” but
that index is out of the bounds of the original string and the exception is
thrown. Also, with these parameters StringUtils.removeIgnoreCase("İash", "a")
the exception won’t happen instead of, the next string will be returned “İah”
that is totally wrong because the length of the normal string and the lowercase
version are different.
This character “İ” is the only one from this list
[https://en.wikipedia.org/wiki/Dot_(diacritic)] that makes that the Strings
that contain this character causes that the toLowerCase method returns a string
with a bigger size but toUpperCase method returns a String with the same size.
I already send a pull request changing the following lines of the replace
method:
From:
if (ignoreCase) {
searchText = text.toLowerCase();
searchString = searchString.toLowerCase();
}
To:
if (ignoreCase) {
searchText = text.toUpperCase();
searchString = searchString.toUpperCase();
}
I had some problems adding the test, this character “İ” was uploaded as a
question mark, I asked for help in a GitHub comment on the commit.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835215#comment-16835215
]
Gerardo Torres Ontiveros edited comment on LANG-1453 at 5/8/19 12:31 AM:
-
I figured out the cause of this bug and found a solution.
In StringUtils.replace the replacement process is performed based on the
indexes of the substrings on the lowercase version of the input strings. When
we have this String “İa” ([Dotted uppercase
“I”|https://en.wikipedia.org/wiki/Dotted_and_dotless_I] followed by an “a”) and
try to get the lowercase version of this String something weird occurs. As
dotted lowercase “I” doesn’t exist a lowercase “i” and a
[dot|https://en.wikipedia.org/wiki/Dot_(diacritic)] is returned (“i·a”). As you
noticed the input is 2 characters length and the output have 3 characters
length, so when the “a” is tried to be removed from the original string “İa”
the index of the “a” is taken as 2 as it is on the lowercase version “i·a” but
that index is out of the bounds of the original string and the exception is
thrown. Also, with these parameters StringUtils.removeIgnoreCase("İash", "a")
the exception won’t happen instead of, the next string will be returned “İah”
that is totally wrong because the length of the normal string and the lowercase
version are different.
This character “İ” is the only one from this list
[https://en.wikipedia.org/wiki/Dot_(diacritic)] that makes that the Strings
that contain this character causes that the toLowerCase method returns a string
with a bigger size but toUpperCase method returns a String with the same size.
I already send a pull request changing the following lines of the replace
method:
From:
if (ignoreCase)
{ searchText = text.toLowerCase(); searchString =
searchString.toLowerCase(); }
To:
if (ignoreCase)
{ searchText = text.toUpperCase(); searchString =
searchString.toUpperCase(); }
I had some problems adding the test, this character “İ” was uploaded as a
question mark, I asked for help in a GitHub comment on the commit.
was (Author: gtorres):
I figured out the cause of this bug and find a solution.
In StringUtils.replace the replacement process is performed based on the
indexes of the substrings on the lowercase version of the input strings. When
we have this String “İa” ([Dotted uppercase
“I”|https://en.wikipedia.org/wiki/Dotted_and_dotless_I] followed by an “a”) and
try to get the lowercase version of this String something weird occurs. As
dotted lowercase “I” doesn’t exist a lowercase “i” and a
[dot|https://en.wikipedia.org/wiki/Dot_(diacritic)] is returned (“i·a”). As you
noticed the input is 2 characters length and the output have 3 characters
length, so when the “a” is tried to be removed from the original string “İa”
the index of the “a” is taken as 2 as it is on the lowercase version “i·a” but
that index is out of the bounds of the original string and the exception is
thrown. Also, with these parameters StringUtils.removeIgnoreCase("İash", "a")
the exception won’t happen instead of, the next string will be returned “İah”
that is totally wrong because the length of the normal string and the lowercase
version are different.
This character “İ” is the only one from this list
[https://en.wikipedia.org/wiki/Dot_(diacritic)] that makes that the Strings
that contain this character causes that the toLowerCase method returns a string
with a bigger size but toUpperCase method returns a String with the same size.
I already send a pull request changing the following lines of the replace
method:
From:
if (ignoreCase) {
searchText = text.toLowerCase();
searchString = searchString.toLowerCase();
}
To:
if (ignoreCase) {
searchText = text.toUpperCase();
searchString = searchString.toUpperCase();
}
I had some problems adding the test, this character “İ” was uploaded as a
question mark, I asked for help in a GitHub comment on the commit.
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (LANG-1453) StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LANG-1453?focusedWorklogId=238908&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238908
]
ASF GitHub Bot logged work on LANG-1453:
Author: ASF GitHub Bot
Created on: 08/May/19 00:28
Start Date: 08/May/19 00:28
Worklog Time Spent: 10m
Work Description: geratorres commented on pull request #420: LANG-1453:
using toUpperCase instead of toLowerCase solve the problem
URL: https://github.com/apache/commons-lang/pull/420
I changed the using of toLowerCase to toUpperCase on replace function on
StringUtils. more detailed info is in a comment on Jira
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: 238908)
Time Spent: 10m
Remaining Estimate: 0h
> StringUtils.removeIgnoreCase("İa", "a") throws IndexOutOfBoundsException
>
>
> Key: LANG-1453
> URL: https://issues.apache.org/jira/browse/LANG-1453
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.text.*
>Affects Versions: 3.8.1
>Reporter: Thomas Neerup
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *try* {
> String s = StringUtils._removeIgnoreCase_("İa", "a");
> } *catch* (Exception e) {
> e.printStackTrace();
> }
> output
> java.lang.IndexOutOfBoundsException: start 3, end 2, s.length() 2
> at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:539)
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-lang] geratorres opened a new pull request #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem
geratorres opened a new pull request #420: LANG-1453: using toUpperCase instead of toLowerCase solve the problem URL: https://github.com/apache/commons-lang/pull/420 I changed the using of toLowerCase to toUpperCase on replace function on StringUtils. more detailed info is in a comment on Jira 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-statistics] ericbarnhill commented on a change in pull request #4: A small Mode function
ericbarnhill commented on a change in pull request #4: A small Mode function
URL: https://github.com/apache/commons-statistics/pull/4#discussion_r281865803
##
File path:
commons-statistics-distribution/src/main/java/org/apache/commons/statistics/distribution/CauchyDistribution.java
##
@@ -65,7 +62,7 @@ public double getMedian() {
* @return the mode for this distribution.
*/
public double getMode() {
-return mode;
+return getMedian();
Review comment:
Looks good. You may also want to add a statement in the doc that the mode is
the same as the median for this distribution.
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] (MATH-1481) Update Sobol dimension
[ https://issues.apache.org/jira/browse/MATH-1481?focusedWorklogId=238809&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238809 ] ASF GitHub Bot logged work on MATH-1481: Author: ASF GitHub Bot Created on: 07/May/19 21:15 Start Date: 07/May/19 21:15 Worklog Time Spent: 10m Work Description: asfgit commented on pull request #105: improvement-MATH-1481 Sobol dimension extension URL: https://github.com/apache/commons-math/pull/105 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: 238809) Time Spent: 10m Remaining Estimate: 20m (was: 0.5h) > Update Sobol dimension > -- > > Key: MATH-1481 > URL: https://issues.apache.org/jira/browse/MATH-1481 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Charmont >Priority: Minor > Labels: pull-request-available > Original Estimate: 0.5h > Time Spent: 10m > Remaining Estimate: 20m > > Use the last file of [https://web.maths.unsw.edu.au/~fkuo/sobol/] to increase > the Sobol dimension. Easy update : copy/paste file and update dimension from > 1000 to 21201. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-math] asfgit merged pull request #105: improvement-MATH-1481 Sobol dimension extension
asfgit merged pull request #105: improvement-MATH-1481 Sobol dimension extension URL: https://github.com/apache/commons-math/pull/105 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-1481) Update Sobol dimension
[ https://issues.apache.org/jira/browse/MATH-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1481. -- Resolution: Done Fix Version/s: 4.0 commit 5de563e6c764add5980c63310c1df43db2bbdb38 > Update Sobol dimension > -- > > Key: MATH-1481 > URL: https://issues.apache.org/jira/browse/MATH-1481 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Charmont >Priority: Minor > Labels: pull-request-available > Fix For: 4.0 > > Original Estimate: 0.5h > Time Spent: 10m > Remaining Estimate: 20m > > Use the last file of [https://web.maths.unsw.edu.au/~fkuo/sobol/] to increase > the Sobol dimension. Easy update : copy/paste file and update dimension from > 1000 to 21201. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835119#comment-16835119
]
Mark Thomas commented on DAEMON-398:
Assuming I am reading the Mercurial logs correctly, there were no native code
changes for either the shared or Windows code between Java 11.0.2 and 11.0.3.
It looks like I'm going to need to set up a Windows built environment for Java
11.
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> #
> {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16)
> and test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime
> library (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
> ||OS||Daemon version (built with)||Java vendor and version (built
> with)||Result||
> |Windows 7|1.1.x HEAD (9.00)|AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2008R2 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2012R2|1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.2+9 (12.00)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|Fail|
> Note: It is assumed the OS is fully patched unless otherwise stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMPRESS-485) Reproducible Builds: keep entries order when gathering ParallelScatterZipCreator
[ https://issues.apache.org/jira/browse/COMPRESS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835085#comment-16835085 ] Hervé Boutemy commented on COMPRESS-485: sure, done :) > Reproducible Builds: keep entries order when gathering > ParallelScatterZipCreator > > > Key: COMPRESS-485 > URL: https://issues.apache.org/jira/browse/COMPRESS-485 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Hervé Boutemy >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > currently, zip files created using ParallelScatterZipCreator have random > order. > This is causing issues when trying to do Reproducible Builds with Maven > MNG-6276 > Studying ParallelScatterZipCreator, entries are kept sorted in memory in > futures list: instead of writing each full scatter in sequence, iterating > over futures should permit to write each zip entry in original order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (COMPRESS-485) Reproducible Builds: keep entries order when gathering ParallelScatterZipCreator
[ https://issues.apache.org/jira/browse/COMPRESS-485?focusedWorklogId=238783&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-238783 ] ASF GitHub Bot logged work on COMPRESS-485: --- Author: ASF GitHub Bot Created on: 07/May/19 20:31 Start Date: 07/May/19 20:31 Worklog Time Spent: 10m Work Description: coveralls commented on issue #78: COMPRESS-485 keep zip entries order in parallel zip creation URL: https://github.com/apache/commons-compress/pull/78#issuecomment-489726010 [](https://coveralls.io/builds/23245578) Coverage increased (+0.07%) to 86.598% when pulling **b3a1b0aaa377c51439da93953f9b58f6f5b05eb8 on hboutemy:COMPRESS-485** into **e127b13c58117a2e26639f5f83b785180ef8cfa2 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: 238783) Time Spent: 50m (was: 40m) > Reproducible Builds: keep entries order when gathering > ParallelScatterZipCreator > > > Key: COMPRESS-485 > URL: https://issues.apache.org/jira/browse/COMPRESS-485 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.18 >Reporter: Hervé Boutemy >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > currently, zip files created using ParallelScatterZipCreator have random > order. > This is causing issues when trying to do Reproducible Builds with Maven > MNG-6276 > Studying ParallelScatterZipCreator, entries are kept sorted in memory in > futures list: instead of writing each full scatter in sequence, iterating > over futures should permit to write each zip entry in original order -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-compress] coveralls edited a comment on issue #78: COMPRESS-485 keep zip entries order in parallel zip creation
coveralls edited a comment on issue #78: COMPRESS-485 keep zip entries order in parallel zip creation URL: https://github.com/apache/commons-compress/pull/78#issuecomment-489726010 [](https://coveralls.io/builds/23245578) Coverage increased (+0.07%) to 86.598% when pulling **b3a1b0aaa377c51439da93953f9b58f6f5b05eb8 on hboutemy:COMPRESS-485** into **e127b13c58117a2e26639f5f83b785180ef8cfa2 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] coveralls edited a comment on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler
coveralls edited a comment on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler URL: https://github.com/apache/commons-rng/pull/40#issuecomment-490160810 [](https://coveralls.io/builds/23241979) Coverage increased (+0.01%) to 98.487% when pulling **5d41c69f5d28b9301e3672f67e3269e2af08e79e on aherbert:feature-RNG-91** into **44f7b628bc1ae426740a37199b984893c45068e4 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] coveralls edited a comment on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler
coveralls edited a comment on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler URL: https://github.com/apache/commons-rng/pull/40#issuecomment-490160810 [](https://coveralls.io/builds/23241979) Coverage increased (+0.01%) to 98.487% when pulling **5d41c69f5d28b9301e3672f67e3269e2af08e79e on aherbert:feature-RNG-91** into **44f7b628bc1ae426740a37199b984893c45068e4 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] [Closed] (VFS-713) Add FileObjectUtils.readProperties(FileObject) method to read a .properties file.
[
https://issues.apache.org/jira/browse/VFS-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-713.
Resolution: Fixed
In git master.
> Add FileObjectUtils.readProperties(FileObject) method to read a .properties
> file.
> -
>
> Key: VFS-713
> URL: https://issues.apache.org/jira/browse/VFS-713
> Project: Commons VFS
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Add:
> - org.apache.commons.vfs2.util.FileObjectUtils.readProperties(FileObject)
> - org.apache.commons.vfs2.util.FileObjectUtils.readProperties(FileObject,
> Properties)
> As:
> {code:java}
> /**
> * Reads the given file into a new {@link Properties}.
> *
> * @param fileObject the file to read
> * @return a new {@link Properties}.
> * @throws IOException
> * @throws FileSystemException On error getting this file's content.
> * @throws IOException On error getting this file's content.
> * @since 2.4
> */
> public static Properties readProperties(final FileObject fileObject)
> throws FileSystemException, IOException {
> return readProperties(fileObject, new Properties());
> }
> /**
> * Reads the given file into a new given {@link Properties}.
> *
> * @param fileObject the file to read
> * @param properties the destination
> * @return a new {@link Properties}.
> * @throws FileSystemException On error getting this file's content.
> * @throws IOException On error getting this file's content.
> * @since 2.4
> */
> public static Properties readProperties(final FileObject fileObject,
> final Properties properties)
> throws FileSystemException, IOException {
> if (fileObject == null) {
> return properties;
> }
> try (InputStream inputStream =
> fileObject.getContent().getInputStream()) {
> properties.load(inputStream);
> }
> return properties;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-713) Add FileObjectUtils.readProperties(FileObject) method to read a .properties file.
Gary Gregory created VFS-713:
Summary: Add FileObjectUtils.readProperties(FileObject) method to
read a .properties file.
Key: VFS-713
URL: https://issues.apache.org/jira/browse/VFS-713
Project: Commons VFS
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.4
Add:
- org.apache.commons.vfs2.util.FileObjectUtils.readProperties(FileObject)
- org.apache.commons.vfs2.util.FileObjectUtils.readProperties(FileObject,
Properties)
As:
{code:java}
/**
* Reads the given file into a new {@link Properties}.
*
* @param fileObject the file to read
* @return a new {@link Properties}.
* @throws IOException
* @throws FileSystemException On error getting this file's content.
* @throws IOException On error getting this file's content.
* @since 2.4
*/
public static Properties readProperties(final FileObject fileObject) throws
FileSystemException, IOException {
return readProperties(fileObject, new Properties());
}
/**
* Reads the given file into a new given {@link Properties}.
*
* @param fileObject the file to read
* @param properties the destination
* @return a new {@link Properties}.
* @throws FileSystemException On error getting this file's content.
* @throws IOException On error getting this file's content.
* @since 2.4
*/
public static Properties readProperties(final FileObject fileObject, final
Properties properties)
throws FileSystemException, IOException {
if (fileObject == null) {
return properties;
}
try (InputStream inputStream =
fileObject.getContent().getInputStream()) {
properties.load(inputStream);
}
return properties;
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] coveralls commented on issue #41: RNG-101: Add MarsagliaTsangWang discrete probability sampler.
coveralls commented on issue #41: RNG-101: Add MarsagliaTsangWang discrete probability sampler. URL: https://github.com/apache/commons-rng/pull/41#issuecomment-490168940 [](https://coveralls.io/builds/23241219) Coverage increased (+0.1%) to 98.602% when pulling **bae7ba114c484db0617882c57863351c4f9eec4a on aherbert:feature-RNG-101** into **44f7b628bc1ae426740a37199b984893c45068e4 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] [Closed] (VFS-712) Add null-safe org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)
[
https://issues.apache.org/jira/browse/VFS-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-712.
Resolution: Fixed
In git master.
> Add null-safe org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)
> -
>
> Key: VFS-712
> URL: https://issues.apache.org/jira/browse/VFS-712
> Project: Commons VFS
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.4
>
>
> Add null-safe
> \{{org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)}}:
> {code:java}
> /**
> * Null-safe call to {@link FileObject#exists()}.
> *
> * @param fileObject
> * @return false if {@code fileObject} is null, otherwise, see {@link
> FileObject#exists()}.
> * @throws FileSystemException On error determining if this file exists.
> */
> public static boolean exists(final FileObject fileObject) throws
> FileSystemException {
> return fileObject != null && fileObject.exists();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (VFS-712) Add null-safe org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)
Gary Gregory created VFS-712:
Summary: Add null-safe
org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)
Key: VFS-712
URL: https://issues.apache.org/jira/browse/VFS-712
Project: Commons VFS
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 2.4
Add null-safe
\{{org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObject)}}:
{code:java}
/**
* Null-safe call to {@link FileObject#exists()}.
*
* @param fileObject
* @return false if {@code fileObject} is null, otherwise, see {@link
FileObject#exists()}.
* @throws FileSystemException On error determining if this file exists.
*/
public static boolean exists(final FileObject fileObject) throws
FileSystemException {
return fileObject != null && fileObject.exists();
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] coveralls commented on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler
coveralls commented on issue #40: RNG-91: Added a KempSmallMeanPoissonSampler URL: https://github.com/apache/commons-rng/pull/40#issuecomment-490160810 [](https://coveralls.io/builds/23240712) Coverage decreased (-0.03%) to 98.44% when pulling **b68f53cd3e85c309b69824d743a242898b4d5b79 on aherbert:feature-RNG-91** into **73e8065f5c6cf7db571d93d29f9d1d92bd02ab07 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 #41: RNG-101: Add MarsagliaTsangWang discrete probability sampler.
aherbert opened a new pull request #41: RNG-101: Add MarsagliaTsangWang discrete probability sampler. URL: https://github.com/apache/commons-rng/pull/41 This adds support for a generic distribution defined by an array of probabilities and also a Poisson and Binomial distribution. 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] [Commented] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834934#comment-16834934
]
Mark Thomas commented on DAEMON-398:
Looking at the table, I think we have enough info already in terms of
combinations. There appears to be both an OS and compiler component to this.
There error message for the combination that fails in the main daemon log is:
"CreateJavaVM Failed", "The system cannot find the file specified.". I'd like
to dig into that second message a little more to see exactly which file cannot
be found.
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> #
> {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16)
> and test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime
> library (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
> ||OS||Daemon version (built with)||Java vendor and version (built
> with)||Result||
> |Windows 7|1.1.x HEAD (9.00)|AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2008R2 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2012R2|1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.2+9 (12.00)|OK|
> |Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|Fail|
> Note: It is assumed the OS is fully patched unless otherwise stated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-398:
---
Description:
*Steps to reproduce*
# Install Java 11
# Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
# Using prunmgr, add a Java Option '-invalid'
# Start the service
# stdout and stderr files are empty!
# Install Java 10
# Using prunmgr, switch the Java Virtual Machine to Java 10
# Start the service
#
{code:none|title=stderr}
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support
was removed in 8.0
Unrecognized option: -invalid
{code}
*Analysis*
* It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
* I followed this guide: [Redirecting standard I/O from within a
program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
[^set-stdout.patch]), but it didn't help.
* Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
test with Java 13-ea, which is also compiled with the same version (hence using
the same C-runtime library) it does not work.
* The guide ends with what the probably causing the issue:
{quote}... the one problem that remains with redirecting Win32 file handles:
It doesn't affect anything in the program using a different C runtime library
(such as a third-party DLL, for example).
{quote}
* Setting registry value Log/LogJniMessages=1, which is using the {{vfprintf}}
option of the
[JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
does not help. Maybe because is is added after the user-specified Java Options?
*Ideas*
# Make {{vfprintf}} the first parameter
Downside of {{vfprintf}} is that it is hard to distinct between stdout and
stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
# Log a bug for OpenJDK and try to get it fixed.
||OS||Daemon version (built with)||Java vendor and version (built
with)||Result||
|Windows 7|1.1.x HEAD (9.00)|AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2008R2 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2012R2|1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|OK|
|Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.2+9 (12.00)|OK|
|Windows 2016 |1.1.x HEAD (9.00) |AdoptOpenJDK 11.0.3+7 (14.15)|Fail|
Note: It is assumed the OS is fully patched unless otherwise stated.
was:
*Steps to reproduce*
# Install Java 11
# Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
# Using prunmgr, add a Java Option '-invalid'
# Start the service
# stdout and stderr files are empty!
# Install Java 10
# Using prunmgr, switch the Java Virtual Machine to Java 10
# Start the service
# {code:none|title=stderr}
Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize; support
was removed in 8.0
Unrecognized option: -invalid
{code}
*Analysis*
* It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
* I followed this guide: [Redirecting standard I/O from within a
program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
[^set-stdout.patch]), but it didn't help.
* Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
test with Java 13-ea, which is also compiled with the same version (hence using
the same C-runtime library) it does not work.
* The guide ends with what the probably causing the issue:
{quote}
... the one problem that remains with redirecting Win32 file handles:
It doesn't affect anything in the program using a different C runtime library
(such as a third-party DLL, for example).
{quote}
* Setting registry value Log/LogJniMessages=1, which is using the {{vfprintf}}
option of the
[JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
does not help. Maybe because is is added after the user-specified Java Options?
*Ideas*
# Make {{vfprintf}} the first parameter
Downside of {{vfprintf}} is that it is hard to distinct between stdout and
stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
# Log a bug for OpenJDK and try to get it fixed.
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Repor
[GitHub] [commons-rng] aherbert opened a new pull request #40: RNG-91: Added a KempSmallMeanPoissonSampler
aherbert opened a new pull request #40: RNG-91: Added a KempSmallMeanPoissonSampler URL: https://github.com/apache/commons-rng/pull/40 Add a benchmark to the JMH examples of various methods to compute a Poisson sample. This sampler is suitable for use an alternative to the SmallMeanPoissonSampler when the generator is slow. Speed at mean <1 is comparable. At mean in the range 1-40 a slow generator would favour this method, a fast generator would favour the SmallMeanPoissonSampler. 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] [Commented] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834893#comment-16834893
]
Mark Thomas commented on DAEMON-398:
I was using Windows 7.
I think it would be useful to add a table to the issue description to track
which combinations work and which do not. That should help us track down
exactly where the problem lies. I'll get something set-up. Help populating it
would be much appreciated. I'm not looking to populate all possible
combinations - just enough to figure out where we should be looking for a root
cause.
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (MATH-1481) Update Sobol dimension
Charmont created MATH-1481: -- Summary: Update Sobol dimension Key: MATH-1481 URL: https://issues.apache.org/jira/browse/MATH-1481 Project: Commons Math Issue Type: Improvement Affects Versions: 3.6.1 Reporter: Charmont Use the last file of [https://web.maths.unsw.edu.au/~fkuo/sobol/] to increase the Sobol dimension. Easy update : copy/paste file and update dimension from 1000 to 21201. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-math] tcharmont commented on a change in pull request #105: Extend the Sobol generator sequence dimension
tcharmont commented on a change in pull request #105: Extend the Sobol generator sequence dimension URL: https://github.com/apache/commons-math/pull/105#discussion_r281676503 ## File path: src/main/java/org/apache/commons/math4/random/SobolSequenceGenerator.java ## @@ -62,10 +62,10 @@ private static final double SCALE = FastMath.pow(2, BITS); /** The maximum supported space dimension. */ -private static final int MAX_DIMENSION = 1000; +private static final int MAX_DIMENSION = 21201; Review comment: Done :) 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] [Commented] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834830#comment-16834830
]
Gerwin commented on DAEMON-398:
---
{code:none}
C:\>dumpbin /headers "c:\Program Files\TomEE\bin\TomEE.amd64.exe"
OPTIONAL HEADER VALUES
9.00 linker version
{code}
Mine is compiled with VS2008.
To be complete, I downloaded
[commons-daemon-1.1.0-bin-windows.zip|http://apache.40b.nl//commons/daemon/binaries/windows/commons-daemon-1.1.0-bin-windows.zip]
and extracted amd64/prunsrv.exe to TomEE.amd64.exe and tried again: still
fails, no error message in std files.
And it is compiled with same VS2008.
But I have some more information: I can only reproduce this on Windows 2016 /
Windows 10. Not on Windows 2008R2 or Windows 2012R2.
Which version are you using?
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-396) LibraryPath is broken for Java 11
[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834802#comment-16834802
]
Mark Thomas commented on DAEMON-396:
My testing was with AdoptOpenJDK 11.0.3+7 where this issue is not reproducible
when using a Commons Daemon binary built with the release build environment
(which is essentially the same as the one used for the Tomcat native
components:
https://cwiki.apache.org/confluence/display/TOMCAT/Common+Native+Build+Environment)
It looks like the issue is that the Commons Daemon being testing is being built
with a later version of Visual Studio than intended. The build tools we use for
Commons Daemon might be rather on the old side but they are deliberately chosen
to avoid issues like this.
Tomcat is not distributing the dependencies. Tomcat is using the official
Commons Daemon Windows binaries that do not require them.
> LibraryPath is broken for Java 11
> -
>
> Key: DAEMON-396
> URL: https://issues.apache.org/jira/browse/DAEMON-396
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.0
>Reporter: Gerwin
>Priority: Critical
> Fix For: 1.1.1
>
> Attachments: JAVA_HOME-bin-to-PATH.patch, apxAddToPathW.patch
>
>
> My application which runs on TomEE is broken when running on Java 11. I'm
> getting this error:
> {code:none}
> java.lang.UnsatisfiedLinkError: no xmlForJava in java.library.path:
> [C:\Program Files\TomEE\bin, <>, .]
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
> at java.base/java.lang.System.loadLibrary(System.java:1867)
> {code}
> It works for Java 8 and 10, but fails for both Oracle JDK 11 and OpenJDK 11.
> The application installs the service with the {{--LibraryPath}} option and
> {{--StartMode jvm}}. When inspecting the {{java.library.path}} using JMX, I
> observe this:
> # With Java 8 {{java.library.path}} contains the value specified in the
> LibraryPath
> # With Java 11 {{java.library.path}} contains the value of the PATH
> environment variable
> From the sourcecode I see that procrun is executing code in this order:
> {code:none}
> _wputenv("PATH=;C:\\application\\lib");
> LoadLibraryW("jvm.dll")
> JNI_CreateJavaVM()
> SetDllDirectoryW(";C:\\application\\lib")
> {code}
> The JVM is supposed to take the value of the PATH variable into account when
> loaded, but it doesn't.
> I found these articles:
> * Stackoverflow: [Program uses outdated (not current) env variable
> value|https://stackoverflow.com/questions/9634905/program-uses-outdated-not-current-env-variable-value]
> * Microsoft Docs: [Potential Errors Passing CRT Objects Across DLL
> Boundaries#This example passes environment variables across a DLL
> boundary|https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2017#example-1]
> So the C-Runtime library has its own copy of the environment variables and
> behavior depends on how the binaries are compiled.
> * /MD means they share a single copy of the C-Runtime library.
> * /MT means that they use separate copies of the C-Runtime library.
> I expect that Java 11 is build differently, which causes this bug.
> Give this quote...
> {quote}
> Normally when Java is launched and a library path is not specified, the JVM
> will default to using the system PATH on Windows and the LD_LIBRARY_PATH on
> UNIX systems to locate any native libraries loaded by the application. This
> is akin to what happens with the CLASSPATH environment variable when a
> specific classpath is not specified when launching the JVM. The use of the
> CLASSPATH environment variable has fallen out of style because of all the
> conflict problems which can arise when multiple Java applications are
> installed on the same machine. The same issues are all there with the library
> path as well.
> In general, it is advised that you avoid potential problems when your
> application is deployed by being conservative about which directories will be
> included in the Java library path.
> https://wrapper.tanukisoftware.com/doc/english/prop-java-library-path-append-system-path.html
> {quote}
> .. I think it would be better to change the implementation of
> {{--LibraryPath}} to set the JVM option {{-Djava.library.path}} instead of
> the PATH env var.
> This will make procrun independent of how the jvm.dll is build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (DAEMON-398) Java 11 jvm.dll startup messages not available on stdout/stderr when compiling with newer Visual Studio
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-398:
---
Issue Type: Improvement (was: Bug)
Summary: Java 11 jvm.dll startup messages not available on stdout/stderr
when compiling with newer Visual Studio (was: Java 11 jvm.dll startup error
messages not available on stdout/stderr)
> Java 11 jvm.dll startup messages not available on stdout/stderr when
> compiling with newer Visual Studio
> ---
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Improvement
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-398) Java 11 jvm.dll startup error messages not available on stdout/stderr
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834792#comment-16834792
]
Mark Thomas commented on DAEMON-398:
My testing was with AdoptOpenJDK 11.0.3+7 where this issue is not reproducible.
It looks like the issue is that the Commons Daemon being testing is being built
with a later version of Visual Studio than intended. The build tools we use for
Commons Daemon might be rather on the old side but they are deliberately chosen
to avoid issues like this.
A patch that enables this to work when compiling with a later version of Visual
Studio would certainly be accepted. That would fall under an enhancement rather
than a bug so I'll adjust this issue accordingly.
> Java 11 jvm.dll startup error messages not available on stdout/stderr
> -
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DAEMON-396) LibraryPath is broken for Java 11
[
https://issues.apache.org/jira/browse/DAEMON-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834786#comment-16834786
]
Gerwin commented on DAEMON-396:
---
bq. I have tested with the latest release (1.1.0) and I am unable to recreate
the first of the issues. java.library.path is correctly set with both Java 8
and Java 11.
Which JDK binaries did you use? I just figured out that AdoptOpenJDK 11.0.2 is
compiled with VS2013, and that will work.
But Oracle binaries (both openjdk.java.net and commercial) and AdoptOpenJDK
11.0.3 are compiled with VS2017. And then it is broken.
bq. I'm not a fan of the solution to the first problem as it tends (always?)
adds a dependency on one of the .Net runtimes which aren't always installed.
Alternative is to redistribute the dependencies (e.g. msvcp140.dll) with
commons-daemon. Tomcat and OpenJDK are doing this too.
> LibraryPath is broken for Java 11
> -
>
> Key: DAEMON-396
> URL: https://issues.apache.org/jira/browse/DAEMON-396
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.0
>Reporter: Gerwin
>Priority: Critical
> Fix For: 1.1.1
>
> Attachments: JAVA_HOME-bin-to-PATH.patch, apxAddToPathW.patch
>
>
> My application which runs on TomEE is broken when running on Java 11. I'm
> getting this error:
> {code:none}
> java.lang.UnsatisfiedLinkError: no xmlForJava in java.library.path:
> [C:\Program Files\TomEE\bin, <>, .]
> at
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2660)
> at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:829)
> at java.base/java.lang.System.loadLibrary(System.java:1867)
> {code}
> It works for Java 8 and 10, but fails for both Oracle JDK 11 and OpenJDK 11.
> The application installs the service with the {{--LibraryPath}} option and
> {{--StartMode jvm}}. When inspecting the {{java.library.path}} using JMX, I
> observe this:
> # With Java 8 {{java.library.path}} contains the value specified in the
> LibraryPath
> # With Java 11 {{java.library.path}} contains the value of the PATH
> environment variable
> From the sourcecode I see that procrun is executing code in this order:
> {code:none}
> _wputenv("PATH=;C:\\application\\lib");
> LoadLibraryW("jvm.dll")
> JNI_CreateJavaVM()
> SetDllDirectoryW(";C:\\application\\lib")
> {code}
> The JVM is supposed to take the value of the PATH variable into account when
> loaded, but it doesn't.
> I found these articles:
> * Stackoverflow: [Program uses outdated (not current) env variable
> value|https://stackoverflow.com/questions/9634905/program-uses-outdated-not-current-env-variable-value]
> * Microsoft Docs: [Potential Errors Passing CRT Objects Across DLL
> Boundaries#This example passes environment variables across a DLL
> boundary|https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2017#example-1]
> So the C-Runtime library has its own copy of the environment variables and
> behavior depends on how the binaries are compiled.
> * /MD means they share a single copy of the C-Runtime library.
> * /MT means that they use separate copies of the C-Runtime library.
> I expect that Java 11 is build differently, which causes this bug.
> Give this quote...
> {quote}
> Normally when Java is launched and a library path is not specified, the JVM
> will default to using the system PATH on Windows and the LD_LIBRARY_PATH on
> UNIX systems to locate any native libraries loaded by the application. This
> is akin to what happens with the CLASSPATH environment variable when a
> specific classpath is not specified when launching the JVM. The use of the
> CLASSPATH environment variable has fallen out of style because of all the
> conflict problems which can arise when multiple Java applications are
> installed on the same machine. The same issues are all there with the library
> path as well.
> In general, it is advised that you avoid potential problems when your
> application is deployed by being conservative about which directories will be
> included in the Java library path.
> https://wrapper.tanukisoftware.com/doc/english/prop-java-library-path-append-system-path.html
> {quote}
> .. I think it would be better to change the implementation of
> {{--LibraryPath}} to set the JVM option {{-Djava.library.path}} instead of
> the PATH env var.
> This will make procrun independent of how the jvm.dll is build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (DAEMON-398) Java 11 jvm.dll startup error messages not available on stdout/stderr
[
https://issues.apache.org/jira/browse/DAEMON-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gerwin reopened DAEMON-398:
---
I tried with [AdoptOpenJDK
11.0.2+9|https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmVariant=hotspot]
and there it works fine.
{code:none}
C:\>dumpbin /headers "c:\Program
Files\Java\adoptopenjdk11.0.2_9\bin\server\jvm.dll"
Microsoft (R) COFF/PE Dumper Version 14.16.27027.1
Copyright (C) Microsoft Corporation. All rights reserved.
OPTIONAL HEADER VALUES
12.00 linker version
{code}
It is compiled with Visual Studio 2013
([ref|http://mariusbancila.ro/blog/2015/08/12/version-history-of-vc-mfc-and-atl/]).
I tried with [AdoptOpenJDK
11.0.3+7|https://adoptopenjdk.net/archive.html?variant=openjdk11&jvmVariant=hotspot]
and there it is broken again.
{code:none}
C:\>dumpbin /headers "C:\Program
Files\Java\adoptopenjdk11.0.3_7\bin\server\jvm.dll"
OPTIONAL HEADER VALUES
14.15 linker version
{code}
They seem to have upgraded their build environment, because this is compiled
with Visual Studio 2017 15.8.
Apart from that, Oracle JDK 11 (both openjdk.java.net and commercial) is
compiled with Visual Studio 2017 15.5.
I assume the Oracle binaries are also supported by commons-daemon.
> Java 11 jvm.dll startup error messages not available on stdout/stderr
> -
>
> Key: DAEMON-398
> URL: https://issues.apache.org/jira/browse/DAEMON-398
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.1.1
> Environment: Windows
>Reporter: Gerwin
>Priority: Major
> Attachments: set-stdout.patch
>
>
> *Steps to reproduce*
> # Install Java 11
> # Install prunsrv.exe using jvm.dll and specify stdout and stderr file.
> # Using prunmgr, add a Java Option '-invalid'
> # Start the service
> # stdout and stderr files are empty!
> # Install Java 10
> # Using prunmgr, switch the Java Virtual Machine to Java 10
> # Start the service
> # {code:none|title=stderr}
> Java HotSpot(TM) 64-Bit Server VM warning: Ignoring option MaxPermSize;
> support was removed in 8.0
> Unrecognized option: -invalid
> {code}
> *Analysis*
> * It works for Java 8, 9 and 10, fails for 11, 12 and 13-ea.
> * I followed this guide: [Redirecting standard I/O from within a
> program|https://jdebp.eu/FGA/redirecting-standard-io.html] (see
> [^set-stdout.patch]), but it didn't help.
> * Even when I compile prunsrv with Visual Studio 2017 15.9 (linker 14.16) and
> test with Java 13-ea, which is also compiled with the same version (hence
> using the same C-runtime library) it does not work.
> * The guide ends with what the probably causing the issue:
> {quote}
> ... the one problem that remains with redirecting Win32 file handles:
> It doesn't affect anything in the program using a different C runtime library
> (such as a third-party DLL, for example).
> {quote}
> * Setting registry value Log/LogJniMessages=1, which is using the
> {{vfprintf}} option of the
> [JNI_CreateJavaVM|https://docs.oracle.com/en/java/javase/11/docs/specs/jni/invocation.html#jni_createjavavm]
> does not help. Maybe because is is added after the user-specified Java
> Options?
> *Ideas*
> # Make {{vfprintf}} the first parameter
> Downside of {{vfprintf}} is that it is hard to distinct between stdout and
> stderr. Maybe make a JNI call to {{System.out}} and {{System.err}} to be able
> to recognize the {{*File}} pointer and map to stdout and stderr accordingly.
> And I think that {{javajni.c/apxJavaSetOut()}} should not be required.
> # Log a bug for OpenJDK and try to get it fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IO-606) FilenameUtils.concat fails with relative path
[
https://issues.apache.org/jira/browse/IO-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834757#comment-16834757
]
Gary Gregory commented on IO-606:
-
[~matthias-ronge],
Thank you for your report.
Please feel free to provide a failing unit test as a PR on GitHub and a fix if
you are available.
Gary
> FilenameUtils.concat fails with relative path
> -
>
> Key: IO-606
> URL: https://issues.apache.org/jira/browse/IO-606
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Matthias Ronge
>Priority: Major
>
> {{FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")}}
> returns {{null}}, where expected result should be like
> {{../../../../src/test/resources/filename.xml}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IO-606) FilenameUtils.concat fails with relative path
[
https://issues.apache.org/jira/browse/IO-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Ronge updated IO-606:
--
Description:
{{FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")}}
returns {{null}}, where expected result should be like
{{../../../../src/test/resources/filename.xml}}
was:
FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")
returns null, where expected result should be like
../../../../src/test/resources/filename.xml
> FilenameUtils.concat fails with relative path
> -
>
> Key: IO-606
> URL: https://issues.apache.org/jira/browse/IO-606
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Matthias Ronge
>Priority: Major
>
> {{FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")}}
> returns {{null}}, where expected result should be like
> {{../../../../src/test/resources/filename.xml}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IO-606) FilenameUtils.concat fails with relative path
[
https://issues.apache.org/jira/browse/IO-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Ronge updated IO-606:
--
Description:
FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")
returns null, where expected result should be like
../../../../src/test/resources/filename.xml
was:
FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")
returns null, where expected result should be like
> FilenameUtils.concat fails with relative path
> -
>
> Key: IO-606
> URL: https://issues.apache.org/jira/browse/IO-606
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.6
>Reporter: Matthias Ronge
>Priority: Major
>
> FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")
> returns null, where expected result should be like
> ../../../../src/test/resources/filename.xml
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IO-606) FilenameUtils.concat fails with relative path
Matthias Ronge created IO-606:
-
Summary: FilenameUtils.concat fails with relative path
Key: IO-606
URL: https://issues.apache.org/jira/browse/IO-606
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.6
Reporter: Matthias Ronge
FilenameUtils.concat("../../../../src/test/resources/", "filename.xml")
returns null, where expected result should be like
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-101) MarsagliaTsangWang discrete probability sampler
[
https://issues.apache.org/jira/browse/RNG-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834563#comment-16834563
]
Alex D Herbert commented on RNG-101:
The results of this sampler for generating the Poisson distribution are shown
in RNG-91.
> MarsagliaTsangWang discrete probability sampler
> ---
>
> Key: RNG-101
> URL: https://issues.apache.org/jira/browse/RNG-101
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Major
> Fix For: 1.3
>
>
> The following paper provides a method for sampling from a discrete
> probability distribution that requires a single 30-bit unisigned integer per
> sample:
> {noformat}
> George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
> Fast Generation of Discrete Random Variables.
> Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.
> {noformat}
> [JSS Vol 11, Issue 3|http://dx.doi.org/10.18637/jss.v011.i03]
> The paper gives a general method that requires input probabilities expressed
> as unsigned 30 bit integers. The probabilities thus have an assumed divisor
> of 2^30^. The probabilities must sum to 2^30^. These are then efficiently
> tabulated for fast look-up using 5 base-64 digits from the 30-bit number.
> Sampling then takes 1 random integer per sample. No samples can be obtained
> for any observation where the probability is < 1^-32^.
> The paper provides software to compute the probability distributions for
> Poisson and Binomial and the look-up tables.
> It is applicable to any distribution by normalising to 2^30^:
> {code:java}
> // Compute the normalisation: 2^30 / sum
> // (assuming sum has been precomputed)
> final double normalisation = (1 << 30) / sum;
> final int[] prob = new int[probabilities.length];
> int sum = 0;
> int max = 0;
> int mode = 0;
> for (int i = 0; i < prob.length; i++) {
> // Add 0.5 for rounding
> final int p = (int) (probabilities[i] * normalisation + 0.5);
> sum += p;
> // Find the mode (maximum probability)
> if (max < p) {
> max = p;
> mode = i;
> }
> prob[i] = p;
> }
> // The sum must be >= 2^30.
> // Here just compensate the difference onto the highest probability.
> prob[mode] += (1 << 30) - sum;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (RNG-101) MarsagliaTsangWang discrete probability sampler
Alex D Herbert created RNG-101:
--
Summary: MarsagliaTsangWang discrete probability sampler
Key: RNG-101
URL: https://issues.apache.org/jira/browse/RNG-101
Project: Commons RNG
Issue Type: New Feature
Components: sampling
Affects Versions: 1.3
Reporter: Alex D Herbert
Assignee: Alex D Herbert
Fix For: 1.3
The following paper provides a method for sampling from a discrete probability
distribution that requires a single 30-bit unisigned integer per sample:
{noformat}
George Marsaglia, Wai Wan Tsang, Jingbo Wang (2004)
Fast Generation of Discrete Random Variables.
Journal of Statistical Software. Vol. 11, Issue. 3, pp. 1-11.
{noformat}
[JSS Vol 11, Issue 3|http://dx.doi.org/10.18637/jss.v011.i03]
The paper gives a general method that requires input probabilities expressed as
unsigned 30 bit integers. The probabilities thus have an assumed divisor of
2^30^. The probabilities must sum to 2^30^. These are then efficiently
tabulated for fast look-up using 5 base-64 digits from the 30-bit number.
Sampling then takes 1 random integer per sample. No samples can be obtained for
any observation where the probability is < 1^-32^.
The paper provides software to compute the probability distributions for
Poisson and Binomial and the look-up tables.
It is applicable to any distribution by normalising to 2^30^:
{code:java}
// Compute the normalisation: 2^30 / sum
// (assuming sum has been precomputed)
final double normalisation = (1 << 30) / sum;
final int[] prob = new int[probabilities.length];
int sum = 0;
int max = 0;
int mode = 0;
for (int i = 0; i < prob.length; i++) {
// Add 0.5 for rounding
final int p = (int) (probabilities[i] * normalisation + 0.5);
sum += p;
// Find the mode (maximum probability)
if (max < p) {
max = p;
mode = i;
}
prob[i] = p;
}
// The sum must be >= 2^30.
// Here just compensate the difference onto the highest probability.
prob[mode] += (1 << 30) - sum;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
