date:20160612

[jira] [Updated] (CRYPTO-62) Add multithreaded related tests and javadoc comments

2016-06-12 Thread Dapeng Sun (JIRA)


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

Dapeng Sun updated CRYPTO-62:
-
Fix Version/s: 1.0.0

> Add multithreaded related tests and javadoc comments
> 
>
> Key: CRYPTO-62
> URL: https://issues.apache.org/jira/browse/CRYPTO-62
> Project: Commons Crypto
>  Issue Type: Improvement
>Reporter: Hendrik Saly
>Priority: Minor
> Fix For: 1.0.0
>
>
> Add multithreaded related tests for random number generation and javadoc 
> comments to make clear that the chipers are NOT thread-safe



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

[jira] [Updated] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails

2016-06-12 Thread Dapeng Sun (JIRA)


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

Dapeng Sun updated CRYPTO-61:
-
Fix Version/s: 1.0.0

> possible NPE in OpensslCryptoRandom if 
> OpensslCryptoRandomNative.nextRandBytes fails
> 
>
> Key: CRYPTO-61
> URL: https://issues.apache.org/jira/browse/CRYPTO-61
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Hendrik Saly
> Fix For: 1.0.0
>
>
> "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[])



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

[jira] [Commented] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails

2016-06-12 Thread Dapeng Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326773#comment-15326773
 ] 

Dapeng Sun commented on CRYPTO-61:
--

Thank Hendrik for your contribution.

> possible NPE in OpensslCryptoRandom if 
> OpensslCryptoRandomNative.nextRandBytes fails
> 
>
> Key: CRYPTO-61
> URL: https://issues.apache.org/jira/browse/CRYPTO-61
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Hendrik Saly
> Fix For: 1.0.0
>
>
> "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[])



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

[jira] [Resolved] (CRYPTO-61) possible NPE in OpensslCryptoRandom if OpensslCryptoRandomNative.nextRandBytes fails

2016-06-12 Thread Dapeng Sun (JIRA)


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

Dapeng Sun resolved CRYPTO-61.
--
Resolution: Fixed

> possible NPE in OpensslCryptoRandom if 
> OpensslCryptoRandomNative.nextRandBytes fails
> 
>
> Key: CRYPTO-61
> URL: https://issues.apache.org/jira/browse/CRYPTO-61
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Hendrik Saly
>
> "fallback" could be null in OpensslCryptoRandom.nextBytes(byte[])



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

[jira] [Resolved] (CRYPTO-62) Add multithreaded related tests and javadoc comments

2016-06-12 Thread Dapeng Sun (JIRA)


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

Dapeng Sun resolved CRYPTO-62.
--
Resolution: Fixed

> Add multithreaded related tests and javadoc comments
> 
>
> Key: CRYPTO-62
> URL: https://issues.apache.org/jira/browse/CRYPTO-62
> Project: Commons Crypto
>  Issue Type: Improvement
>Reporter: Hendrik Saly
>Priority: Minor
>
> Add multithreaded related tests for random number generation and javadoc 
> comments to make clear that the chipers are NOT thread-safe



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

[jira] [Commented] (CRYPTO-62) Add multithreaded related tests and javadoc comments

2016-06-12 Thread Dapeng Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326772#comment-15326772
 ] 

Dapeng Sun commented on CRYPTO-62:
--

Thank @Hendrik Saly for your contribution.

> Add multithreaded related tests and javadoc comments
> 
>
> Key: CRYPTO-62
> URL: https://issues.apache.org/jira/browse/CRYPTO-62
> Project: Commons Crypto
>  Issue Type: Improvement
>Reporter: Hendrik Saly
>Priority: Minor
>
> Add multithreaded related tests for random number generation and javadoc 
> comments to make clear that the chipers are NOT thread-safe



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

[jira] [Comment Edited] (CRYPTO-54) US Export classification & ECCN registration for encryption

2016-06-12 Thread Dapeng Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326765#comment-15326765
 ] 

Dapeng Sun edited comment on CRYPTO-54 at 6/13/16 3:15 AM:
---

Fixed.

http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E


was (Author: dapengsun):
http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E

> US Export classification & ECCN registration for encryption
> ---
>
> Key: CRYPTO-54
> URL: https://issues.apache.org/jira/browse/CRYPTO-54
> Project: Commons Crypto
>  Issue Type: Task
>Reporter: Benedikt Ritter
> Fix For: 1.0.0
>
>
> As discussed in [1] we may have to get a US Export classification and a ECCN 
> registration for encryption for Apache Commons Crypto.
> [1] http://markmail.org/message/4at6msgqdxq4g4h6



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

