[jira] [Created] (COLLECTIONS-562) Update minimum required java to 1.6
Thomas Neidhart created COLLECTIONS-562: --- Summary: Update minimum required java to 1.6 Key: COLLECTIONS-562 URL: https://issues.apache.org/jira/browse/COLLECTIONS-562 Project: Commons Collections Issue Type: Task Affects Versions: 4.0 Reporter: Thomas Neidhart The minimum required java version shall be updated to 1.6. 1.5 is already long EOL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (MATH-1220) More efficient sample() method for ZipfDistribution
[ https://issues.apache.org/jira/browse/MATH-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otmar Ertl updated MATH-1220: - Attachment: Zipf Rejection Inversion Sampling Notes.pdf I attached my notes that should make it clearer how the original algorithm was transformed. More efficient sample() method for ZipfDistribution --- Key: MATH-1220 URL: https://issues.apache.org/jira/browse/MATH-1220 Project: Commons Math Issue Type: Improvement Reporter: Otmar Ertl Fix For: 4.0, 3.6 Attachments: Zipf Rejection Inversion Sampling Notes.pdf, patch_v1, patch_v2 Currently, sampling from a ZipfDistribution is very inefficient. Random values are generated by inverting the CDF. However, the current implementation uses O(N) power function evaluations to calculate the CDF for some point. (Here N is the number of points of the Zipf distribution.) I propose to use rejection sampling instead, which allows the generation of a single random value in constant time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (COMPRESS-316) CompressorStreamFactory doesn't handle deflate streams with a zlib header
Nick Burch created COMPRESS-316: --- Summary: CompressorStreamFactory doesn't handle deflate streams with a zlib header Key: COMPRESS-316 URL: https://issues.apache.org/jira/browse/COMPRESS-316 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.9 Reporter: Nick Burch If you take a zlib / deflate compressed file, with the zlib header (eg the test file bla.tar.deflatez) and pass it to CompressorStreamFactory.createCompressorInputStream, it won't be detected and you'll get a CompressorException(No Compressor found for the stream signature.) While detecting header-less zlib files is probably too tricky to manage, those with the header ought to be possible to spot and handle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (COMPRESS-316) CompressorStreamFactory doesn't handle deflate streams with a zlib header
[ https://issues.apache.org/jira/browse/COMPRESS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Burch updated COMPRESS-316: Attachment: zlib-header-detection.patch Proposed patch which adds zlib header signature detection to DeflateCompressorInputStream, uses that in CompressorStreamFactory, and adds a test to DetectCompressorTestCase using an existing test file CompressorStreamFactory doesn't handle deflate streams with a zlib header - Key: COMPRESS-316 URL: https://issues.apache.org/jira/browse/COMPRESS-316 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.9 Reporter: Nick Burch Attachments: zlib-header-detection.patch If you take a zlib / deflate compressed file, with the zlib header (eg the test file bla.tar.deflatez) and pass it to CompressorStreamFactory.createCompressorInputStream, it won't be detected and you'll get a CompressorException(No Compressor found for the stream signature.) While detecting header-less zlib files is probably too tricky to manage, those with the header ought to be possible to spot and handle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-779) Provide a StrBuilder-based or StringBuilder-based ToStringBuilder
[ https://issues.apache.org/jira/browse/LANG-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14557372#comment-14557372 ] ASF GitHub Bot commented on LANG-779: - Github user coveralls commented on the pull request: https://github.com/apache/commons-lang/pull/90#issuecomment-104904506 [](https://coveralls.io/builds/2634896) Coverage decreased (-0.01%) to 93.26% when pulling **8a6b5a6023aed533afef1d2f61c63feac4f9b46e on dstewart:LANG-779** into **0343b4fda87161265acf30d5ee61e525e751358d on apache:master**. Provide a StrBuilder-based or StringBuilder-based ToStringBuilder - Key: LANG-779 URL: https://issues.apache.org/jira/browse/LANG-779 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.1 Reporter: Simon Dierl Priority: Minor Fix For: Patch Needed At the moment, ToStringBuilder internally uses a StringBuffer to create the output String. StringBuffer, as opposed to StringBuilder and StrBuilder, is synchronized. Since ToStringBuilder will almost never leave the toString()-method, the synchronization only adds overhead. Since the ToStringBuilder API never suggests that ToStringBuilder is thread-safe, either the current implementation could be changed to use Str[ing]Builder or an alternative implementation could be provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: LANG-779 Use StringBuilder instead of S...
GitHub user dstewart opened a pull request: https://github.com/apache/commons-lang/pull/90 LANG-779 Use StringBuilder instead of StringBuffer You can merge this pull request into a Git repository by running: $ git pull https://github.com/dstewart/commons-lang LANG-779 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/90.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 #90 commit 8a6b5a6023aed533afef1d2f61c63feac4f9b46e Author: Daniel Stewart ds191...@gmail.com Date: 2015-05-23T14:46:03Z LANG-779 Use StringBuilder instead of StringBuffer --- 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-779) Provide a StrBuilder-based or StringBuilder-based ToStringBuilder
[ https://issues.apache.org/jira/browse/LANG-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14557370#comment-14557370 ] ASF GitHub Bot commented on LANG-779: - GitHub user dstewart opened a pull request: https://github.com/apache/commons-lang/pull/90 LANG-779 Use StringBuilder instead of StringBuffer You can merge this pull request into a Git repository by running: $ git pull https://github.com/dstewart/commons-lang LANG-779 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/90.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 #90 commit 8a6b5a6023aed533afef1d2f61c63feac4f9b46e Author: Daniel Stewart ds191...@gmail.com Date: 2015-05-23T14:46:03Z LANG-779 Use StringBuilder instead of StringBuffer Provide a StrBuilder-based or StringBuilder-based ToStringBuilder - Key: LANG-779 URL: https://issues.apache.org/jira/browse/LANG-779 Project: Commons Lang Issue Type: Improvement Components: lang.builder.* Affects Versions: 3.1 Reporter: Simon Dierl Priority: Minor Fix For: Patch Needed At the moment, ToStringBuilder internally uses a StringBuffer to create the output String. StringBuffer, as opposed to StringBuilder and StrBuilder, is synchronized. Since ToStringBuilder will almost never leave the toString()-method, the synchronization only adds overhead. Since the ToStringBuilder API never suggests that ToStringBuilder is thread-safe, either the current implementation could be changed to use Str[ing]Builder or an alternative implementation could be provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (COMPRESS-316) CompressorStreamFactory doesn't handle deflate streams with a zlib header
[ https://issues.apache.org/jira/browse/COMPRESS-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-316. - Resolution: Fixed Fix Version/s: 1.10 patch committed with svn revision 1681356 My reading of RFC1950 is that the second byte could also have four different values when using preset dictionaries, but then we might be getting too many false positives. Thanks! CompressorStreamFactory doesn't handle deflate streams with a zlib header - Key: COMPRESS-316 URL: https://issues.apache.org/jira/browse/COMPRESS-316 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.9 Reporter: Nick Burch Fix For: 1.10 Attachments: zlib-header-detection.patch If you take a zlib / deflate compressed file, with the zlib header (eg the test file bla.tar.deflatez) and pass it to CompressorStreamFactory.createCompressorInputStream, it won't be detected and you'll get a CompressorException(No Compressor found for the stream signature.) While detecting header-less zlib files is probably too tricky to manage, those with the header ought to be possible to spot and handle -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] commons-lang pull request: LANG-779 Provide a StrBuilder-based or ...
Github user coveralls commented on the pull request: https://github.com/apache/commons-lang/pull/90#issuecomment-104904506 [](https://coveralls.io/builds/2634896) Coverage decreased (-0.01%) to 93.26% when pulling **8a6b5a6023aed533afef1d2f61c63feac4f9b46e on dstewart:LANG-779** into **0343b4fda87161265acf30d5ee61e525e751358d 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] [Updated] (COLLECTIONS-542) AbstractHashedMap should not extend AbstractMap anymore
[ https://issues.apache.org/jira/browse/COLLECTIONS-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart updated COLLECTIONS-542: Issue Type: Task (was: Bug) AbstractHashedMap should not extend AbstractMap anymore --- Key: COLLECTIONS-542 URL: https://issues.apache.org/jira/browse/COLLECTIONS-542 Project: Commons Collections Issue Type: Task Affects Versions: 4.0 Reporter: Thomas Neidhart Priority: Minor Fix For: 4.1, 5.0 As described in the javadoc of AbstractHashedMap, the inheritance of AbstractMap should have been removed in the 4.0 release. This has been forgotten. Removal of the inheritance does not seem to be possible for the 4.x branch, so we should at least correct the javadoc. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
