[jira] [Commented] (CODEC-225) InputStream not closed

2016-09-13 Thread Gary Gregory (JIRA) 

[ 
https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488816#comment-15488816
 ] 

Gary Gregory commented on CODEC-225:


DaitchMokotoffSoundex: This a false positive. In general, an input source does 
not need to be closed when it is fed into a scanner because closing the scanner 
closes the input stream. You will only loose the stream if there is an 
exception thrown in parseRules(), which can only happen if the rules file 
built-in the jar is broken. Unlikely to happen yet theoretically possible. So 
closing both the stream and scanner is redundant.

I think I'll do a pass over the whole code based and use try-with-resources 
statements once we move on to Java 7, which will make all of this cleaner.

My plan is to:
- release 1.11 when I get a chance or someone else volunteers
- update to Java 7
- Use try-with-resource blocks.

> InputStream not closed
> --
>
> Key: CODEC-225
> URL: https://issues.apache.org/jira/browse/CODEC-225
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10, 1.11
>Reporter: Svetlin Zarev
>
> After running static code analysis on common codecs we discovered that it 
> leaks file descriptors. The relevant locations are:
> * DaitchMokotoffSoundex -> the static initializer on line 229 
> * Rule -> the static initializer on line 212 and the parseRules() method on 
> line 438.
> patch provided via github pull request.
> This issue is relevant for web app deployments on OSes (like windows) that 
> lock the files if ther eare open streams to them, and will prevent 
> application undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (LANG-1134) New methods for lang3.Validate

2016-09-13 Thread Stardust (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15488714#comment-15488714
 ] 

Stardust commented on LANG-1134:


I addressed the issues discussed here.
I'm still not happy with the "Object" suffix for the comparison methods, but as 
far as I can tell nothing better has been suggested.
"differentObject" is problematic. While I think it will be clear to anyone what 
this method does, it somehow sounds like an identity test to me.

Also, I did as you told me last year to make new changes: edit the files and 
make a new pull request. Thing is there has been other commits since my 
original one and I didn't have the new files in my branch, I'm guessing this is 
why Github is reporting a conflict. I do not know how to solve this.

> New methods for lang3.Validate
> --
>
> Key: LANG-1134
> URL: https://issues.apache.org/jira/browse/LANG-1134
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.*
>Affects Versions: 3.4
>Reporter: Stardust
>Assignee: Charles Honton
>Priority: Minor
> Fix For: 3.5
>
>
> These are suggestions for new methods for the Validate class.
> h1. Floating point values
> h2. notNaN(value)
> Throws an exception if value != value .
> {code}double value;
> value = Double.NaN;
> Validate.notNaN(value);// Throws exception
> value = 1.0;
> Validate.notNaN(value);// Validates
> value = Double.POSITIVE_INFINITY;
> Validate.notNaN(value);// Validates{code}
> h2. finite(value)
> Validates that the argument contains a numeric value (not NaN or infinite).
> {code}double value;
> value = Double.NaN;
> Validate.finite(value);// Throws exception
> value = Double.POSITIVE_INFINITY;
> Validate.finite(value);// Throws exception
> value = 1.0;
> Validate.finite(value);// Validates{code}
> h1. Integers and floats
> The following methods are overloaded to accept both integers and floating 
> point values.
> h2. greater(reference, value), greaterOrEqual(reference, value)
> Ensures the argument is greater than (or equal to) a given value.
> {code}double value;
> value = 0.0;
> Validate.greater(0.0, value);// Throws exception
> Validate.greaterOrEqual(0.0, value); // Validates
> value = Double.POSITIVE_INFINITY;
> Validate.greater(0.0, value);// Validates
> value = Double.NaN;
> Validate.greater(0.0, value);// Throws exception{code}
> h2. smaller(reference, value), smallerOrEqual(reference, value)
> Ensures the argument is smaller than (or equal to) a given value. Does the 
> opposite of greater(), see example above.
> h2. different(reference, value)
> Ensures the argument is not equal to a given value. A typical use case would 
> be to accept only non-zero values.
> {code}double value;
> value = 0.0;
> Validate.different(0.0, value);// Throws exception
> Validate.different(1.0, value);// Validates
> value = Double.NaN;
> Validate.different(0.0, value);// Validates{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #190: Lang 1134