[jira] [Comment Edited] (CRYPTO-54) US Export classification & ECCN registration for encryption

2016-06-12 Thread Dapeng Sun (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326765#comment-15326765
 ] 

Dapeng Sun edited comment on CRYPTO-54 at 6/13/16 3:16 AM:
---

Fixed.

http://mail-archives.apache.org/mod_mbox/commons-dev/201606.mbox/%3CCACZkXPyrYvY8NMyQLnT6qMDpNxWiDUudoEw%2BDe%2BYBDHoBBhCzQ%40mail.gmail.com%3E


was (Author: dapengsun):
Fixed.

http://mail-archives.apache.org/mod_mbox/commons-dev/201605.mbox/%3CCAB917RJkcNYL4KeRJTo%3D5F7P3A4iyME0TA40GNmuU4RLs5N4KQ%40mail.gmail.com%3E

> US Export classification & ECCN registration for encryption
> ---
>
> Key: CRYPTO-54
> URL: https://issues.apache.org/jira/browse/CRYPTO-54
> Project: Commons Crypto
>  Issue Type: Task
>Reporter: Benedikt Ritter
> Fix For: 1.0.0
>
>
> As discussed in [1] we may have to get a US Export classification and a ECCN 
> registration for encryption for Apache Commons Crypto.
> [1] http://markmail.org/message/4at6msgqdxq4g4h6



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

[jira] [Closed] (CSV-187) Update platform requirement from Java 6 to 7

2016-06-12 Thread Gary Gregory (JIRA)


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

Gary Gregory closed CSV-187.

Resolution: Fixed

In trunk.

> Update platform requirement from Java 6 to 7
> 
>
> Key: CSV-187
> URL: https://issues.apache.org/jira/browse/CSV-187
> Project: Commons CSV
>  Issue Type: Improvement
> Environment: Apache Maven 3.3.9 
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\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
>
> Update platform requirement from Java 6 to 7.



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

[jira] [Created] (CSV-187) Update platform requirement from Java 6 to 7

2016-06-12 Thread Gary Gregory (JIRA)

Gary Gregory created CSV-187:


 Summary: Update platform requirement from Java 6 to 7
 Key: CSV-187
 URL: https://issues.apache.org/jira/browse/CSV-187
 Project: Commons CSV
  Issue Type: Improvement
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
Maven home: E:\Java\apache-maven-3.3.9
Java version: 1.7.0_79, vendor: Oracle Corporation
Java home: C:\Program Files\Java\jdk1.7.0_79\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


Update platform requirement from Java 6 to 7.



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

[jira] [Commented] (COMPRESS-357) BZip2CompressorOutputStream can affect output stream incorrectly

2016-06-12 Thread Richard Shapiro (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326728#comment-15326728
 ] 

Richard Shapiro commented on COMPRESS-357:
--

I just want to point out that the real problem with this is the presence of a 
finalize() method. Any code that requires that finalize() be run is almost 
certainly incorrect, as you can never rely on it ever being called. Since the 
class is thread-unsafe, there is in practice no additional performance cost to 
synchronizing both flush() and finish(), since if the lock isn't essentially 
free, you aren't using the class correctly either (i.e., you'd better be 
calling write() and flush() inside some other synchronized block, or else 
guarantee they are on the same thread). 

The other thing to remember is that if it's incorrect, it doesn't matter how 
fast something is, and bzip2 is already so slow that I doubt you will ever see 
the synchronization cost even if you do multi-thread it.

By far the most correct solution is to get rid of finish().   

> BZip2CompressorOutputStream can affect output stream incorrectly
> 
>
> Key: COMPRESS-357
> URL: https://issues.apache.org/jira/browse/COMPRESS-357
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.9, 1.11
> Environment: multithreaded
>Reporter: Richard Shapiro
>  Labels: easyfix
> Fix For: 1.12
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> BZip2CompressorOutputStream has an unsynchronized finished() method, and an 
> unsynchronized finalize method. Finish checks to see if the output stream is 
> null, and if it is not it calls various methods, some of which write to the 
> output stream. 
> Now, consider something like this sequence.
> BZip2OutputStream s = ...
> ...
> s.close();
> s = null;
> After the s = null, the stream is garbage. At some point the garbage 
> collector call finalize(), which calls finish(). But, since the GC may be on 
> a different thread, there is no guarantee that the assignment this.out = null 
> in finish() has actually been made visible to the GC thread, which results in 
> bad data in the output stream.
> This is not a theoretical problem; In a part of a large project I'm working 
> on, this happens about 2% of the time. 
> The fixes are simple
> 1) synchronize finish() or
>   
> 2) don't call finish from finalize().
> A workaround is to derive a class and override the finalize() method. 



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

