[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()
[ https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071550#comment-16071550 ] Amey Jadiye commented on TEXT-97: - Hmm, lets have extra opinions. [~chtompki], [~britter], [~brunodepau...@yahoo.com.br], what do you think ? > RandomStringGenerator should be able to pass multiple ranges to .withinRange() > -- > > Key: TEXT-97 > URL: https://issues.apache.org/jira/browse/TEXT-97 > Project: Commons Text > Issue Type: Improvement >Reporter: Amey Jadiye > Fix For: 1.2 > > > Users should have ability to pass multiple ranges to generate desired output. > Ex. For > *.randomNumeric()* > {code} > char [][] ranges = {{'0','9'}}; > RandomStringGenerator generator = new > RandomStringGenerator.Builder().withinRange(ranges).build(); > {code} > *.randomAlphabetic()* > {code} > char [][] ranges = {{'A','Z'}}; // or {{'A','Z'},{'a','z'}} > RandomStringGenerator generator = new > RandomStringGenerator.Builder().withinRange(ranges).build(); > {code} > *.randomAlphanumeric()* > {code} > char [][] ranges = {{'0','9'},{'A','Z'},{'a','b'}}; > RandomStringGenerator generator = new > RandomStringGenerator.Builder().withinRange(ranges).build(); > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-251) Add new read method "toByteArray" to handle InputStream with known size
[ https://issues.apache.org/jira/browse/IO-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071630#comment-16071630 ] ASF GitHub Bot commented on IO-251: --- GitHub user ilmarmors opened a pull request: https://github.com/apache/commons-io/pull/38 FileUtils.readFileToByteArray - optimize reading of files with known size IO-251 added optimization for reading files with known size as byte arrays, but it was reverted in IO-453 due to regression, because File.length() method may return 0 for path files denoting system-dependent entities such as devices or pipes More optimal solution is to treat 0 as unknown size, but if size is known (> 0) use more efficient approach and read content into pre-allocated byte array with exact size. You can merge this pull request into a Git repository by running: $ git pull https://github.com/ilmarmors/commons-io master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-io/pull/38.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 #38 commit 3ce13884f3b2d78c6ca6cbf9a85c240c6b6532c3 Author: Ilmars Poikans Date: 2017-07-02T13:01:23Z FileUtils.readFileToByteArray - optimize reading of files with known size > Add new read method "toByteArray" to handle InputStream with known size > --- > > Key: IO-251 > URL: https://issues.apache.org/jira/browse/IO-251 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: Marco Albini >Priority: Minor > Fix For: 2.1 > > Attachments: IO-251_toByteArray.patch > > > I suggest adding a new method toByteArray(InputStream input, int size) to > IoUtils to handle known size InputStream (e.g. files). > Current implementation based on copy method consumes more memory than > necessary (at least the double) to transform a InputStream into a byte array. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #274: Fix ExceptionUtils#getStackFrame(String) javadoc
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/274 Thanks! --- 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 #274: Fix ExceptionUtils#getStackFrame(String) jav...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/274 --- 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 #273: add lastIndexOfAnyChar method just like indexOfAny
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/273 Thanks for the pull request, but the build fails because of checkstyle violations, see: https://travis-ci.org/apache/commons-lang/jobs/248359934 for details. --- 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] (IO-542) FileUtils#readFileToByteArray: optimize reading of files with known size
Pascal Schumacher created IO-542: Summary: FileUtils#readFileToByteArray: optimize reading of files with known size Key: IO-542 URL: https://issues.apache.org/jira/browse/IO-542 Project: Commons IO Issue Type: Improvement Reporter: Pascal Schumacher {quote}IO-251 added optimization for reading files with known size as byte arrays, but it was reverted in IO-453 due to regression, because File.length() method may return 0 for path files denoting system-dependent entities such as devices or pipes More optimal solution is to treat 0 as unknown size and use IOUtils.toByteArray(input), but if size is known (> 0) use more efficient approach and read content into pre-allocated byte array with exact size by calling IOUtils.toByteArray(input, size).{quote} source https://github.com/apache/commons-io/pull/38 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IO-251) Add new read method "toByteArray" to handle InputStream with known size
[ https://issues.apache.org/jira/browse/IO-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071683#comment-16071683 ] ASF GitHub Bot commented on IO-251: --- Github user asfgit closed the pull request at: https://github.com/apache/commons-io/pull/38 > Add new read method "toByteArray" to handle InputStream with known size > --- > > Key: IO-251 > URL: https://issues.apache.org/jira/browse/IO-251 > Project: Commons IO > Issue Type: Improvement > Components: Utilities >Affects Versions: 1.4 >Reporter: Marco Albini >Priority: Minor > Fix For: 2.1 > > Attachments: IO-251_toByteArray.patch > > > I suggest adding a new method toByteArray(InputStream input, int size) to > IoUtils to handle known size InputStream (e.g. files). > Current implementation based on copy method consumes more memory than > necessary (at least the double) to transform a InputStream into a byte array. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IO-542) FileUtils#readFileToByteArray: optimize reading of files with known size
[ https://issues.apache.org/jira/browse/IO-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved IO-542. -- Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 2.6 > FileUtils#readFileToByteArray: optimize reading of files with known size > > > Key: IO-542 > URL: https://issues.apache.org/jira/browse/IO-542 > Project: Commons IO > Issue Type: Improvement >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 2.6 > > > {quote}IO-251 added optimization for reading files with known size as byte > arrays, but it was reverted in IO-453 due to regression, because > File.length() method may return 0 for path files denoting system-dependent > entities such as devices or pipes > More optimal solution is to treat 0 as unknown size and use > IOUtils.toByteArray(input), but if size is known (> 0) use more efficient > approach and read content into pre-allocated byte array with exact size by > calling IOUtils.toByteArray(input, size).{quote} > source https://github.com/apache/commons-io/pull/38 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[ https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071766#comment-16071766 ] ASF GitHub Bot commented on TEXT-88: Github user coveralls commented on the issue: https://github.com/apache/commons-text/pull/48 [![Coverage Status](https://coveralls.io/builds/12224670/badge)](https://coveralls.io/builds/12224670) Coverage decreased (-0.002%) to 97.302% when pulling **3f5dfd4b1cc24fa31446a9ea5821cf267375e552 on ameyjadiye:TEXT-88** into **5e479dcd74dab262e5080991796395c3e29222b9 on apache:master**. > WordUtils.capitalizeFully behaves in a counterintuitive manner with empty > delimiter array. > -- > > Key: TEXT-88 > URL: https://issues.apache.org/jira/browse/TEXT-88 > Project: Commons Text > Issue Type: Bug >Reporter: Rob Tompkins > > As discussed in TEXT-85, it seems that > {code:java} > WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine > {code} > Both Sebb and Arun think that this is odd and that the letter "i" should have > been capitalized resulting in the output {{I am fine}} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.
[ https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071768#comment-16071768 ] ASF GitHub Bot commented on TEXT-88: Github user ameyjadiye commented on the issue: https://github.com/apache/commons-text/pull/48 I think we are good to merge this as per discussion here [TEXT-88](https://issues.apache.org/jira/browse/TEXT-88) > WordUtils.capitalizeFully behaves in a counterintuitive manner with empty > delimiter array. > -- > > Key: TEXT-88 > URL: https://issues.apache.org/jira/browse/TEXT-88 > Project: Commons Text > Issue Type: Bug >Reporter: Rob Tompkins > > As discussed in TEXT-85, it seems that > {code:java} > WordUtils.capitalizeFully("i am fine", new char[]{}) // --> i am fine > {code} > Both Sebb and Arun think that this is odd and that the letter "i" should have > been capitalized resulting in the output {{I am fine}} -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator
[ https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16071800#comment-16071800 ] Peter Phillips commented on TEXT-96: Thanks very much to [~ameyjadiye] for the work and PR. I can see that {{RandomStringGenerator}} serves a useful purpose, but I would still propose that simpler methods are required if it is to replace {{RandomStringUtils}}. For existing code using {{RandomStringUtils}} I wouldn't choose to do a search and replace to convert to {{RandomStringGenerator}}. I would instead choose to use an older version of commons-lang3 when {{RandomStringUtils}} eventually gets removed, or alternatively just copy the class into my projects. I would have thought that the majority of developers would do the same. > Convenience methods needed for RandomStringGenerator > > > Key: TEXT-96 > URL: https://issues.apache.org/jira/browse/TEXT-96 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Peter Phillips >Priority: Minor > > {{RandomStringGenerator}} is extremely verbose compared to the deprecated > commons.lang3 {{RandomStringUtils}}. > Previously we could write: > {code:java} > RandomStringUtils.randomNumeric(10) > {code} > to generate a numeric string whereas this now has become: > {code:java} > new RandomStringGenerator.Builder().withinRange('0', '9').build().generate(10) > {code} > although in practice we would then also use static imports too. > The {{randomAlphabetic}} conversion is even more verbose: > {code:java} > new RandomStringGenerator.Builder().withinRange('A', 'z').filteredBy(new > CharacterPredicate() { > @Override > public boolean test(int codePoint) { > return codePoint >= 'a' || codePoint <= 'Z'; > } > }).build().generate(10)) > {code} and at that point I lost enthusiam with trying to replicate > {{randomAlphanumeric}}. > I don't think the average java developer would understand what a code point > is in the first place so then trying to get our automation testers to use the > new API to implement random alphanumeric character generation would be > difficult. > I therefore suggest that commons-text should have a copy of > {{RandomStringUtils}} which can even delegate to {{RandomStringGenerator}} or > alternatively convenience static methods for the common use cases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)