2016-09-13 Thread Lady-Stardust 
GitHub user Lady-Stardust opened a pull request:

https://github.com/apache/commons-lang/pull/190

Lang 1134

Addressed concerns discussed on JIRA.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Lady-Stardust/commons-lang LANG-1134

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/190.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 #190


commit 0595a9828a4b0d1aa41d96b5606fbc91626bf324
Author: Lady-Stardust <>
Date:   2015-05-10T01:31:53Z

Added new methods, see LANG-1134

commit da892402f40cfa30f8b6ff9659020ba16a9027af
Author: Stardust 
Date:   2015-05-10T01:35:04Z

Added new methods, see LANG-1134

commit a510dcf2a5a0fc431731ff506aef7589198eb5a5
Author: Lady-Stardust <>
Date:   2015-05-10T01:35:04Z

Added new methods, see LANG-1134

commit f9c313145eb42d4317268e06a9f880e87ebffa5c
Author: Stardust 
Date:   2015-05-10T01:42:22Z

Merge origin/LANG-1134 into LANG-1134

commit 41e83754024b6b7f32063f7d8bd511d88edb2ff7
Author: Lady-Stardust <>
Date:   2015-05-15T00:30:25Z

Fixed code to use Double.isNaN(); fixed parameter order; fixed comments

commit 77c32a39c8a22dbd20bc9d9a5231d25c300cb48d
Author: Lady-Stardust <>
Date:   2016-09-13T22:45:07Z

Fixed method names; fixed differentObject to use Object.equals




---
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-225) InputStream not closed

2016-09-13 Thread Svetlin Zarev (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svetlin Zarev updated CODEC-225:

Flags: Patch  (was: Patch,Important)

> InputStream not closed
> --
>
> Key: CODEC-225
> URL: https://issues.apache.org/jira/browse/CODEC-225
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10, 1.11
>Reporter: Svetlin Zarev
>
> After running static code analysis on common codecs we discovered that it 
> leaks file descriptors. The relevant locations are:
> * DaitchMokotoffSoundex -> the static initializer on line 229 
> * Rule -> the static initializer on line 212 and the parseRules() method on 
> line 438.
> patch provided via github pull request.
> This issue is relevant for web app deployments on OSes (like windows) that 
> lock the files if ther eare open streams to them, and will prevent 
> application undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CODEC-225) InputStream not closed

2016-09-13 Thread Svetlin Zarev (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Svetlin Zarev updated CODEC-225:

Affects Version/s: 1.11
   1.10

> InputStream not closed
> --
>
> Key: CODEC-225
> URL: https://issues.apache.org/jira/browse/CODEC-225
> Project: Commons Codec
>  Issue Type: Bug
>Affects Versions: 1.10, 1.11
>Reporter: Svetlin Zarev
>
> After running static code analysis on common codecs we discovered that it 
> leaks file descriptors. The relevant locations are:
> * DaitchMokotoffSoundex -> the static initializer on line 229 
> * Rule -> the static initializer on line 212 and the parseRules() method on 
> line 438.
> patch provided via github pull request.
> This issue is relevant for web app deployments on OSes (like windows) that 
> lock the files if ther eare open streams to them, and will prevent 
> application undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CODEC-225) InputStream not closed

2016-09-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/CODEC-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486887#comment-15486887
 ] 

ASF GitHub Bot commented on CODEC-225:
--

GitHub user SvetlinZarev opened a pull request:

https://github.com/apache/commons-codec/pull/5

Do not leak file descriptors

Bug: CODEC-225

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/SvetlinZarev/commons-codec StreamLeaks

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-codec/pull/5.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 #5


commit b93405af5abb1f59c87e49d271c4f39ab034868b
Author: Svetlin Zarev 
Date:   2016-09-13T10:29:17Z

Do not leak file descriptors

Bug: CODEC-225