[GitHub] commons-lang issue #165: update javadoc for DateParser and DatePrinter

2016-06-12 Thread coveralls

Github user coveralls commented on the issue:

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

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

Coverage increased (+0.002%) to 93.466% when pulling 
**4b91070a2a118e3a8207561487acb55fc8a60ae2 on chonton:master** into 
**d2fb3b0865a87cc909e4faab7733f993356141e2 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 #165: update javadoc for DateParser and DatePrinte...

2016-06-12 Thread chonton

GitHub user chonton opened a pull request:

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

update javadoc for DateParser and DatePrinter



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

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

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

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


commit 4b91070a2a118e3a8207561487acb55fc8a60ae2
Author: Chas Honton 
Date:   2016-06-13T00:34:33Z

update javadoc for DateParser and DatePrinter




---
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] (COMPRESS-357) BZip2CompressorOutputStream can affect output stream incorrectly

2016-06-12 Thread Sebb (JIRA)


[ 
https://issues.apache.org/jira/browse/COMPRESS-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326670#comment-15326670
 ] 

Sebb commented on COMPRESS-357:
---

There are two cases to consider:
A) the main code runs finish(), and finalize must be prevented from calling 
finish() again.
B) the main code does not run finish(), so finalize must call finish()

Case A is easy to handle; just ensure that the indicator variable (out) is 
properly published.

In case B, the finalize method detects that it needs to call finish().
So far so good, the finalizer thread has only accessed the properly published 
variable.
But the finish() method will only work properly if it sees the correct values 
for all the variables it uses.
Other variables have not been safely published, so the values seen by the 
finalizer thread may be arbitrarily stale.

Note that this is not a problem of concurrent access - it is a problem of safe 
publication, i.e. ensuring that the variable values written in the main thread 
are seen by the finalizer thread. 

This is exactly the problem reported in the description; the correct out field 
value was not seen by the finalizer thread.

One way to fix this would be to make *all* the variables used by finish() 
volatile.
I don't know if that would cause a serious performance hit.

> BZip2CompressorOutputStream can affect output stream incorrectly
> 
>
> Key: COMPRESS-357
> URL: https://issues.apache.org/jira/browse/COMPRESS-357
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Compressors
>Affects Versions: 1.9, 1.11
> Environment: multithreaded
>Reporter: Richard Shapiro
>  Labels: easyfix
> Fix For: 1.12
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> BZip2CompressorOutputStream has an unsynchronized finished() method, and an 
> unsynchronized finalize method. Finish checks to see if the output stream is 
> null, and if it is not it calls various methods, some of which write to the 
> output stream. 
> Now, consider something like this sequence.
> BZip2OutputStream s = ...
> ...
> s.close();
> s = null;
> After the s = null, the stream is garbage. At some point the garbage 
> collector call finalize(), which calls finish(). But, since the GC may be on 
> a different thread, there is no guarantee that the assignment this.out = null 
> in finish() has actually been made visible to the GC thread, which results in 
> bad data in the output stream.
> This is not a theoretical problem; In a part of a large project I'm working 
> on, this happens about 2% of the time. 
> The fixes are simple
> 1) synchronize finish() or
>   
> 2) don't call finish from finalize().
> A workaround is to derive a class and override the finalize() method. 



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

[jira] [Created] (CRYPTO-70) Compiling on Windows

2016-06-12 Thread Gary Gregory (JIRA)

Gary Gregory created CRYPTO-70:
--

 Summary: Compiling on Windows
 Key: CRYPTO-70
 URL: https://issues.apache.org/jira/browse/CRYPTO-70
 Project: Commons Crypto
  Issue Type: New Feature
  Components: Build
Reporter: Gary Gregory


The build needs to be updated to compile on Windows. TDB if this should be for 
1.0 or 1.1.



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

[jira] [Commented] (VALIDATOR-394) General Modulus Ten Check Digit Implementation

2016-06-12 Thread Niall Pemberton (JIRA)


[ 
https://issues.apache.org/jira/browse/VALIDATOR-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326580#comment-15326580
 ] 

Niall Pemberton commented on VALIDATOR-394:
---

@Sebb - good point, I've cloned postitionWeight 

I added a couple of more tests and a *sumWeightedDigits* option and checked in 
this change:
 - http://svn.apache.org/viewvc?view=revision=1748035



