[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils
[
https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942595#comment-15942595
]
ASF GitHub Bot commented on LANG-1317:
--
Github user yasserzamani commented on the issue:
https://github.com/apache/commons-lang/pull/261
Another bad thing is that `getMethodsWithAnnotation(cls, annotationCls,
false, false)` will be a duplicate for `getMethodsWithAnnotation(cls,
annotationCls)`.
Another solution is to keep my current changes not modified but add
following javadoc:
```
*
* To lookup annotations on the given class level only choose {@code
get*()} methods
* and to lookup in the entire inheritance hierarchy of the given class and
ignore
* accessibility, choose {@code find*()} methods
*
* @since 2.5
*/
public class MethodUtils {
```
> Add findAnnotation and findMethodsWithAnnotation to MethodUtils
> ---
>
> Key: LANG-1317
> URL: https://issues.apache.org/jira/browse/LANG-1317
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.reflect.*
>Reporter: Yasser Zamani
> Labels: patch
>
> In order to fix WW-4744 , mainly, I am going to add two functionalities to
> MethodUtils: findAnnotation and findMethodsWithAnnotation.
> findAnnotation will be an extension for Method.getAnnotation that also
> searches interfaces and super classes while caching results with no memory
> leak.
> findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation
> that also supports non public methods, super class and interface methods,
> again, while caching results as above.
> Generally, do you agree with these in a pull request? If so, I will be
> working on it :)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user yasserzamani commented on the issue:
https://github.com/apache/commons-lang/pull/261
Another bad thing is that `getMethodsWithAnnotation(cls, annotationCls,
false, false)` will be a duplicate for `getMethodsWithAnnotation(cls,
annotationCls)`.
Another solution is to keep my current changes not modified but add
following javadoc:
```
*
* To lookup annotations on the given class level only choose {@code
get*()} methods
* and to lookup in the entire inheritance hierarchy of the given class and
ignore
* accessibility, choose {@code find*()} methods
*
* @since 2.5
*/
public class MethodUtils {
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * Replace The SubnetInfo subclass of SubnetUtils ** SubnetUtils.SubnetInfo works as the abstract class of IP4Subnet and IP6Subnet * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into the SubnetInfo subclass * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* ** SubnetUtils.SubnetInfo works as the abstract class of IP4Subnet and IP6Subnet * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into the SubnetInfo subclass * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * Replace The SubnetInfo subclass of SubnetUtils > ** SubnetUtils.SubnetInfo works as the abstract class of IP4Subnet and > IP6Subnet > * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into > the SubnetInfo subclass > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* ** SubnetUtils.SubnetInfo works as the abstract class of IP4Subnet and IP6Subnet * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into the SubnetInfo subclass * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into the SubnetInfo subclass * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into the subclass of SubnetUtil* > ** SubnetUtils.SubnetInfo works as the abstract class of IP4Subnet and > IP6Subnet > * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into > the SubnetInfo subclass > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into the SubnetInfo subclass * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into the subclass of SubnetUtil* > * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into > the SubnetInfo subclass > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into the subclass of SubnetUtil* > * A few methods of SubnetUtils, rangeCheck, pop, and format, were moved into > SubnetUtils.SubnetInfo. > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into a subclass of SubnetUtil* > ** The method rangeCheck, pop, and format of SubnetUtils was moved into > SubnetUtils.SubnetInfo. > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into the subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into the subclass of SubnetUtil* > ** The method rangeCheck, pop, and format of SubnetUtils was moved into > SubnetUtils.SubnetInfo. > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into a subclass of SubnetUtil > ** The method rangeCheck, pop, and format of SubnetUtils was moved into > SubnetUtils.SubnetInfo. > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-630) NET-630 Changed SubnetUtils for NEW SubnetInfo subclass
[ https://issues.apache.org/jira/browse/NET-630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-630: - Description: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil* ** The method rangeCheck, pop, and format of SubnetUtils was moved into SubnetUtils.SubnetInfo. * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 was: The constructors of this class has been modified to create a object of subnet summary information. Also, added two new static methods to create the object. h2. Change log h3. 3/24/17 * *SubnetInfo class into a subclass of SubnetUtil* * The getAddressCount and getAllAddresses methods were reimplemented ** For compatibility * Moved IP4Subnet and IP6Subnet classes into the until package h3. 3/23/17 * *Renamed getAddressCount() to getAddressCountString()* ** The old name, getAddressCount(), was the obsoleted name and confused others * Removed the insignificant value representation, which are no reasons to be defined in this class * -Changes the path to SubnetInfo (SubnetUtilsExample.java and SubnetUtilsTest.java)- * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- * Improved comments https://github.com/apache/commons-net/pull/25 > NET-630 Changed SubnetUtils for NEW SubnetInfo subclass > --- > > Key: NET-630 > URL: https://issues.apache.org/jira/browse/NET-630 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > The constructors of this class has been modified to create a object of subnet > summary information. > Also, added two new static methods to create the object. > h2. Change log > h3. 3/24/17 > * *SubnetInfo class into a subclass of SubnetUtil* > ** The method rangeCheck, pop, and format of SubnetUtils was moved into > SubnetUtils.SubnetInfo. > * The getAddressCount and getAllAddresses methods were reimplemented > ** For compatibility > * Moved IP4Subnet and IP6Subnet classes into the until package > h3. 3/23/17 > * *Renamed getAddressCount() to getAddressCountString()* > ** The old name, getAddressCount(), was the obsoleted name and confused others > * Removed the insignificant value representation, which are no reasons to be > defined in this class > * -Changes the path to SubnetInfo (SubnetUtilsExample.java and > SubnetUtilsTest.java)- > * -Replaced getAddressCount to getAddressLong in the SubnetUtilsTest class- > * Improved comments > https://github.com/apache/commons-net/pull/25 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (NET-629) NET-629 Added IP4Subnet and IP6Subnet classes
[ https://issues.apache.org/jira/browse/NET-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi closed NET-629. Resolution: Done > NET-629 Added IP4Subnet and IP6Subnet classes > - > > Key: NET-629 > URL: https://issues.apache.org/jira/browse/NET-629 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > IP4Subnet and IP6Subnet classes which provide subnet summary information for > each IP address version. > Change log > * The method rangeCheck, pop, and format of SubnetUtils was moved to > SubnetInfo in the subnet package. > * Added asInteger, getCidrSignature, and getAllAddresses methods of > SubnetUtils.SubnetInfo to SubnetInfo in the subnet package. > * Changed the parameter type of isInRange from short array to integer array. > * Renamed getAddressCount() to getAddressCountString() > ** The old name, getAddressCount(), was the obsoleted name and confused > others. > * Improved comments -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (NET-629) NET-629 Added IP4Subnet and IP6Subnet classes
[ https://issues.apache.org/jira/browse/NET-629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Makoto Sakaguchi updated NET-629: - Description: IP4Subnet and IP6Subnet classes which provide subnet summary information for each IP address version. Change log * The method rangeCheck, pop, and format of SubnetUtils was moved to SubnetInfo in the subnet package. * Added asInteger, getCidrSignature, and getAllAddresses methods of SubnetUtils.SubnetInfo to SubnetInfo in the subnet package. * Changed the parameter type of isInRange from short array to integer array. * Renamed getAddressCount() to getAddressCountString() ** The old name, getAddressCount(), was the obsoleted name and confused others. * Improved comments was: IP4Subnet and IP6Subnet classes which provide subnet summary information for each IP address version. Change log * The method rangeCheck, pop, and format of SubnetUtils was moved to SubnetInfo in the subnet package. * Added asInteger, getCidrSignature, and getAllAddresses methods of SubnetUtils.SubnetInfo to SubnetInfo in the subnet package. * Changed the parameter type of isInRange from short array to integer array. * Renamed getAddressCount() to getAddressCountString() ** The old name, getAddressCount(), was the obsoleted name and confused others. * Improved comments https://github.com/apache/commons-net/pull/22 > NET-629 Added IP4Subnet and IP6Subnet classes > - > > Key: NET-629 > URL: https://issues.apache.org/jira/browse/NET-629 > Project: Commons Net > Issue Type: Sub-task >Reporter: Makoto Sakaguchi > > IP4Subnet and IP6Subnet classes which provide subnet summary information for > each IP address version. > Change log > * The method rangeCheck, pop, and format of SubnetUtils was moved to > SubnetInfo in the subnet package. > * Added asInteger, getCidrSignature, and getAllAddresses methods of > SubnetUtils.SubnetInfo to SubnetInfo in the subnet package. > * Changed the parameter type of isInRange from short array to integer array. > * Renamed getAddressCount() to getAddressCountString() > ** The old name, getAddressCount(), was the obsoleted name and confused > others. > * Improved comments -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CODEC-231) StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE
[ https://issues.apache.org/jira/browse/CODEC-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-231. Resolution: Fixed Fix Version/s: 1.11 URL: http://svn.apache.org/viewvc?rev=1788777=rev Log: CODEC-231 StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE Modified: commons/proper/codec/trunk/src/changes/changes.xml commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/StringUtils.java commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/binary/StringUtilsTest.java > StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String > Index OBE > - > > Key: CODEC-231 > URL: https://issues.apache.org/jira/browse/CODEC-231 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10 >Reporter: Sebb > Fix For: 1.11 > > > StringUtils.equals(CharSequence cs1, CharSequence cs2) fails with String > Index OBE if the two sequences are different lengths. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CODEC-231) StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE
[ https://issues.apache.org/jira/browse/CODEC-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CODEC-231: --- Issue Type: Bug (was: Improvement) > StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String > Index OBE > - > > Key: CODEC-231 > URL: https://issues.apache.org/jira/browse/CODEC-231 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10 >Reporter: Sebb > Fix For: 1.11 > > > StringUtils.equals(CharSequence cs1, CharSequence cs2) fails with String > Index OBE if the two sequences are different lengths. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CODEC-231) StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE
[ https://issues.apache.org/jira/browse/CODEC-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated CODEC-231: --- Affects Version/s: 1.10 > StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String > Index OBE > - > > Key: CODEC-231 > URL: https://issues.apache.org/jira/browse/CODEC-231 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.10 >Reporter: Sebb > > StringUtils.equals(CharSequence cs1, CharSequence cs2) fails with String > Index OBE if the two sequences are different lengths. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CODEC-231) StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE
Sebb created CODEC-231: -- Summary: StringUtils.equals(CharSequence cs1, CharSequence cs2) can fail with String Index OBE Key: CODEC-231 URL: https://issues.apache.org/jira/browse/CODEC-231 Project: Commons Codec Issue Type: Improvement Reporter: Sebb StringUtils.equals(CharSequence cs1, CharSequence cs2) fails with String Index OBE if the two sequences are different lengths. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (EMAIL-171) buildMimeMessage() unconditionally encodes and folds header values
[ https://issues.apache.org/jira/browse/EMAIL-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated EMAIL-171: --- Description: The buildMimeMessage() method unconditionally calls MimeUtility#fold and MimeUtility#encodeText for all entries in the headers Map. However the encodeText method is only suitable for "unstructured" RFC 822 headers, i.e. those which consist of arbitrary text. If the headers Map contains any keys that have structured values, and the value contains any non-ASCII characters, the generated header may be corrupted. If the user adds a structured header to the Map, they need to ensure that the value is already ASCII-encoded using the appropriate strategy for the field. This needs to be documented. was: The buildMimeMessage() method unconditionally calls MimeUtility#fold and MimeUtility#encodeText for all entries in the headers Map. However the encodeText method is only suitable for "unstructured" RFC 822 headers, i.e. those which consist of arbitrary text. If the headers Map contains any keys that have structured values, and the value contains any non-ASCII characters, then generated header may be corrupted. If the user adds a structured header to the Map, they need to ensure that the value is already ASCII-encoded using the appropriate strategy for the field. This needs to be documented. > buildMimeMessage() unconditionally encodes and folds header values > -- > > Key: EMAIL-171 > URL: https://issues.apache.org/jira/browse/EMAIL-171 > Project: Commons Email > Issue Type: Bug >Reporter: Sebb > > The buildMimeMessage() method unconditionally calls MimeUtility#fold and > MimeUtility#encodeText for all entries in the headers Map. > However the encodeText method is only suitable for "unstructured" RFC 822 > headers, i.e. those which consist of arbitrary text. > If the headers Map contains any keys that have structured values, and the > value contains any non-ASCII characters, the generated header may be > corrupted. > If the user adds a structured header to the Map, they need to ensure that the > value is already ASCII-encoded using the appropriate strategy for the field. > This needs to be documented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (EMAIL-171) buildMimeMessage() unconditionally encodes and folds header values
[ https://issues.apache.org/jira/browse/EMAIL-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated EMAIL-171: --- Summary: buildMimeMessage() unconditionally encodes and folds header values (was: buildMimeMessage() unconditionally encodes and folders header values) > buildMimeMessage() unconditionally encodes and folds header values > -- > > Key: EMAIL-171 > URL: https://issues.apache.org/jira/browse/EMAIL-171 > Project: Commons Email > Issue Type: Bug >Reporter: Sebb > > The buildMimeMessage() method unconditionally calls MimeUtility#fold and > MimeUtility#encodeText for all entries in the headers Map. > However the encodeText method is only suitable for "unstructured" RFC 822 > headers, i.e. those which consist of arbitrary text. > If the headers Map contains any keys that have structured values, and the > value contains any non-ASCII characters, then generated header may be > corrupted. > If the user adds a structured header to the Map, they need to ensure that the > value is already ASCII-encoded using the appropriate strategy for the field. > This needs to be documented. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user sebbASF commented on the issue: https://github.com/apache/commons-lang/pull/231 looks good --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (CONFIGURATION-655) Reading configuration from InputStream - improvement
[
https://issues.apache.org/jira/browse/CONFIGURATION-655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942427#comment-15942427
]
Oliver Heger commented on CONFIGURATION-655:
Thanks for creating this ticket. There is for sure room for improvements in
this area.
Currently, I don't have yet a bright idea how to integrate better support for
streams into the existing API. It is certainly preferrable to use already
existing concepts rather than inventig something completely new. So would it be
possible to extend the {{FileLocator}} and {{FileHandler}} classes in a way
that an input stream could be specified similar to a File or an URL? We could
for instance introduce a {{StreamProvider}} interface which just has a
_getInputStream()_ method. Such a provider would become a property of
{{FileLocator}} and {{FileHandler}}, and it would also be supported by
file-based builder parameters.
With such extensions one could create a configuration in the following way:
{code}
XMLConfiguration cfg = new
FileBasedConfigurationBuilder<>(XMLConfiguration.class)
.configure(new Parameters().xml().setStreamProvider(new MyStreamProvider()))
.getConfiguration();
{code}
I am not yet sure how this approach would affect the current loading mechanism
and the file location strategy (which operates on URLs rather than streams).
Probably, a {{StreamProvider}} would take precedence over other properties.
Some experiments would need to be done to verify that nothing gets broken.
But would you in general agree to such an approach or do you have other
suggestions?
> Reading configuration from InputStream - improvement
>
>
> Key: CONFIGURATION-655
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-655
> Project: Commons Configuration
> Issue Type: Improvement
>Reporter: Rafał Figas
>
> The point of this improvement is better handling of configurations loaded
> from input streams.
> Currently to load configuration from input stream following code should be
> used:
> {code}
> XMLConfiguration cfg = new
> BasicConfigurationBuilder<>(XMLConfiguration.class).configure(new
> Parameters().xml()).getConfiguration();
> FileHandler fh = new FileHandler(cfg);
> fh.load(stream);
> {code}
> In general this looks a little bit odd, because FileHandler is involved, what
> suggests that configuration has something to do with file, while it is not
> necessary true. Maybe it would be clearer if either builder, or configuration
> would be responsible for loading data. I think builder would be even better,
> because what I expect from builder is to get the configuration object that is
> complete, contains data and I can work with it's content. From where I get
> the data should be responsibility of builder. And if I want to save such
> configuration I should be able to get it as string for example (or byte array
> or stream) and it is my own responsibility of what will I do with it (save to
> file, push to webservice etc.).
> AFAIR there is also some kind of configuratio autoupdate feature, but what
> comes first to my mind is to add such feature to builder. Then builder could
> create a configuration that is wrapped in appropriate handler responsible for
> saving updates.
> Just a few humble suggestions that could improve working with this nice
> library :-). I believe that minimum improvement would be a clear remark in
> user guide how to load configuration from stream in current version as it is
> not obvious.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (CODEC-91) Handling of embedded padding in base64 encoded data changed in 1.4
[
https://issues.apache.org/jira/browse/CODEC-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=12875013#comment-12875013
]
Sebb edited comment on CODEC-91 at 3/26/17 6:59 PM:
I'm clearly in favour of the current behaviour: Any non-blank characters
following the *proper* number of pad characters indicates a broken data stream.
Note, that the user is able to achieve his strange wish by parsing the data
stream with a simpe regex before handling it over to commons codec. For example
(not verified, in particular not for performance, just to give an impression):
{code}
String base64String = "Y29tbW9ucwo=Y29tbW9ucwo=";
Pattern p = Pattern.compile("\\=([^\\=\\s])");
for (;;) {
Matcher m = p.matcher(base64String);
while (m.find()) {
base64String = m.replaceFirst(m.group(1));
}
}
{code}
was (Author: joc...@apache.org):
I'm clearly in favour of the current behaviour: Any non-blank characters
following the *proper* number of pad characters indicates a broken data stream.
Note, that the user is able to achieve his strange wish by parsing the data
stream with a simpe regex before handling it over to commons codec. For example
(not verified, in particular not for performance, just to give an impression):
String base64String = "Y29tbW9ucwo=Y29tbW9ucwo=";
Pattern p = Pattern.compile("\\=([^\\=\\s])");
for (;;) {
Matcher m = p.matcher(base64String);
while (m.find()) {
base64String = m.replaceFirst(m.group(1));
}
}
> Handling of embedded padding in base64 encoded data changed in 1.4
> --
>
> Key: CODEC-91
> URL: https://issues.apache.org/jira/browse/CODEC-91
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Chris Pimlott
>Assignee: Julius Davies
> Fix For: 1.x
>
> Attachments: codec-91-actually-works-and-tests-yay.patch
>
>
> 1.4 changed the way that embedded padding characters (i.e. "=") were handled
> when decoding base64 data. Previously, the decoder ignored them and decoded
> all the data. Now it stops upon encountering the first padding byte. This
> breaks compatibility with previous versions.
> For example, in 1.4,
> b64.decode("Y29tbW9ucwo=".getBytes());
> gives the same result as
> b64.decode("Y29tbW9ucwo=Y29tbW9ucwo=".getBytes());
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942402#comment-15942402 ] ASF GitHub Bot commented on LANG-1317: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 You are right. The method signature I suggested omits the important super part. I agree it should be something like `getMethodsWithAnnotation(Class cls, annotationCls, boolean searchSupers, boolean ignoreAccess)`. (I'm not a fan of boolean parameters (especially multiple ones), so if somebody has an idea for a good method name, that is welcome.) > Add findAnnotation and findMethodsWithAnnotation to MethodUtils > --- > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 You are right. The method signature I suggested omits the important super part. I agree it should be something like `getMethodsWithAnnotation(Class cls, annotationCls, boolean searchSupers, boolean ignoreAccess)`. (I'm not a fan of boolean parameters (especially multiple ones), so if somebody has an idea for a good method name, that is welcome.) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (CODEC-166) Base64 could be faster
[
https://issues.apache.org/jira/browse/CODEC-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-166:
---
Issue Type: Wish (was: Bug)
> Base64 could be faster
> --
>
> Key: CODEC-166
> URL: https://issues.apache.org/jira/browse/CODEC-166
> Project: Commons Codec
> Issue Type: Wish
>Affects Versions: 1.7
>Reporter: Julius Davies
>Assignee: Julius Davies
> Fix For: 2.0
>
> Attachments: base64bench.zip, CODEC-166.patch, CODEC-166_speed.patch
>
>
> Our Base64 consistently performs 3 times slower compared to MiGBase64 and
> iHarder in the byte[] and String encode() methods.
> We are pretty good on decode(), though a little slower (approx. 33% slower)
> than MiGBase64.
> We always win in the Streaming methods (MiGBase64 doesn't do streaming).
> Yay! :-) :-) :-)
> I put together a benchmark. Here's a typical run:
> {noformat}
> LARGE DATA new byte[12345]
> iHarder...
> encode 486.0 MB/sdecode 158.0 MB/s
> encode 491.0 MB/sdecode 148.0 MB/s
> MiGBase64...
> encode 499.0 MB/sdecode 222.0 MB/s
> encode 493.0 MB/sdecode 226.0 MB/s
> Apache Commons Codec...
> encode 142.0 MB/sdecode 146.0 MB/s
> encode 138.0 MB/sdecode 150.0 MB/s
> {noformat}
> I believe the main approach we can consider to improve performance is to
> avoid array copies at all costs. MiGBase64 even counts the number of valid
> Base64 characters ahead of time on decode() to precalculate the result's size
> and avoid any array copying!
> I suspect this will mean writing out separate execution paths for the String
> and byte[] methods, and keeping them out of the streaming logic, since the
> streaming logic is founded on array copy.
> Unfortunately this means we will diminish internal reuse of the streaming
> implementation, but I think it's the only way to improve performance, if we
> want to.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942390#comment-15942390 ] ASF GitHub Bot commented on LANG-1317: -- Github user yasserzamani commented on the issue: https://github.com/apache/commons-lang/pull/261 @PascalSchumacher , thank you! I was overloaded by another job and forgot that I also can use method overloads. Yes, strongly I agree. Just I have some doubts about name `ignoreAccessiblitiy` because the new method is not only about accessibility, but also about traverse super classes and implemented interface and super interfaces while the annotation maybe is not present on the given class but is present on lower layers. Maybe we should also add another param named `searchSupers` for example. > Add findAnnotation and findMethodsWithAnnotation to MethodUtils > --- > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CODEC-230) URLCodec.WWW_FORM_URL should be private
[ https://issues.apache.org/jira/browse/CODEC-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-230. Resolution: Fixed Fix Version/s: 1.11 URL: http://svn.apache.org/viewvc?rev=1788761=rev Log: CODEC-230 URLCodec.WWW_FORM_URL should be private Modified: commons/proper/codec/trunk/src/changes/changes.xml commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/net/URLCodec.java > URLCodec.WWW_FORM_URL should be private > --- > > Key: CODEC-230 > URL: https://issues.apache.org/jira/browse/CODEC-230 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.10 >Reporter: Sebb > Fix For: 1.11 > > > URLCodec.WWW_FORM_URL is mutable and should be made private. > Otherwise subclasses can change the array accidentally or deliberately. > However this would change the API for sub-classes. > A work-round would be to create a parallel private field and keep > WWW_FORM_URL as a copy, but marked deprecated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user yasserzamani commented on the issue: https://github.com/apache/commons-lang/pull/261 @PascalSchumacher , thank you! I was overloaded by another job and forgot that I also can use method overloads. Yes, strongly I agree. Just I have some doubts about name `ignoreAccessiblitiy` because the new method is not only about accessibility, but also about traverse super classes and implemented interface and super interfaces while the annotation maybe is not present on the given class but is present on lower layers. Maybe we should also add another param named `searchSupers` for example. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (CODEC-126) Make org.apache.commons.codec.net.URLCodec charset field final
[ https://issues.apache.org/jira/browse/CODEC-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942386#comment-15942386 ] Sebb commented on CODEC-126: Should also be converted to a Charset and made private > Make org.apache.commons.codec.net.URLCodec charset field final > --- > > Key: CODEC-126 > URL: https://issues.apache.org/jira/browse/CODEC-126 > Project: Commons Codec > Issue Type: Improvement >Affects Versions: 1.5 > Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500) > Maven home: C:\Java\apache-maven-3.0.3\bin\.. > Java version: 1.6.0_24, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_24\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.0 > > > Make org.apache.commons.codec.net.URLCodec charset field final. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CODEC-229) StringUtils.newStringxxx(null) should return null, not NPE
[
https://issues.apache.org/jira/browse/CODEC-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved CODEC-229.
Resolution: Fixed
Fix Version/s: 1.11
URL: http://svn.apache.org/viewvc?rev=1788755=rev
Log:
CODEC-229 StringUtils.newStringxxx(null) should return null, not NPE
Modified:
commons/proper/codec/trunk/src/changes/changes.xml
commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/StringUtils.java
commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/binary/StringUtilsTest.java
> StringUtils.newStringxxx(null) should return null, not NPE
> --
>
> Key: CODEC-229
> URL: https://issues.apache.org/jira/browse/CODEC-229
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Sebb
> Fix For: 1.11
>
>
> Method calls such as StringUtils.newStringIso8859_1(null) should return null,
> not NPE.
> It looks like this capability was lost with the fix for CODEC-136, i.e.
> http://svn.apache.org/viewvc?rev=1306366=rev
> Several methods were changed from
> {code}
> return StringUtils.newString(bytes, CharEncoding.xxx);
> to
> return new String(bytes, Charsets.xxx);
> {code}
> The new code should have been:
> {code}
> return newString(bytes, Charsets.xxx);
> {code}
> The newString method handles null input.
> There were no tests for null input so the change in behaviour was missed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CODEC-229) StringUtils.newStringxxx(null) should return null, not NPE
[
https://issues.apache.org/jira/browse/CODEC-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb updated CODEC-229:
---
Affects Version/s: 1.10
> StringUtils.newStringxxx(null) should return null, not NPE
> --
>
> Key: CODEC-229
> URL: https://issues.apache.org/jira/browse/CODEC-229
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Sebb
>
> Method calls such as StringUtils.newStringIso8859_1(null) should return null,
> not NPE.
> It looks like this capability was lost with the fix for CODEC-136, i.e.
> http://svn.apache.org/viewvc?rev=1306366=rev
> Several methods were changed from
> {code}
> return StringUtils.newString(bytes, CharEncoding.xxx);
> to
> return new String(bytes, Charsets.xxx);
> {code}
> The new code should have been:
> {code}
> return newString(bytes, Charsets.xxx);
> {code}
> The newString method handles null input.
> There were no tests for null input so the change in behaviour was missed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CODEC-230) URLCodec.WWW_FORM_URL should be private
Sebb created CODEC-230: -- Summary: URLCodec.WWW_FORM_URL should be private Key: CODEC-230 URL: https://issues.apache.org/jira/browse/CODEC-230 Project: Commons Codec Issue Type: Bug Affects Versions: 1.10 Reporter: Sebb URLCodec.WWW_FORM_URL is mutable and should be made private. Otherwise subclasses can change the array accidentally or deliberately. However this would change the API for sub-classes. A work-round would be to create a parallel private field and keep WWW_FORM_URL as a copy, but marked deprecated. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/231 @sebbASF What do you think about the latest changes? Is this pull request ready for merging? Thanks, Pascal --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942375#comment-15942375 ] ASF GitHub Bot commented on LANG-1317: -- Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 Thanks for the pull request! It is really unfortunate that the existing method `getMethodsWithAnnotation` is not called `getAccessibleMethodsWithAnnotation` : (, because then the new method could be called `getMethodsWithAnnotation`. I would not have been able to tell the difference between `getMethodsWithAnnotation` and `findMethodsWithAnnotation` without reading the javadoc. I believe we need a more intention revealing method name or maybe we should just add an overload of `getMethodsWithAnnotation` e.g. `getMethodsWithAnnotation(Class cls, annotationCls, boolean ignoreAccessiblitiy)`. What do you think? > Add findAnnotation and findMethodsWithAnnotation to MethodUtils > --- > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/261 Thanks for the pull request! It is really unfortunate that the existing method `getMethodsWithAnnotation` is not called `getAccessibleMethodsWithAnnotation` : (, because then the new method could be called `getMethodsWithAnnotation`. I would not have been able to tell the difference between `getMethodsWithAnnotation` and `findMethodsWithAnnotation` without reading the javadoc. I believe we need a more intention revealing method name or maybe we should just add an overload of `getMethodsWithAnnotation` e.g. `getMethodsWithAnnotation(Class cls, annotationCls, boolean ignoreAccessiblitiy)`. What do you think? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (CODEC-229) StringUtils.newStringxxx(null) should return null, not NPE
Sebb created CODEC-229:
--
Summary: StringUtils.newStringxxx(null) should return null, not NPE
Key: CODEC-229
URL: https://issues.apache.org/jira/browse/CODEC-229
Project: Commons Codec
Issue Type: Bug
Reporter: Sebb
Method calls such as StringUtils.newStringIso8859_1(null) should return null,
not NPE.
It looks like this capability was lost with the fix for CODEC-136, i.e.
http://svn.apache.org/viewvc?rev=1306366=rev
Several methods were changed from
{code}
return StringUtils.newString(bytes, CharEncoding.xxx);
to
return new String(bytes, Charsets.xxx);
{code}
The new code should have been:
{code}
return newString(bytes, Charsets.xxx);
{code}
The newString method handles null input.
There were no tests for null input so the change in behaviour was missed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CODEC-136) Use Charset objects when possible, create Charsets class for required character encodings
[ https://issues.apache.org/jira/browse/CODEC-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942343#comment-15942343 ] Sebb commented on CODEC-136: URL: http://svn.apache.org/viewvc?rev=1306366=rev Log: [CODEC-136] Use Charset objects when possible, create Charsets for required character encodings. Added: commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java commons/proper/codec/trunk/src/test/java/org/apache/commons/codec/CharsetsTest.java Modified: commons/proper/codec/trunk/pom.xml commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/binary/StringUtils.java > Use Charset objects when possible, create Charsets class for required > character encodings > - > > Key: CODEC-136 > URL: https://issues.apache.org/jira/browse/CODEC-136 > Project: Commons Codec > Issue Type: New Feature > Environment: Apache Maven 3.0.4 (r1232337; 2012-01-17 03:44:56-0500) > Maven home: C:\Java\apache-maven-3.0.4\bin\.. > Java version: 1.6.0_31, vendor: Sun Microsystems Inc. > Java home: C:\Program Files\Java\jdk1.6.0_31\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.7 > > > Use Charset objects when possible, create Charsets for required character > encodings. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CODEC-228) URLCodec.decode does not throw DecoderException with invalid UTF-8
[
https://issues.apache.org/jira/browse/CODEC-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942341#comment-15942341
]
Sebb commented on CODEC-228:
This is because the code uses
new String(decoded_bytes, charset)
to convert the result, and the behaviour of that ctor is unspecified for bytes
that are invalid.
There are probably other instances of this in the code base.
> URLCodec.decode does not throw DecoderException with invalid UTF-8
> --
>
> Key: CODEC-228
> URL: https://issues.apache.org/jira/browse/CODEC-228
> Project: Commons Codec
> Issue Type: Bug
>Affects Versions: 1.10
>Reporter: Andrew Gaul
>
> I expect the following to throw {{DecoderException}}:
> {code:java}
> new URLCodec().decode("%AE%8A-", "UTF-8");
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-654) Add optionalConfigurationAt method to HierarchicalConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942338#comment-15942338 ] Oliver Heger commented on CONFIGURATION-654: Sounds like a reasonable enhancement. I like the variant which returns an Optional best, but unfortunately, [configuration] is still on Java 6 (we might go to 7 soon); so we will probably have to stick with a *null* return value. Any chance that you could provide a patch? > Add optionalConfigurationAt method to HierarchicalConfiguration > --- > > Key: CONFIGURATION-654 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-654 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Rafał Figas > Labels: easyfix > > It would be nice to have method similar to configurationAt, but expecting > that there is one or no configuration at given key. > Currently there is no easy way to handle optional node in configuration. One > has to handle exception from configurationAt or use configurationsAt and do > various checks on collection size. > Method optionalConfigurationAt could return configuration at given key if > exactly one exists, return empty Optional or null, when there is no node, > exception when more then one node exists. > Method could throw exception like "UnexpectedMultipleNodesException' > containing key name, what would be helpful for clear error handling. > It would be very helpful while handling optional nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1317) Add findAnnotation and findMethodsWithAnnotation to MethodUtils
[ https://issues.apache.org/jira/browse/LANG-1317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15942195#comment-15942195 ] ASF GitHub Bot commented on LANG-1317: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/10775689) Coverage decreased (-0.002%) to 94.603% when pulling **e49a3a2099759f5fee2423aff2b9fa762881c36b on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. > Add findAnnotation and findMethodsWithAnnotation to MethodUtils > --- > > Key: LANG-1317 > URL: https://issues.apache.org/jira/browse/LANG-1317 > Project: Commons Lang > Issue Type: Improvement > Components: lang.reflect.* >Reporter: Yasser Zamani > Labels: patch > > In order to fix WW-4744 , mainly, I am going to add two functionalities to > MethodUtils: findAnnotation and findMethodsWithAnnotation. > findAnnotation will be an extension for Method.getAnnotation that also > searches interfaces and super classes while caching results with no memory > leak. > findMethodsWithAnnotation will be an extension for getMethodsWithAnnotation > that also supports non public methods, super class and interface methods, > again, while caching results as above. > Generally, do you agree with these in a pull request? If so, I will be > working on it :) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #261: LANG-1317: Add findAnnotation and findMethodsWithAn...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/261 [](https://coveralls.io/builds/10775689) Coverage decreased (-0.002%) to 94.603% when pulling **e49a3a2099759f5fee2423aff2b9fa762881c36b on yasserzamani:LANG-1317** into **4a300fee2ef1c03902d0fb25ceb02aa01d0fab46 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
