[jira] [Commented] (TEXT-96) Convenience methods needed for RandomStringGenerator

[Peter Phillips (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (TEXT-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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-88) WordUtils.capitalizeFully behaves in a counterintuitive manner with empty delimiter array.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Resolved] (IO-542) FileUtils#readFileToByteArray: optimize reading of files with known size

[Pascal Schumacher (JIRA)]

 [ 
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] (IO-251) Add new read method "toByteArray" to handle InputStream with known size

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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] [Created] (IO-542) FileUtils#readFileToByteArray: optimize reading of files with known size

[Pascal Schumacher (JIRA)]

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)

[GitHub] commons-lang issue #273: add lastIndexOfAnyChar method just like indexOfAny

[PascalSchumacher]

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.
---

[GitHub] commons-lang pull request #274: Fix ExceptionUtils#getStackFrame(String) jav...

[asfgit]

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 #274: Fix ExceptionUtils#getStackFrame(String) javadoc

[PascalSchumacher]

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.
---

[jira] [Commented] (IO-251) Add new read method "toByteArray" to handle InputStream with known size

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/IO-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (TEXT-97) RandomStringGenerator should be able to pass multiple ranges to .withinRange()

[Amey Jadiye (JIRA)]

[ 
https://issues.apache.org/jira/browse/TEXT-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)