> General Modulus Ten Check Digit Implementation
> --
>
> Key: VALIDATOR-394
> URL: https://issues.apache.org/jira/browse/VALIDATOR-394
> Project: Commons Validator
>  Issue Type: New Feature
>  Components: Routines
>Reporter: Niall Pemberton
> Attachments: VALIDATOR-394-ModulusTenCheckDigit.patch, 
> VALIDATOR-394-Tests.patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Discussion on the commons dev mailing list about a CheckDigit implementation 
> for German identity cards prompted a general  Modulus 10 CheckDigit 
> implementation where the weighting factors could be specified.
> See http://markmail.org/message/zqxsep327ios2r4t



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

[jira] [Resolved] (IMAGING-178) PnmImageParser does not check the validity of input PAM header

2016-06-12 Thread Benedikt Ritter (JIRA)


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

Benedikt Ritter resolved IMAGING-178.
-
Resolution: Fixed

{code}
$ svn ci -m "IMAGING-178: PnmImageParser does not check the validity of input 
PAM header. Thanks to emopers. This also fixes #20 from github."
Sendingsrc/changes/changes.xml
Sending
src/main/java/org/apache/commons/imaging/formats/pnm/PnmImageParser.java
Sending
src/test/java/org/apache/commons/imaging/formats/pnm/PnmImageParserTest.java
Transmitting file data ...done
Committing transaction...
Committed revision 1748015.
{code}

Thank you!

> PnmImageParser does not check the validity of input PAM header
> --
>
> Key: IMAGING-178
> URL: https://issues.apache.org/jira/browse/IMAGING-178
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: PNM
>Reporter: emopers
>
> PnmImageParser.java directly calls tokenizer.nextToken() at line no 160, 163, 
> 166, 169 and 172 on java.util.StringTokenizer tokenizer without checking if 
> there are more tokens.  Because tokenizer is built from the bytes string that 
> can be invalid, this can lead to a runtime exception without a useful error 
> message.  This can be easily fixed by calling tokenizer.hasMoreTokens() 
> before calling tokenizer.nextToken() at each line number mentioned before and 
> throwing useful error message.



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

[jira] [Updated] (IMAGING-178) PnmImageParser does not check the validity of input PAM header

2016-06-12 Thread Benedikt Ritter (JIRA)


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

Benedikt Ritter updated IMAGING-178:

Fix Version/s: 1.0

> PnmImageParser does not check the validity of input PAM header
> --
>
> Key: IMAGING-178
> URL: https://issues.apache.org/jira/browse/IMAGING-178
> Project: Commons Imaging
>  Issue Type: Bug
>  Components: Format: PNM
>Reporter: emopers
> Fix For: 1.0
>
>
> PnmImageParser.java directly calls tokenizer.nextToken() at line no 160, 163, 
> 166, 169 and 172 on java.util.StringTokenizer tokenizer without checking if 
> there are more tokens.  Because tokenizer is built from the bytes string that 
> can be invalid, this can lead to a runtime exception without a useful error 
> message.  This can be easily fixed by calling tokenizer.hasMoreTokens() 
> before calling tokenizer.nextToken() at each line number mentioned before and 
> throwing useful error message.



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

[jira] [Created] (CRYPTO-69) Activate Travis CI

2016-06-12 Thread Benedikt Ritter (JIRA)

Benedikt Ritter created CRYPTO-69:
-

 Summary: Activate Travis CI
 Key: CRYPTO-69
 URL: https://issues.apache.org/jira/browse/CRYPTO-69
 Project: Commons Crypto
  Issue Type: Improvement
  Components: Build
Reporter: Benedikt Ritter


We should activate Travis CI for Commons Crypto. For this to work we need to 
install JCE unlimited strength in the Travis build environment. An example can 
be found here: https://github.com/simi/travis-jce-unlimited-test



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

[jira] [Commented] (CRYPTO-68) Enable common code quality reports

2016-06-12 Thread Benedikt Ritter (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326421#comment-15326421
 ] 

Benedikt Ritter commented on CRYPTO-68:
---

Working on this...

> Enable common code quality reports
> --
>
> Key: CRYPTO-68
> URL: https://issues.apache.org/jira/browse/CRYPTO-68
> Project: Commons Crypto
>  Issue Type: Improvement
>  Components: Build, Document
>Reporter: Benedikt Ritter
> Fix For: 1.0.0
>
>
> We should enable common code quality reports and publish the result on the 
> website:
> - findbugs
> - pmd
> - checkstyle



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

[jira] [Created] (CRYPTO-68) Enable common code quality reports

2016-06-12 Thread Benedikt Ritter (JIRA)

Benedikt Ritter created CRYPTO-68:
-

 Summary: Enable common code quality reports
 Key: CRYPTO-68
 URL: https://issues.apache.org/jira/browse/CRYPTO-68
 Project: Commons Crypto
  Issue Type: Improvement
  Components: Build, Document
Reporter: Benedikt Ritter
 Fix For: 1.0.0


