[jira] [Commented] (OGNL-249) Ognl.GetMethods does not return default methods in interfaces (new java 8 feature)
[
https://issues.apache.org/jira/browse/OGNL-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14598934#comment-14598934
]
Lukasz Lenart commented on OGNL-249:
I have found a better way to solve this problem, can you test the latest
snapshot version? 3.0.12-SNAPSHOT, here is the commit
https://github.com/jkuhnert/ognl/commit/92d2f58c1a52e98b24088745e7f91eae44950a4a
> Ognl.GetMethods does not return default methods in interfaces (new java 8
> feature)
> --
>
> Key: OGNL-249
> URL: https://issues.apache.org/jira/browse/OGNL-249
> Project: Commons OGNL
> Issue Type: Bug
> Components: Core Runtime
>Affects Versions: 3.0
> Environment: Java 8, OSX, likely all environments tho.
>Reporter: Tim Wright
> Fix For: 4.0
>
>
> Hi,
> I'm a contributor to an open source automated test framework called
> "Concordion". We use OGNL internally to evaulate test specifications. One of
> our users has reported a bug where Concordion cannot call default interface
> methods. We've traced the problem to OGNL - the OgnlRuntime.getMethods method
> is not returning default implementations of interface methods. We've verified
> the behaviour in OGNL versions 2.6.9 and 3.0.9.
> Consider the following interface and junit test file. The test fails. But it
> probably should not.
> {code:java}
> // INTERFACE
> package org.concordion;
> public interface InterfaceWithDefaults {
> default public void defaultMethod() { }
> }
> {code}
> {code:java}
> // TEST CLASS
> package org.concordion;
> import ognl.OgnlRuntime;
> import org.junit.Test;
> import static org.junit.Assert.assertNotNull;
> public class TestDefaultMethods implements InterfaceWithDefaults {
> @Test
> public void testDefaultMethod() {
> defaultMethod();
> assertNotNull(OgnlRuntime.getMethods(TestDefaultMethods.class,
> "defaultMethod", false));
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1062) Use Java 8 features to improve EqualsBuilder
[
https://issues.apache.org/jira/browse/LANG-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14598514#comment-14598514
]
Alan Green commented on LANG-1062:
--
A couple of thoughts:
1. The attribute access functions could be applied to both objects in the
equality, so append only needs one argument:
{code}
return EqualsBuilder.test(this, obj).append(o -> o.id).isEquals();
{code}
2. It would make sense to provide a single function that accepts a collection
of attribute access functions:
{code}
return EqualsBuilder.test(this, obj).appendAll(Arrays.asList(o -> o.id, o ->
o.name, o -> o.color)).isEquals();
{code}
3. Since the common case is for hashCode and equality to work over the same
member attributes, they could share this list:
{code}
private static final List> EQUAL_ATTRS = Arrays.asList(o
-> o.id, o -> o.name, o -> o.color);
public boolean equals(final Object obj) {
return EqualsBuilder.test(this, obj).appendAll(EQUAL_ATTRS).isEquals();
}
public int hashCode() {
return HashCodeBuilder.for(this).appendAll(EQUAL_ATTRS).build();
}
{code}
> Use Java 8 features to improve EqualsBuilder
>
>
> Key: LANG-1062
> URL: https://issues.apache.org/jira/browse/LANG-1062
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.builder.*
>Affects Versions: 3.3.2
>Reporter: Bruce Brouwer
> Fix For: 4.0
>
>
> Remove the need for boilerplate code still necessary with EqualsBuilder.
> Instead of checking for instanceOf or equality checks, it would be nice to be
> able to write this:
> {code}
> public boolean equals(final Object obj) {
> return EqualsBuilder.test(this, obj).append(this.id, o -> o.id).isEquals();
> }
> {code}
> I think this could generally work with a subclass of EqualsBuilder with a
> generic type, like this:
> {code}
> public class LambdaEqualsBuilder extends EqualsBuilder {
> private final T obj;
> public LambdaEqualsBuilder(final T _this, final Object obj) {
> if (_this != obj && !_this.getClass().isInstance(obj)) {
> appendSuper(false);
> this.obj = null;
> } else {
> this.obj = (T) obj;
> }
> }
> public LambdaEqualsBuilder append(final P a, final Function
> b) {
> if (isEquals()) {
> return (LambdaEqualsBuilder) append(a, b.apply(obj));
> }
> return this;
> }
> // This might actually go in EqualsBuilder itself
> public static LambdaEqualsBuilder test(final E _this, final Object
> _that) {
> return new LambdaEqualsBuilder(_this, _that);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IO-481) org.apache.commons.io.FileUtils#waitFor waits too long
[
https://issues.apache.org/jira/browse/IO-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed IO-481.
-
Resolution: Fixed
Fix Version/s: 2.5
Assignee: Kristian Rosenvold
Fixed in r1687108
> org.apache.commons.io.FileUtils#waitFor waits too long
> --
>
> Key: IO-481
> URL: https://issues.apache.org/jira/browse/IO-481
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Kristian Rosenvold
>Assignee: Kristian Rosenvold
> Fix For: 2.5
>
>
> The timing algorithm is basically broken, since Thread.sleep is imprecise.
> There is also a counter error in the looping code.
> The following testcase will never run in less than 4 seconds on my machine
> public void testRealWallTime() {
> long start = System.currentTimeMillis();
> FileUtils.waitFor(new File(""), 2);
> System.out.println("elapsed = " + (System.currentTimeMillis() -
> start));
> }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLI-255) DefaultParser, option with long name and single dash, unlimited arguments
Alexander Prishchepov created CLI-255:
-
Summary: DefaultParser, option with long name and single dash,
unlimited arguments
Key: CLI-255
URL: https://issues.apache.org/jira/browse/CLI-255
Project: Commons CLI
Issue Type: Bug
Components: Parser
Affects Versions: 1.3.1, 1.3
Reporter: Alexander Prishchepov
Priority: Minor
If I have options with long name and single dash, DefaultParser does not
recognize them after a list of unlimited arguments.
Here is the test case:
---
public void testUnlimitedArgs() throws Exception
{
String[] args = new String[] {"-unlimitedOne", "one", "two",
"-unlimitedTwo",
"alpha"};
Options options = new Options();
options.addOption(Option.builder("unlimitedOne").hasArgs().build());
options.addOption(Option.builder("unlimitedTwo").hasArgs().build());
CommandLine cl = parser.parse(options, args);
assertTrue("Confirm -unlimitedOne is set",
cl.hasOption("unlimitedOne"));
assertEquals("number of arg for -unlimitedOne", 2,
cl.getOptionValues("unlimitedOne").length);
assertTrue("Confirm -unlimitedTwo is set",
cl.hasOption("unlimitedTwo"));
assertEquals("number of arg for -unlimitedTwo", 1,
cl.getOptionValues("unlimitedTwo").length);
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (COLLECTIONS-546) Implement expiring queue like already exist PassiveExpiringMap
[ https://issues.apache.org/jira/browse/COLLECTIONS-546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597650#comment-14597650 ] Suryakanth commented on COLLECTIONS-546: I want to work on this. I want to submit a patch in a day or two. > Implement expiring queue like already exist PassiveExpiringMap > -- > > Key: COLLECTIONS-546 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-546 > Project: Commons Collections > Issue Type: New Feature > Components: Collection >Affects Versions: 4.x >Reporter: Guram Savinov > Labels: collection, expiration, queue > > It's very useful collection wrapper for map with expiration - > PassiveExpiringMap. > Can you implement queue with expiration like already exist PassiveExpiringMap? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (LANG-1151) Performance improvements for NumberUtils.isParsable
[
https://issues.apache.org/jira/browse/LANG-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Pablo Santos Rodríguez updated LANG-1151:
--
Attachment: benchmark-lang1151.zip
Hi [~britter],
please see attached maven project with the benchmark, it is adapted from the
one at http://jdevelopment.nl/efficient-determine-string-number/
Running it several times yields consistent results, f.ex.:
{code}
isNumberWithParseLong: 21350 ms
isNumberWithIsDigit: 610 ms
isNumberWithRegex: 2688 ms
isParsable34: 1972 ms
isParsable: 736 ms
{code}
(although {{isNumberWithIsDigit}} is faster, I suspect it's because it doesn't
handle the decimal point)
br,
juan pablo
> Performance improvements for NumberUtils.isParsable
> ---
>
> Key: LANG-1151
> URL: https://issues.apache.org/jira/browse/LANG-1151
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
>Affects Versions: 3.4
>Reporter: Juan Pablo Santos Rodríguez
> Attachments: benchmark-lang1151.zip
>
>
> NumberUtils.isParsable contains String comparisons + some String replacing,
> which could be improved in terms of performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1151) Performance improvements for NumberUtils.isParsable
[ https://issues.apache.org/jira/browse/LANG-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Pablo Santos Rodríguez updated LANG-1151: -- Issue Type: Improvement (was: Bug) > Performance improvements for NumberUtils.isParsable > --- > > Key: LANG-1151 > URL: https://issues.apache.org/jira/browse/LANG-1151 > Project: Commons Lang > Issue Type: Improvement > Components: lang.math.* >Affects Versions: 3.4 >Reporter: Juan Pablo Santos Rodríguez > Attachments: benchmark-lang1151.zip > > > NumberUtils.isParsable contains String comparisons + some String replacing, > which could be improved in terms of performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
