[jira] [Commented] (MATH-1467) Avoid throwing exceptions when using default locale
[
https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595843#comment-16595843
]
Gilles commented on MATH-1467:
--
{quote}is it a big deal?
{quote}
IMO, no. But it is a bit strange to single out a special case.
Moreover, I think that the problem is more general: we should not use
exception when a key is missing or misspelled since it is discarded anyway.
Please have a look at the fix in commit
34bd1707749c71302207fb2fc0559b6ca301d895
No more useless exceptions for "English", but it will load the (empty) bundle
every time a message is requested. For "English" is certainly a performance
hit. However, it is a general issue with {{getLocalizedMessage(Locale)}}. If
you are only interested in the "English" message (?), perhaps your code should
call {{getMessage()}}.
> Avoid throwing exceptions when using default locale
> ---
>
> Key: MATH-1467
> URL: https://issues.apache.org/jira/browse/MATH-1467
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.6.1
>Reporter: Gregory Jevardat
>Priority: Major
> Attachments: LocalizedFormats.java, LocalizedFormatsTest.java
>
>
> In the LocalizedFormats class the method getLocalizedString systematically
> throws an exception when the US or EN locale is used.
> It occurs because it tries to load the bundle in any case and obviously the
> properties file for EN does not exist.
> Maybe a little check if an EN locale is used and then returning the
> sourceFormat would avoid trying to load the bundle and throw exceptions.
> In my case we have intensive (billions) statistical computations and Java
> Mission Control reports 10-100k's of MissingResourcesExceptions caused by
> that.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1466) CMAES Optimization Fails to find Actual Optimum if Solution Value is Negative
[
https://issues.apache.org/jira/browse/MATH-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595780#comment-16595780
]
Gilles commented on MATH-1466:
--
bq. I think it has to do with the following stop criteria, which ends early if
the cost is negative
It is spot on, indeed.
But this condition is controlled by the {{stopFitness}} argument to the
[constructor|http://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math4/optim/nonlinear/scalar/noderiv/CMAESOptimizer.html#CMAESOptimizer-int-double-boolean-int-int-org.apache.commons.rng.UniformRandomProvider-boolean-org.apache.commons.math4.optim.ConvergenceChecker-].
Which value do you use?
I've added a [unit
test|https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=commit;h=efb0230063b31d53bd077d9f6a4bb64fcbb9c97f]
for {noformat}f(x) = x^2 - 100{noformat} that shows that the implementation
should also work if the optimum has a negative fitness.
> CMAES Optimization Fails to find Actual Optimum if Solution Value is Negative
> -
>
> Key: MATH-1466
> URL: https://issues.apache.org/jira/browse/MATH-1466
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Rebecca
>Priority: Major
> Labels: Optimization
>
> Class CMAESOptimizer
> ([java.lang.Object|http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html?is-external=true]
> [org.apache.commons.math3.optim.BaseOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/BaseOptimizer.html]
> [org.apache.commons.math3.optim.BaseMultivariateOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/BaseMultivariateOptimizer.html]<[PointValuePair|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/PointValuePair.html]>
> [org.apache.commons.math3.optim.nonlinear.scalar.MultivariateOptimizer|http://commons.apache.org/proper/commons-math/javadocs/api-3.4/org/apache/commons/math3/optim/nonlinear/scalar/MultivariateOptimizer.html]
> org.apache.commons.math3.optim.nonlinear.scalar.noderiv.CMAESOptimizer)
> I cannot provide code as I work for a private company with IP. However, my
> tests indicate that if the we are minimizing a cost function, and the
> function's value is a negative value, the resulting solution is incorrect.
> For example, say I were minimizing y = x^2 - 100
> The solution should be x = 0, with a value of -100. However, this CMAES
> optimizer would find random solutions, like x = 3 or x = -2 (with solutions
> of -91 and -96 respectively).
> I used the BOBYQA solver, and it was able to find the solution of x = 0 with
> a value of y = -100. I tested y = x^2 + 100 and the CMAES solver was able to
> find a solution of x = 0, y = 100. I tested y = x^2 and the CMAES the CMAES
> solver was able to find a solution of x = 0, y = 0. I tested y = x^2 -1 and
> the CMAES solver was NOT able to find a solution of x = 0, y = -1.
> I know it is highly inconvenient, but if someone wants to take a look at my
> cost function I can try to get an NDA. I think this bug is reproducible
> without it. Feel free to contact me at
> [rwolk...@umich.edu|mailto:rwolk...@umich.edu] if more info is needed.
> I think it has to do with the following stop criteria, which ends early if
> the cost is negative:
> if (stopFitness != 0 && bestFitness < (isMinimize ? stopFitness :
> -stopFitness)) {
> break generationLoop;
> }
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (TEXT-134) Add a Properties file string lookup
[ https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb reopened TEXT-134: --- Note that OpenVMS uses :: as a separator in path names. Furthermore, Unix allows :: in a path name. I'm not sure it makes sense to combine the Document name and the Key in the same string. Also, what about the possible characters in the key? > Add a Properties file string lookup > --- > > Key: TEXT-134 > URL: https://issues.apache.org/jira/browse/TEXT-134 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.5 > > > Add a Properties file String Lookup to look up the value for a given key in > the format "Document:Key". > For example: "com/domain/document.properties::key". > Note the use of the separator "::" instead of ":" to allow for path > containing ":" like "C:\path\to\file.properties". > The lookup key is "properties". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TEXT-134) Add a Properties file string lookup
[ https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated TEXT-134: -- Description: Add a Properties file String Lookup to look up the value for a given key in the format "Document:Key". For example: "com/domain/document.properties::key". Note the use of the separator "::" instead of ":" to allow for path containing ":" like "C:\path\to\file.properties". The lookup key is "properties". was: Add a Properties file String Lookup to look up the value for a given key in the format "Document:Key". For example: "com/domain/document.properties:key". The lookup key is "properties". > Add a Properties file string lookup > --- > > Key: TEXT-134 > URL: https://issues.apache.org/jira/browse/TEXT-134 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.5 > > > Add a Properties file String Lookup to look up the value for a given key in > the format "Document:Key". > For example: "com/domain/document.properties::key". > Note the use of the separator "::" instead of ":" to allow for path > containing ":" like "C:\path\to\file.properties". > The lookup key is "properties". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TEXT-134) Add a Properties file string lookup
[ https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed TEXT-134. - Resolution: Fixed > Add a Properties file string lookup > --- > > Key: TEXT-134 > URL: https://issues.apache.org/jira/browse/TEXT-134 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.5 > > > Add a Properties file String Lookup to look up the value for a given key in > the format "Document:Key". > For example: "com/domain/document.properties::key". > Note the use of the separator "::" instead of ":" to allow for path > containing ":" like "C:\path\to\file.properties". > The lookup key is "properties". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (TEXT-134) Add a Properties file string lookup
[ https://issues.apache.org/jira/browse/TEXT-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory reopened TEXT-134: --- > Add a Properties file string lookup > --- > > Key: TEXT-134 > URL: https://issues.apache.org/jira/browse/TEXT-134 > Project: Commons Text > Issue Type: New Feature >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.5 > > > Add a Properties file String Lookup to look up the value for a given key in > the format "Document:Key". > For example: "com/domain/document.properties:key". > The lookup key is "properties". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #350: Replace FindBugs with SpotBugs
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/350 [](https://coveralls.io/builds/18711022) Coverage remained the same at 95.253% when pulling **82fd2516d6c018e46ef290e05551349a9ed82ca8 on PascalSchumacher:spotbugs** into **3ee9cc840088762c875a9c02531077279f7c237f on apache:master**. ---
[GitHub] commons-lang pull request #350: Replace FindBugs with SpotBugs
GitHub user PascalSchumacher opened a pull request: https://github.com/apache/commons-lang/pull/350 Replace FindBugs with SpotBugs You can merge this pull request into a Git repository by running: $ git pull https://github.com/PascalSchumacher/commons-lang spotbugs Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/350.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #350 commit 82fd2516d6c018e46ef290e05551349a9ed82ca8 Author: pascalschumacher Date: 2018-08-28T17:00:09Z Replace FindBugs with SpotBugs ---
[jira] [Commented] (VALIDATOR-447) ISBN style numbers outside ISBN range returning true for isValid
[ https://issues.apache.org/jira/browse/VALIDATOR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595057#comment-16595057 ] Alex commented on VALIDATOR-447: thanks again for the feedback. I think I broadly agree. I am not suggesting that we should try and validate against actual publications and actual allocated ISBNs. Validating ISBNs that are not in a range that is allocted to ISBNs is more the issue generally. This could probably be disclaimed in the javadocs (what is being validated is ean13s with 978 and 979 prefixes). On the ISMN issue, which is probably more misleading (eg 979-0-2600-0043-8), a lightweight solution would be to add a isISMN method that applies additional validation to confirm if the item is an ISMN (rather than an ISBN) > ISBN style numbers outside ISBN range returning true for isValid > > > Key: VALIDATOR-447 > URL: https://issues.apache.org/jira/browse/VALIDATOR-447 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Alex >Priority: Major > Labels: validators > Attachments: RangeMessage.xml > > > All 13 digit EANs with the 979 prefix are validating as ISBNs > (ISBNValidator). There are 2 issues with this. > # 979-0 prefixed numbers are allocated to the ISMN agency and represent > music works. [https://www.ismn-international.org/whatis.html] > # 979-[2-9] are unassigned at present, that is they have not yet been > allocated to a country agency (or another authority). > see attached xml (from > [www.isbn-international.org/export_rangemessage.xml|http://www.isbn-international.org/export_rangemessage.xml] > [^RangeMessage.xml] ) for the current valid ranges for ISBN > and > [https://en.wikipedia.org/wiki/List_of_ISBN_identifier_groups#Identifiers_of_the_979-_prefix] > An example unassigned 'ISBN' is 97923 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594939#comment-16594939 ] Gregory Jevardat commented on MATH-1467: So Here is my quick proposal. Idea is to bypass ResourceBundle in case of english language. The only side effect I see as a beginner in this project is when you want to override english translations by our own properties file. In this case it will not work. But is it a big deal ? [^LocalizedFormats.java][^LocalizedFormatsTest.java] > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > Attachments: LocalizedFormats.java, LocalizedFormatsTest.java > > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Jevardat updated MATH-1467: --- Attachment: LocalizedFormatsTest.java > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > Attachments: LocalizedFormats.java, LocalizedFormatsTest.java > > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Jevardat updated MATH-1467: --- Attachment: LocalizedFormats.java > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > Attachments: LocalizedFormats.java > > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594907#comment-16594907 ] Gregory Jevardat commented on MATH-1467: I'll try. First issue is that the dependency org.apache.commons commons-rng-sampling 1.1-SNAPSHOT is not found by default. So I switched to 1.1 for being able to build the project in IntelliJ > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (VALIDATOR-447) ISBN style numbers outside ISBN range returning true for isValid
[ https://issues.apache.org/jira/browse/VALIDATOR-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594870#comment-16594870 ] Sebb commented on VALIDATOR-447: AFAICT, it's impossible in general to fully validate an ISBN - even with the XML file, there will be numbers that don't (yet) correspond with actual publications. Also, the XML file changes frequently (e.g. the attached version (Aug 23) is already out of date - there is one dated Aug 28). Further, it looks as though the HTTP server does not support ETAG or Modified timestamps either, so AFAICT one would have to download the full XML file on a regular basis. The code currently detects generic errors such as unexpected prefix and bad checksum. (And AFAIK it does not reject any valid codes - that would obviously be a bug). What is the use case for stricter validation? Is there sufficient demand for this to be implemented, documented and maintained? > ISBN style numbers outside ISBN range returning true for isValid > > > Key: VALIDATOR-447 > URL: https://issues.apache.org/jira/browse/VALIDATOR-447 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Reporter: Alex >Priority: Major > Labels: validators > Attachments: RangeMessage.xml > > > All 13 digit EANs with the 979 prefix are validating as ISBNs > (ISBNValidator). There are 2 issues with this. > # 979-0 prefixed numbers are allocated to the ISMN agency and represent > music works. [https://www.ismn-international.org/whatis.html] > # 979-[2-9] are unassigned at present, that is they have not yet been > allocated to a country agency (or another authority). > see attached xml (from > [www.isbn-international.org/export_rangemessage.xml|http://www.isbn-international.org/export_rangemessage.xml] > [^RangeMessage.xml] ) for the current valid ranges for ISBN > and > [https://en.wikipedia.org/wiki/List_of_ISBN_identifier_groups#Identifiers_of_the_979-_prefix] > An example unassigned 'ISBN' is 97923 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JEXL-270) Wrong Script$Curried creation when script.curry() method is called inside script
[
https://issues.apache.org/jira/browse/JEXL-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594854#comment-16594854
]
Dmitri Blinov commented on JEXL-270:
Somehow the source text of the curried lambda in the second test case becomes
the one of the script itself, i.e. {{var base = 0; var sum = (y, z) ->
{var x = base; x += y; return x}; base = 2; var y = sum.curry(1); y.toString()
eq sum.toString()}}, not the \{{(y, z) -> {var x = base; x += y; return x}
}}, if this is of any help
> Wrong Script$Curried creation when script.curry() method is called inside
> script
>
>
> Key: JEXL-270
> URL: https://issues.apache.org/jira/browse/JEXL-270
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Priority: Major
>
> I have noticed that when i call lambda.curry() method inside the script, then
> the curried lamba is created with wrong source text. I expect the source text
> of the curried lambda to be always equal to that of original, but that is not
> the case now. To illustrate this I have prepared two testcases, from which
> {{testCurryScript2}} fails with
> [ERROR] Failures:
> [ERROR] LambdaTest.testCurryScript2:307 expected: but was:
> {code:java}
> @Test
> public void testCurryScript() throws Exception {
> JexlEngine jexl = new Engine();
> JexlScript base = jexl.createScript("(x, y, z)->{ x + y + z }");
> String text = base.toString();
> JexlScript script = base.curry(5, 15);
> Assert.assertEquals(text, script.toString());
> JexlEvalContext ctxt = new JexlEvalContext();
> ctxt.set("s", base);
> script = jexl.createScript("return s");
> Object result = script.execute(ctxt);
> Assert.assertEquals(text, result.toString());
> script = jexl.createScript("return s.curry(1)");
> result = script.execute(ctxt);
> Assert.assertEquals(text, result.toString());
> }
> @Test
> public void testCurryScript2() throws Exception {
> JexlEngine jexl = new Engine();
> JexlScript base = jexl.createScript("var base = 0; var sum = (y, z)
> -> {var x = base; x += y; return x}; base = 2; var y = sum.curry(1);
> y.toString() eq sum.toString()");
> Object result = base.execute(null);
> Assert.assertEquals(Boolean.TRUE, result);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (JEXL-270) Wrong Script$Curried creation when script.curry() method is called inside script
Dmitri Blinov created JEXL-270:
--
Summary: Wrong Script$Curried creation when script.curry() method
is called inside script
Key: JEXL-270
URL: https://issues.apache.org/jira/browse/JEXL-270
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Reporter: Dmitri Blinov
I have noticed that when i call lambda.curry() method inside the script, then
the curried lamba is created with wrong source text. I expect the source text
of the curried lambda to be always equal to that of original, but that is not
the case now. To illustrate this I have prepared two testcases, from which
{{testCurryScript2}} fails with
[ERROR] Failures:
[ERROR] LambdaTest.testCurryScript2:307 expected: but was:
{code:java}
@Test
public void testCurryScript() throws Exception {
JexlEngine jexl = new Engine();
JexlScript base = jexl.createScript("(x, y, z)->{ x + y + z }");
String text = base.toString();
JexlScript script = base.curry(5, 15);
Assert.assertEquals(text, script.toString());
JexlEvalContext ctxt = new JexlEvalContext();
ctxt.set("s", base);
script = jexl.createScript("return s");
Object result = script.execute(ctxt);
Assert.assertEquals(text, result.toString());
script = jexl.createScript("return s.curry(1)");
result = script.execute(ctxt);
Assert.assertEquals(text, result.toString());
}
@Test
public void testCurryScript2() throws Exception {
JexlEngine jexl = new Engine();
JexlScript base = jexl.createScript("var base = 0; var sum = (y, z) ->
{var x = base; x += y; return x}; base = 2; var y = sum.curry(1); y.toString()
eq sum.toString()");
Object result = base.execute(null);
Assert.assertEquals(Boolean.TRUE, result);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594759#comment-16594759 ] Gilles commented on MATH-1467: -- Forgot to stress: please use the development version (git "master" branch either at [Apache|https://git1-us-west.apache.org/repos/asf?p=commons-math.git;a=tree] or its mirror at GitHub). > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MATH-1467) Avoid throwing exceptions when using default locale
[ https://issues.apache.org/jira/browse/MATH-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594741#comment-16594741 ] Gilles commented on MATH-1467: -- Could you please submit a patch with unit test showing the (un)expected behaviour? Thanks. > Avoid throwing exceptions when using default locale > --- > > Key: MATH-1467 > URL: https://issues.apache.org/jira/browse/MATH-1467 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Gregory Jevardat >Priority: Major > > In the LocalizedFormats class the method getLocalizedString systematically > throws an exception when the US or EN locale is used. > It occurs because it tries to load the bundle in any case and obviously the > properties file for EN does not exist. > Maybe a little check if an EN locale is used and then returning the > sourceFormat would avoid trying to load the bundle and throw exceptions. > In my case we have intensive (billions) statistical computations and Java > Mission Control reports 10-100k's of MissingResourcesExceptions caused by > that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1417) Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate
[ https://issues.apache.org/jira/browse/LANG-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594701#comment-16594701 ] ASF GitHub Bot commented on LANG-1417: -- Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/349 Build is failing on Travis but not locally... 樂 > Deprecate ThreadPredicate and ThreadGroupPredicate in favor of > java.util.function.Predicate > --- > > Key: LANG-1417 > URL: https://issues.apache.org/jira/browse/LANG-1417 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Priority: Major > Fix For: 3.9 > > > Since we upgraded the Java language requirement to Java 8, we can deprecate > our custom ThreadPredicate and ThreadGroupPredicate implementations. > It looks like our initial plan to let ThreadPredicate and > ThreadGroupPredicate extend java.util.function.Predicate is not possible. > This is because auf AlwaysTruePredicate and NamePredicate extending both > interfaces. This leads to the situation that these classes would inherit from > both Predicate and Predicate, which is not possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1417) Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate
[ https://issues.apache.org/jira/browse/LANG-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594700#comment-16594700 ] ASF GitHub Bot commented on LANG-1417: -- Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/349 In this proposal I added the java.util.function.Predicate APIs to the ThreadUtils class. Another option is to deprecate ThreadUtils all together and put a new ThreadUtils class alongside which only hat the new APIs. > Deprecate ThreadPredicate and ThreadGroupPredicate in favor of > java.util.function.Predicate > --- > > Key: LANG-1417 > URL: https://issues.apache.org/jira/browse/LANG-1417 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Priority: Major > Fix For: 3.9 > > > Since we upgraded the Java language requirement to Java 8, we can deprecate > our custom ThreadPredicate and ThreadGroupPredicate implementations. > It looks like our initial plan to let ThreadPredicate and > ThreadGroupPredicate extend java.util.function.Predicate is not possible. > This is because auf AlwaysTruePredicate and NamePredicate extending both > interfaces. This leads to the situation that these classes would inherit from > both Predicate and Predicate, which is not possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang issue #349: LANG-1417: Deprecate ThreadPredicate and ThreadGrou...
Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/349 Build is failing on Travis but not locally... ð¤ ---
[GitHub] commons-lang issue #349: LANG-1417: Deprecate ThreadPredicate and ThreadGrou...
Github user britter commented on the issue: https://github.com/apache/commons-lang/pull/349 In this proposal I added the java.util.function.Predicate APIs to the ThreadUtils class. Another option is to deprecate ThreadUtils all together and put a new ThreadUtils class alongside which only hat the new APIs. ---
[jira] [Commented] (LANG-1417) Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate
[ https://issues.apache.org/jira/browse/LANG-1417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16594692#comment-16594692 ] ASF GitHub Bot commented on LANG-1417: -- GitHub user britter opened a pull request: https://github.com/apache/commons-lang/pull/349 LANG-1417: Deprecate ThreadPredicate and ThreadGroupPredicate in favo… …r of java.util.function.Predicate I don't see a way to let ThreadGroupPredicate and ThreadPredicate inherit from java.util.function.Predicate. See my comment in [LANG-1417](https://issues.apache.org/jira/browse/LANG-1417). @salyh as author of the initial implementation, can you have a look please? Am I missing something? You can merge this pull request into a Git repository by running: $ git pull https://github.com/britter/commons-lang LANG-1417 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/349.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #349 commit a5a3b374b1f1ef0c7b7746e58a0dde19303e4492 Author: Benedikt Ritter Date: 2018-08-28T08:22:40Z LANG-1417: Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate > Deprecate ThreadPredicate and ThreadGroupPredicate in favor of > java.util.function.Predicate > --- > > Key: LANG-1417 > URL: https://issues.apache.org/jira/browse/LANG-1417 > Project: Commons Lang > Issue Type: Improvement > Components: lang.* >Reporter: Benedikt Ritter >Priority: Major > Fix For: 3.9 > > > Since we upgraded the Java language requirement to Java 8, we can deprecate > our custom ThreadPredicate and ThreadGroupPredicate implementations. > It looks like our initial plan to let ThreadPredicate and > ThreadGroupPredicate extend java.util.function.Predicate is not possible. > This is because auf AlwaysTruePredicate and NamePredicate extending both > interfaces. This leads to the situation that these classes would inherit from > both Predicate and Predicate, which is not possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] commons-lang pull request #349: LANG-1417: Deprecate ThreadPredicate and Thr...
GitHub user britter opened a pull request: https://github.com/apache/commons-lang/pull/349 LANG-1417: Deprecate ThreadPredicate and ThreadGroupPredicate in favo⦠â¦r of java.util.function.Predicate I don't see a way to let ThreadGroupPredicate and ThreadPredicate inherit from java.util.function.Predicate. See my comment in [LANG-1417](https://issues.apache.org/jira/browse/LANG-1417). @salyh as author of the initial implementation, can you have a look please? Am I missing something? You can merge this pull request into a Git repository by running: $ git pull https://github.com/britter/commons-lang LANG-1417 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/349.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #349 commit a5a3b374b1f1ef0c7b7746e58a0dde19303e4492 Author: Benedikt Ritter Date: 2018-08-28T08:22:40Z LANG-1417: Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate ---
[jira] [Created] (LANG-1417) Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate
Benedikt Ritter created LANG-1417: - Summary: Deprecate ThreadPredicate and ThreadGroupPredicate in favor of java.util.function.Predicate Key: LANG-1417 URL: https://issues.apache.org/jira/browse/LANG-1417 Project: Commons Lang Issue Type: Improvement Components: lang.* Reporter: Benedikt Ritter Fix For: 3.9 Since we upgraded the Java language requirement to Java 8, we can deprecate our custom ThreadPredicate and ThreadGroupPredicate implementations. It looks like our initial plan to let ThreadPredicate and ThreadGroupPredicate extend java.util.function.Predicate is not possible. This is because auf AlwaysTruePredicate and NamePredicate extending both interfaces. This leads to the situation that these classes would inherit from both Predicate and Predicate, which is not possible. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MATH-1467) Avoid throwing exceptions when using default locale
Gregory Jevardat created MATH-1467: -- Summary: Avoid throwing exceptions when using default locale Key: MATH-1467 URL: https://issues.apache.org/jira/browse/MATH-1467 Project: Commons Math Issue Type: Improvement Affects Versions: 3.6.1 Reporter: Gregory Jevardat In the LocalizedFormats class the method getLocalizedString systematically throws an exception when the US or EN locale is used. It occurs because it tries to load the bundle in any case and obviously the properties file for EN does not exist. Maybe a little check if an EN locale is used and then returning the sourceFormat would avoid trying to load the bundle and throw exceptions. In my case we have intensive (billions) statistical computations and Java Mission Control reports 10-100k's of MissingResourcesExceptions caused by that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (JEXL-269) Indexed for-loop
Dmitri Blinov created JEXL-269:
--
Summary: Indexed for-loop
Key: JEXL-269
URL: https://issues.apache.org/jira/browse/JEXL-269
Project: Commons JEXL
Issue Type: New Feature
Affects Versions: 3.1
Environment: I have created a PR for this feature, please see
[PR#12|https://github.com/apache/commons-jexl/pull/12]
Reporter: Dmitri Blinov
Introduce new extended syntax of 'for' statement, which allows to specify two
variables, like the following
{code:java}
for (var i, item : list){code}
Inside the loop, the first variable gets current iteration index, starting from
0, and the second variable gets current iterated value. The special
consideration is taken for iteration over map entries, like the following
{code:java}
for(var key, entry : map){code}
, in this case the first variable is the map key, and the second is the
corresponding map value
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (JEXL-267) Lambda evaluation
[
https://issues.apache.org/jira/browse/JEXL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitri Blinov closed JEXL-267.
--
> Lambda evaluation
> -
>
> Key: JEXL-267
> URL: https://issues.apache.org/jira/browse/JEXL-267
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.1
>
>
> The following script returns correct lambda {{function(s,v)\{42;}}}
> {code:java}
> var x = (s, v)->{42}{code}
> While the following script returns {{42}}
> {code:java}
> (s, v)->{42}{code}
> The expected result is the same lambda as in the first example
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