We should enable common code quality reports and publish the result on the 
website:

- findbugs
- pmd
- checkstyle



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

[jira] [Commented] (JEXL-199) An Update to the Add Method

2016-06-12 Thread Dagu Ward (JIRA)


[ 
https://issues.apache.org/jira/browse/JEXL-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326411#comment-15326411
 ] 

Dagu Ward commented on JEXL-199:


Hi Thanks for the reponse, 
I will pass this information onto the spring jade developers and hopefully they 
will put in a fix  on their end.
If it was my code, it would already be fixed, but trying not to get into the 
libraries customization as that puts you in a tight spot with upgrades and 
updates.
Thanks very much for your explanation.
Hopefully they will comply nicely and help me to resolve the problem
Thanks again


> An Update to the Add Method
> ---
>
> Key: JEXL-199
> URL: https://issues.apache.org/jira/browse/JEXL-199
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 2.1.1, 3.0
>Reporter: Dagu Ward
>Assignee: Henri Biestro
>Priority: Critical
> Fix For: 3.0.1
>
>
> If A String and a Boolean is passed to this method, it throws an expection 
> and just dies.
>  Booleans (True or False) should be treated just like strings and just 
> concatenated together, so that this would not cause any problems.
> Spring jade currently uses this method when it is building html, and if a 
> boolean is used in the string, it causes the parsing to die.
> Not sure it is fully the intended purpose, so not reported as a bug, but as a 
> nice improvement, but it sure causing me some stress.
> You can easily put the return in the finally, check for boolean or just use 
> the string function to return the string value
> /**
>  * Add two values together.
>  * 
>  * If any numeric add fails on coercion to the appropriate type,
>  * treat as Strings and do concatenation.
>  * 
>  * 
>  * @param left  left argument
>  * @param right  right argument
>  * @return left + right.
>  */
> public Object add(Object left, Object right) {
> if (left == null && right == null) {
> return controlNullNullOperands();
> }
> /***
> Possible Fix
>  if (left instanceof Boolean){
>left = (Boolean.valueOf((boolean) left).toString());
>  }
>  if (right instanceof Boolean){
>left = (Boolean.valueOf((boolean) right).toString());
>  }
> ***/
> boolean strconcat = strict
> ? left instanceof String || right instanceof 
> String
> : left instanceof String && right instanceof 
> String;
> if (!strconcat) {
> try {
> // if either are bigdecimal use that type
> if (left instanceof BigDecimal || right instanceof 
> BigDecimal) {
> BigDecimal l = toBigDecimal(left);
> BigDecimal r = toBigDecimal(right);
> BigDecimal result = l.add(r, getMathContext());
> return narrowBigDecimal(left, right, result);
> }
> // if either are floating point (double or float) use double
> if (isFloatingPointNumber(left) || 
> isFloatingPointNumber(right)) {
> double l = toDouble(left);
> double r = toDouble(right);
> return l + r;
> }
> // otherwise treat as integers
> BigInteger l = toBigInteger(left);
> BigInteger r = toBigInteger(right);
> BigInteger result = l.add(r);
> return narrowBigInteger(left, right, result);
> } catch (java.lang.NumberFormatException nfe) {
> if (left == null || right == null) {
> controlNullOperand();
> }
> }
> }
> return toString(left).concat(toString(right));
> }



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

[jira] [Resolved] (CRYPTO-65) Warnings compiling on MacOSX - JNIEXPORT redefined

2016-06-12 Thread Benedikt Ritter (JIRA)


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

Benedikt Ritter resolved CRYPTO-65.
---
Resolution: Fixed
  Assignee: Benedikt Ritter

Fixed in 6b3f3b5