> InputStream not closed
> --
>
> Key: CODEC-225
> URL: https://issues.apache.org/jira/browse/CODEC-225
> Project: Commons Codec
>  Issue Type: Bug
>Reporter: Svetlin Zarev
>
> After running static code analysis on common codecs we discovered that it 
> leaks file descriptors. The relevant locations are:
> * DaitchMokotoffSoundex -> the static initializer on line 229 
> * Rule -> the static initializer on line 212 and the parseRules() method on 
> line 438.
> patch provided via github pull request.
> This issue is relevant for web app deployments on OSes (like windows) that 
> lock the files if ther eare open streams to them, and will prevent 
> application undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CODEC-225) InputStream not closed

2016-09-13 Thread Svetlin Zarev (JIRA) 
Svetlin Zarev created CODEC-225:
---

 Summary: InputStream not closed
 Key: CODEC-225
 URL: https://issues.apache.org/jira/browse/CODEC-225
 Project: Commons Codec
  Issue Type: Bug
Reporter: Svetlin Zarev


After running static code analysis on common codecs we discovered that it leaks 
file descriptors. The relevant locations are:

* DaitchMokotoffSoundex -> the static initializer on line 229 
* Rule -> the static initializer on line 212 and the parseRules() method on 
line 438.

patch provided via github pull request.

This issue is relevant for web app deployments on OSes (like windows) that lock 
the files if ther eare open streams to them, and will prevent application 
undeployment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #189: new impl of LevenshteinDistance

2016-09-13 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/189
  

[![Coverage 
Status](https://coveralls.io/builds/7859475/badge)](https://coveralls.io/builds/7859475)

Coverage increased (+0.02%) to 93.592% when pulling 
**aa5b88ec1012a738bfd24d21ed91e88b3edd094d on yufcuy:master** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 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.
---

[GitHub] commons-lang issue #189: new impl of LevenshteinDistance

2016-09-13 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/189
  

[![Coverage 
Status](https://coveralls.io/builds/7859475/badge)](https://coveralls.io/builds/7859475)

Coverage increased (+0.02%) to 93.592% when pulling 
**aa5b88ec1012a738bfd24d21ed91e88b3edd094d on yufcuy:master** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 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.
---

[GitHub] commons-lang pull request #189: new impl of LevenshteinDistance

2016-09-13 Thread yufcuy 
GitHub user yufcuy opened a pull request:

https://github.com/apache/commons-lang/pull/189

new impl of LevenshteinDistance



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yufcuy/commons-lang master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/189.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 #189


commit aa5b88ec1012a738bfd24d21ed91e88b3edd094d
Author: yufcuy 
Date:   2016-09-13T09:38:00Z

new impl of LevenshteinDistance




---
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-1266) Add alphabet converter

2016-09-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486640#comment-15486640
 ] 

ASF GitHub Bot commented on LANG-1266:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/188
  

[![Coverage 
Status](https://coveralls.io/builds/7858389/badge)](https://coveralls.io/builds/7858389)

Coverage decreased (-0.02%) to 93.559% when pulling 
**c1a5a638a3132f2048bb4113181460c3c660c2a8 on eyala:LANG-1266** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 on apache:master**.



> Add alphabet converter
> --
>
> Key: LANG-1266
> URL: https://issues.apache.org/jira/browse/LANG-1266
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.text.*
>Reporter: Eyal Allweil
>
> (as described in [the mailing 
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another - 
> for example, from unicode to latin, without using some of the chars in latin. 
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding, 
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than 
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've 
> added a human-readable toString implementation, and a constructor that can 
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
>  // always should be true
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #188: LANG-1266 Add alphabet converter

2016-09-13 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/188
  

[![Coverage 
Status](https://coveralls.io/builds/7858389/badge)](https://coveralls.io/builds/7858389)

Coverage decreased (-0.02%) to 93.559% when pulling 
**c1a5a638a3132f2048bb4113181460c3c660c2a8 on eyala:LANG-1266** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 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.
---

[jira] [Commented] (LANG-1266) Add alphabet converter

2016-09-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486639#comment-15486639
 ] 

ASF GitHub Bot commented on LANG-1266:
--

Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/188
  

[![Coverage 
Status](https://coveralls.io/builds/7858389/badge)](https://coveralls.io/builds/7858389)

Coverage decreased (-0.02%) to 93.559% when pulling 
**c1a5a638a3132f2048bb4113181460c3c660c2a8 on eyala:LANG-1266** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 on apache:master**.



> Add alphabet converter
> --
>
> Key: LANG-1266
> URL: https://issues.apache.org/jira/browse/LANG-1266
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.text.*
>Reporter: Eyal Allweil
>
> (as described in [the mailing 
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another - 
> for example, from unicode to latin, without using some of the chars in latin. 
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding, 
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than 
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've 
> added a human-readable toString implementation, and a constructor that can 
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
>  // always should be true
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang issue #188: LANG-1266 Add alphabet converter

2016-09-13 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/188
  

[![Coverage 
Status](https://coveralls.io/builds/7858389/badge)](https://coveralls.io/builds/7858389)

Coverage decreased (-0.02%) to 93.559% when pulling 
**c1a5a638a3132f2048bb4113181460c3c660c2a8 on eyala:LANG-1266** into 
**dad86bc0a29689fd29bf03b382a39621718e8b05 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.
---

[jira] [Commented] (LANG-1266) Add alphabet converter

2016-09-13 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/LANG-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15486628#comment-15486628
 ] 

ASF GitHub Bot commented on LANG-1266:
--

GitHub user eyala opened a pull request:

https://github.com/apache/commons-lang/pull/188

LANG-1266 Add alphabet converter

(as described in [the mailing 
list](http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e))

This is a utility class I wrote for converting from one alphabet to another 
- for example, from unicode to latin, without using some of the chars in latin. 
The usage looks like this:

```
Set originals; // a, b, c, d
Set encoding; // 0, 1, d
Set doNotEncode; // d

AlphabetConverter ac = AlphabetConverter.createConverter(originals, 
encoding, doNotEncode);

ac.encode("a"); // 00
ac.encode("b"); // 01
ac.encode("c"); // 0d
ac.encode("d"); // d
ac.encode("abcd"); // 00010dd
```
Of course, 

`x.equals(ac.decode(ac.encode(x)))`

 should always be true.

The implementation provided makes the encodings of fixed length, other than 
the "do not encode" chars, which remain as they are (length one).

In addition, in order to make it easier to preserve the encoding scheme, 
I've added a human-readable toString implementation, and a constructor that can 
recreate an AlphabetConverter from the encoding map, such that:
```

AlphabetConverter ac;


ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded())); 
// always should be true

```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/eyala/commons-lang LANG-1266

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/188.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 #188


commit c1a5a638a3132f2048bb4113181460c3c660c2a8
Author: eallweil 
Date:   2016-09-13T08:15:06Z

LANG-1266 Add alphabet converter




> Add alphabet converter
> --
>
> Key: LANG-1266
> URL: https://issues.apache.org/jira/browse/LANG-1266
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.text.*
>Reporter: Eyal Allweil
>
> (as described in [the mailing 
> list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])
> This is a utility class I wrote for converting from one alphabet to another - 
> for example, from unicode to latin, without using some of the chars in latin. 
> The usage looks like this:
> {code}
> Set originals; // a, b, c, d
> Set encoding; // 0, 1, d
> Set doNotEncode; // d
> AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding, 
> doNotEncode);
> ac.encode("a"); // 00
> ac.encode("b"); // 01
> ac.encode("c"); // 0d
> ac.encode("d"); // d
> ac.encode("abcd"); // 00010dd
> {code}
> Of course, x.equals(ac.decode(ac.encode(x))) should always be true.
> The implementation provided makes the encodings of fixed length, other than 
> the "do not encode" chars, which remain as they are (length one).
> In addition, in order to make it easier to preserve the encoding scheme, I've 
> added a human-readable toString implementation, and a constructor that can 
> recreate an AlphabetConverter from the encoding map, such that:
> {code}
> AlphabetConverter ac;
> ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded()));
>  // always should be true
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] commons-lang pull request #188: LANG-1266 Add alphabet converter

2016-09-13 Thread eyala 
GitHub user eyala opened a pull request:

https://github.com/apache/commons-lang/pull/188

LANG-1266 Add alphabet converter

(as described in [the mailing 
list](http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e))

This is a utility class I wrote for converting from one alphabet to another 
- for example, from unicode to latin, without using some of the chars in latin. 
The usage looks like this:

```
Set originals; // a, b, c, d
Set encoding; // 0, 1, d
Set doNotEncode; // d

AlphabetConverter ac = AlphabetConverter.createConverter(originals, 
encoding, doNotEncode);

ac.encode("a"); // 00
ac.encode("b"); // 01
ac.encode("c"); // 0d
ac.encode("d"); // d
ac.encode("abcd"); // 00010dd
```
Of course, 

`x.equals(ac.decode(ac.encode(x)))`

 should always be true.

The implementation provided makes the encodings of fixed length, other than 
the "do not encode" chars, which remain as they are (length one).

In addition, in order to make it easier to preserve the encoding scheme, 
I've added a human-readable toString implementation, and a constructor that can 
recreate an AlphabetConverter from the encoding map, such that:
```

AlphabetConverter ac;


ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded())); 
// always should be true

```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/eyala/commons-lang LANG-1266

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/188.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 #188


commit c1a5a638a3132f2048bb4113181460c3c660c2a8
Author: eallweil 
Date:   2016-09-13T08:15:06Z

LANG-1266 Add alphabet converter




---
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] (LANG-1266) Add alphabet converter

2016-09-13 Thread Eyal Allweil (JIRA) 
Eyal Allweil created LANG-1266:
--

 Summary: Add alphabet converter
 Key: LANG-1266
 URL: https://issues.apache.org/jira/browse/LANG-1266
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.text.*
Reporter: Eyal Allweil


(as described in [the mailing 
list|http://mail-archives.apache.org/mod_mbox/commons-dev/201609.mbox/%3c289983494.3057706.1472720010...@mail.yahoo.com%3e])

This is a utility class I wrote for converting from one alphabet to another - 
for example, from unicode to latin, without using some of the chars in latin. 
The usage looks like this:

{code}
Set originals; // a, b, c, d
Set encoding; // 0, 1, d
Set doNotEncode; // d

AlphabetConverter ac = AlphabetConverter.createConverter(originals, encoding, 
doNotEncode);

ac.encode("a"); // 00
ac.encode("b"); // 01
ac.encode("c"); // 0d
ac.encode("d"); // d
ac.encode("abcd"); // 00010dd

{code}

Of course, x.equals(ac.decode(ac.encode(x))) should always be true.

The implementation provided makes the encodings of fixed length, other than the 
"do not encode" chars, which remain as they are (length one).

In addition, in order to make it easier to preserve the encoding scheme, I've 
added a human-readable toString implementation, and a constructor that can 
recreate an AlphabetConverter from the encoding map, such that:

{code}
AlphabetConverter ac;

ac.equals(AlphabetConverter.createConverterFromMap(ac.getOriginalToEncoded())); 
// always should be true
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (BCEL-276) LocalVariableTypeTable is not updated.

2016-09-13 Thread Benedikt Ritter (JIRA) 

 [ 
https://issues.apache.org/jira/browse/BCEL-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Benedikt Ritter reopened BCEL-276:
--

Reopening this issue to address problems identified by Mark Roberts.

> LocalVariableTypeTable is not updated. 
> ---
>
> Key: BCEL-276
> URL: https://issues.apache.org/jira/browse/BCEL-276
> Project: Commons BCEL
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Sam Yoon
>Assignee: Benedikt Ritter
>  Labels: github
> Fix For: 6.1
>
> Attachments: LocalVariableTypeTableTest.java, MethodGen.diff, 
> SimpleClassHasMethodIncludeGenericArgument.java
>
>
> If a method for BCI have at least one generic type of argument JVM throw 
> java.lang.ClassFormatError due to not updated LocalVariableTable.
> I know there is workaround as call removeLocalVariables method.
> But I think it's better that BCEL can stay proper LocalVariableTable.
> I'm also pull test case can reproduce error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)