> Warnings compiling on MacOSX - JNIEXPORT redefined
> --
>
> Key: CRYPTO-65
> URL: https://issues.apache.org/jira/browse/CRYPTO-65
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Sebb
>Assignee: Benedikt Ritter
> Fix For: 1.0.0
>
> Attachments: crypto-57.patch
>
>
> I get the following warnings on MacOSX:
>  [exec] compiling OSInfo.java
>  [exec] "$JAVA_HOME/bin/javac" -source 1.6 -target 1.6 -d 
> target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/crypto/random/OpensslCryptoRandomNative.java
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/random/OpensslCrypto1 warning
>  [exec] RandomNative.h 
> org.apache.commons.crypto.random.OpensslCryptoRandomNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c 
> -o target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslCryptoRandom.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:37:9:
>  warning: 'JNIEXPORT' macro redefined [-Wmacro"$JAVA_HOME/bin/javac" -source 
> 1.6 -target 1.6 -d target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79crypto/cipher/OpensslNative.java
>  [exec] .jdk/Contents/Home/include/darwin/jni_md.h:29:9: note: previous 
> definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/cipher/OpensslNative.h 
> org.apache.commons.crypto.cipher.OpensslNative
>  [exec] 1 warning
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c -o 
> target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslNative.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c:26:9: 
> warning: 'JNIEXPORT' macro redefined [-Wmacro-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin/jni_md.h:29:9:
>  note: previous definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.



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

[jira] [Commented] (LANG-1215) NumberUtils.createNumber() method lost precision sometimes

2016-06-12 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher commented on LANG-1215:
-

The fix for LANG-1018 also solves this, so this will be fixed in 3.5.

> NumberUtils.createNumber() method lost precision sometimes
> --
>
> Key: LANG-1215
> URL: https://issues.apache.org/jira/browse/LANG-1215
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 2.6, 3.4
> Environment: Windows 7,Jdk1.6,Eclipse 3.5
>Reporter: charryong
>Priority: Critical
>  Labels: github-import
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> For example:
> System.out.println(NumberUtils.createNumber("193343.82"));
> The result  is   193343.81。
> The bug because of  code in the class  NumberUtils of the 
> org.apache.commons.lang3.math package。
> public static Float createFloat(final String str) {
> if (str == null) {
> return null;
> }
> return Float.valueOf(str);
> }



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

[jira] [Commented] (LANG-1187) Method createNumber from NumberUtils doesn't work for floating point numbers other than Float

2016-06-12 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher commented on LANG-1187:
-

The fix for LANG-1018 also solves this, so this will be fixed in 3.5.

> Method createNumber from NumberUtils doesn't work for floating point numbers 
> other than Float
> -
>
> Key: LANG-1187
> URL: https://issues.apache.org/jira/browse/LANG-1187
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.4
>Reporter: leizhiyuan
>Priority: Critical
>
> demo:
>  Number n = 
> org.apache.commons.lang3.math.NumberUtils.createNumber("6264583.33");
> System.out.println("lang3_createNumber_6264583.33>" + n);
> while n will be 6264583.5. not 6264583.33



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

[jira] [Commented] (CRYPTO-65) Warnings compiling on MacOSX - JNIEXPORT redefined

2016-06-12 Thread Benedikt Ritter (JIRA)


[ 
https://issues.apache.org/jira/browse/CRYPTO-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15326382#comment-15326382
 ] 

Benedikt Ritter commented on CRYPTO-65:
---

Fixes the problem for me as well.

> Warnings compiling on MacOSX - JNIEXPORT redefined
> --
>
> Key: CRYPTO-65
> URL: https://issues.apache.org/jira/browse/CRYPTO-65
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 1.0.0
>
> Attachments: crypto-57.patch
>
>
> I get the following warnings on MacOSX:
>  [exec] compiling OSInfo.java
>  [exec] "$JAVA_HOME/bin/javac" -source 1.6 -target 1.6 -d 
> target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/crypto/random/OpensslCryptoRandomNative.java
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/random/OpensslCrypto1 warning
>  [exec] RandomNative.h 
> org.apache.commons.crypto.random.OpensslCryptoRandomNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c 
> -o target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslCryptoRandom.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:37:9:
>  warning: 'JNIEXPORT' macro redefined [-Wmacro"$JAVA_HOME/bin/javac" -source 
> 1.6 -target 1.6 -d target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79crypto/cipher/OpensslNative.java
>  [exec] .jdk/Contents/Home/include/darwin/jni_md.h:29:9: note: previous 
> definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/cipher/OpensslNative.h 
> org.apache.commons.crypto.cipher.OpensslNative
>  [exec] 1 warning
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c -o 
> target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslNative.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c:26:9: 
> warning: 'JNIEXPORT' macro redefined [-Wmacro-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin/jni_md.h:29:9:
>  note: previous definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.



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

[jira] [Updated] (CRYPTO-65) Warnings compiling on MacOSX - JNIEXPORT redefined

2016-06-12 Thread Benedikt Ritter (JIRA)


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

Benedikt Ritter updated CRYPTO-65:
--
Fix Version/s: 1.0.0

> Warnings compiling on MacOSX - JNIEXPORT redefined
> --
>
> Key: CRYPTO-65
> URL: https://issues.apache.org/jira/browse/CRYPTO-65
> Project: Commons Crypto
>  Issue Type: Bug
>Reporter: Sebb
> Fix For: 1.0.0
>
> Attachments: crypto-57.patch
>
>
> I get the following warnings on MacOSX:
>  [exec] compiling OSInfo.java
>  [exec] "$JAVA_HOME/bin/javac" -source 1.6 -target 1.6 -d 
> target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/crypto/random/OpensslCryptoRandomNative.java
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/random/OpensslCrypto1 warning
>  [exec] RandomNative.h 
> org.apache.commons.crypto.random.OpensslCryptoRandomNative
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c 
> -o target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslCryptoRandom.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/random/OpensslCryptoRandomNative.c:37:9:
>  warning: 'JNIEXPORT' macro redefined [-Wmacro"$JAVA_HOME/bin/javac" -source 
> 1.6 -target 1.6 -d target/jni-classes -sourcepath src/main/java 
> src/main/java/org/apache/commons/-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79crypto/cipher/OpensslNative.java
>  [exec] .jdk/Contents/Home/include/darwin/jni_md.h:29:9: note: previous 
> definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.
>  [exec] warning: [options] bootstrap class path not set in conjunction 
> with -source 1.6
>  [exec] "$JAVA_HOME/bin/javah" -force -classpath target/jni-classes -o 
> target/jni-classes/org/apache/commons/crypto/cipher/OpensslNative.h 
> org.apache.commons.crypto.cipher.OpensslNative
>  [exec] 1 warning
>  [exec] gcc -arch x86_64 -Ilib/inc_mac 
> -I/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include -O2 
> -fPIC -mmacosx-version-min=10.5 -fvisibility=hidden -I/usr/local/include 
> -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" 
> -I"/Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin"
>  -I"target/jni-classes/org/apache/commons/crypto/cipher" 
> -I"target/jni-classes/org/apache/commons/crypto/random" -c 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c -o 
> target/commons-crypto-1.0.0-SNAPSHOT-Mac-x86_64/OpensslNative.o
>  [exec] 
> src/main/native/org/apache/commons/crypto/cipher/OpensslNative.c:26:9: 
> warning: 'JNIEXPORT' macro redefined [-Wmacro-redefined]
>  [exec] #define JNIEXPORT __attribute__((__visibility__("default")))
>  [exec] ^
>  [exec] 
> /Library/Java/JavaVirtualMachines/jdk1.7.0_79.jdk/Contents/Home/include/darwin/jni_md.h:29:9:
>  note: previous definition is here
>  [exec] #define JNIEXPORT
>  [exec] ^
>  [exec] 1 warning generated.



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

[GitHub] commons-lang pull request #93: fix StringUtils.ordinalIndexOf("aaaaaa", "aa"...

2016-06-12 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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 #9: Lang 4 x

2016-06-12 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-1018) NumberUtils.createNumber(final String str) Precision will be lost

2016-06-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LANG-1018:
--

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/156
  
Thanks! :+1: 


> NumberUtils.createNumber(final String str)  Precision will be lost
> --
>
> Key: LANG-1018
> URL: https://issues.apache.org/jira/browse/LANG-1018
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.3.2
> Environment: windows 7
>Reporter: sydng
>Assignee: Duncan Jones
> Fix For: Patch Needed
>
>
> With commons-lang 3.2.2:
> NumberUtils.createNumber("-160952.54");
> The result is "-160952.55".
> Should not be based on the length of the decimal point number to judge 
> whether the floating point number.
> Using the method (createFloat(str)) of dealing with the valid number greater 
> than seven Numbers will cause accuracy loss.
> The source code is as follows:
> {code:java}
> try {
> if(numDecimals <= 7){// If number has 7 or fewer digits past the 
> decimal point then make it a float
> final Float f = createFloat(str);
> if (!(f.isInfinite() || (f.floatValue() == 0.0F && 
> !allZeros))) {
> return f;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> try {
> if(numDecimals <= 16){// If number has between 8 and 16 digits 
> past the decimal point then make it a double
> final Double d = createDouble(str);
> if (!(d.isInfinite() || (d.doubleValue() == 0.0D && 
> !allZeros))) {
> return d;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> return createBigDecimal(str);
> }
> {code}



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

[jira] [Commented] (LANG-903) Add XML implementation of ToStringStyle

2016-06-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LANG-903:
-

Github user asfgit closed the pull request at:

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


> Add XML implementation of ToStringStyle
> ---
>
> Key: LANG-903
> URL: https://issues.apache.org/jira/browse/LANG-903
> Project: Commons Lang
>  Issue Type: Improvement
>  Components: lang.builder.*
>Affects Versions: 3.1
>Reporter: Dave Hughes
>Priority: Minor
> Fix For: Review Patch
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> Lang 1.1 included a commented out implementation of XMLToStringStyle.  This 
> disappeared in later versions, but is a very useful implementation.  
> (JSONToStringStyle would also be very nice)



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

[GitHub] commons-lang pull request #156: LANG-1018: Fix precision loss on NumberUtils...

2016-06-12 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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 #7: [LANG-903] Trunk - ToStringStyle typos and XML...

2016-06-12 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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-1018) NumberUtils.createNumber(final String str) Precision will be lost

2016-06-12 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on LANG-1018:
--

Github user asfgit closed the pull request at:

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


> NumberUtils.createNumber(final String str)  Precision will be lost
> --
>
> Key: LANG-1018
> URL: https://issues.apache.org/jira/browse/LANG-1018
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.3.2
> Environment: windows 7
>Reporter: sydng
>Assignee: Duncan Jones
> Fix For: Patch Needed
>
>
> With commons-lang 3.2.2:
> NumberUtils.createNumber("-160952.54");
> The result is "-160952.55".
> Should not be based on the length of the decimal point number to judge 
> whether the floating point number.
> Using the method (createFloat(str)) of dealing with the valid number greater 
> than seven Numbers will cause accuracy loss.
> The source code is as follows:
> {code:java}
> try {
> if(numDecimals <= 7){// If number has 7 or fewer digits past the 
> decimal point then make it a float
> final Float f = createFloat(str);
> if (!(f.isInfinite() || (f.floatValue() == 0.0F && 
> !allZeros))) {
> return f;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> try {
> if(numDecimals <= 16){// If number has between 8 and 16 digits 
> past the decimal point then make it a double
> final Double d = createDouble(str);
> if (!(d.isInfinite() || (d.doubleValue() == 0.0D && 
> !allZeros))) {
> return d;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> return createBigDecimal(str);
> }
> {code}



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

[GitHub] commons-lang issue #156: LANG-1018: Fix precision loss on NumberUtils.create...

2016-06-12 Thread PascalSchumacher

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/156
  
Thanks! :+1: 


---
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 #9: Lang 4 x

2016-06-12 Thread britter

Github user britter commented on the issue:

https://github.com/apache/commons-lang/pull/9
  
@PascalSchumacher I think @lingeng1986 should take care of clearing the PR 
up so that it can be easily reviewed and applied.


---
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 #9: Lang 4 x

2016-06-12 Thread PascalSchumacher

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-lang/pull/9
  
I tried but failed to extract the changes.


---
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] [Closed] (LANG-1187) Method createNumber from NumberUtils doesn't work for floating point numbers other than Float

2016-06-12 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher closed LANG-1187.
---
Resolution: Duplicate

> Method createNumber from NumberUtils doesn't work for floating point numbers 
> other than Float
> -
>
> Key: LANG-1187
> URL: https://issues.apache.org/jira/browse/LANG-1187
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 3.4
>Reporter: leizhiyuan
>Priority: Critical
>
> demo:
>  Number n = 
> org.apache.commons.lang3.math.NumberUtils.createNumber("6264583.33");
> System.out.println("lang3_createNumber_6264583.33>" + n);
> while n will be 6264583.5. not 6264583.33



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

[jira] [Closed] (LANG-1215) NumberUtils.createNumber() method lost precision sometimes

2016-06-12 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher closed LANG-1215.
---
Resolution: Duplicate

> NumberUtils.createNumber() method lost precision sometimes
> --
>
> Key: LANG-1215
> URL: https://issues.apache.org/jira/browse/LANG-1215
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.math.*
>Affects Versions: 2.6, 3.4
> Environment: Windows 7,Jdk1.6,Eclipse 3.5
>Reporter: charryong
>Priority: Critical
>  Labels: github-import
>   Original Estimate: 72h
>  Remaining Estimate: 72h
>
> For example:
> System.out.println(NumberUtils.createNumber("193343.82"));
> The result  is   193343.81。
> The bug because of  code in the class  NumberUtils of the 
> org.apache.commons.lang3.math package。
> public static Float createFloat(final String str) {
> if (str == null) {
> return null;
> }
> return Float.valueOf(str);
> }



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

[jira] [Closed] (LANG-1204) Make Pairs JSON serializable (e.g. with Jackson annotations)

2016-06-12 Thread Pascal Schumacher (JIRA)


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

Pascal Schumacher closed LANG-1204.
---
Resolution: Won't Fix

Closing this as "Won't Fix" (see my comment above for reasons).

> Make Pairs JSON serializable (e.g. with Jackson annotations)
> 
>
> Key: LANG-1204
> URL: https://issues.apache.org/jira/browse/LANG-1204
> Project: Commons Lang
>  Issue Type: Improvement
>Reporter: Andrew Pennebaker
>
> Please make Pairs JSON-serializable, so that they can be used as fields in 
> larger JSON-serializable objects.



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

40 matches

Mail list logo