[jira] [Commented] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251060#comment-13251060
]
Aaron Digulla commented on IO-315:
--
@Sebb: Which is why I want a class that provides standard constants.
Just like Gary did in
http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java?revision=1308315view=markup
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-795) Replace all String encoding parameters with Charset
[
https://issues.apache.org/jira/browse/LANG-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251061#comment-13251061
]
Aaron Digulla commented on LANG-795:
For an example, please see
http://svn.apache.org/viewvc/commons/proper/codec/trunk/src/main/java/org/apache/commons/codec/Charsets.java?revision=1308315view=markup
Replace all String encoding parameters with Charset
-
Key: LANG-795
URL: https://issues.apache.org/jira/browse/LANG-795
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.1
Reporter: Aaron Digulla
In several places, String constants are used to specify an encoding for data.
Please add methods that accept {{Charset}} instead, and deprecate the
existing methods.
The goal of this change is to reduce code smell (using String constants
instead of a real value type).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-294) Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
[
https://issues.apache.org/jira/browse/IO-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238227#comment-13238227
]
Aaron Digulla commented on IO-294:
--
It would probably belong to a new class in the package
{{org.apache.commons.lang3.text}} but I fear that nobody will ever find it
there.
{{byteCountToDisplaySize()}} is a method that is strongly related to I/O - I
can't think that we'd use that to print the size of String labels in a UI, for
example.
So it should go into commons IO somewhere but maybe into {{IOUtils}} since it's
not especially related to files.
And if you support I18n, you must allow to specify a locale. Otherwise, this
code can't be used in a multi-language web app, for example.
Adding FileUtils.byteCountToDisplaySize(long size, boolean useSiUnits)
--
Key: IO-294
URL: https://issues.apache.org/jira/browse/IO-294
Project: Commons IO
Issue Type: New Feature
Components: Utilities
Affects Versions: 2.1
Reporter: Jean-Noel Rouvignac
Attachments: FileUtils.java, FileUtilsTest.java
I have written a little Utility method that might benefit Commons IO:
{code}
public class FileUtils {
/**
* Returns a human-readable version of the file size (original is in
bytes). The implementation has the following features:
* ul
* liSupports the SI or IEC units./li
* liSupports I18n/li
* liDisplay a one digit remainder (rounded down if less than 5,
rounded up otherwise)/li
* liOnce the main unit is = 100, drops the remainder which would be
over precision./li
* /ul
*
* @param size The number of bytes.
* @param useSiUnits if false, uses the IEC (International
Electrotechnical Commission) units (powers of 2), else uses SI (International
System of Units)
*units (powers of 10).
* @return A human-readable display value (includes units).
*/
public static String byteCountToDisplaySize(long size, boolean
useSiUnits) {
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-286) FastByteArray*Stream implementations to replace syncronized JDK ByteArray*Stream
[
https://issues.apache.org/jira/browse/IO-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238231#comment-13238231
]
Aaron Digulla commented on IO-286:
--
Comments:
# Always use spaces for indentation
# Allow to override the allocation strategy. If the buffer grows fast, a
different strategy could allocate bigger chunks in the beginning (= less
overall allocations) and be more conservative later (so after the buffer has
grown to 10MB, maybe 15MB is better than 20MB for the next round). To implement
this, export the code to calculate {{newBufferSize}} into a protected method.
# I'm also confused by {{writeBytes()}} but more about the loop inside: Why do
you need a loop there? You already know how many bytes to append and how much
buffer you have left - why not extend the buffer as necessary and then append
all the new bytes in one go?
FastByteArray*Stream implementations to replace syncronized JDK
ByteArray*Stream
Key: IO-286
URL: https://issues.apache.org/jira/browse/IO-286
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Reporter: Paul Loy
Priority: Minor
Labels: streams, synchronized
Attachments: FastByteArrayOutputStream_commons-io.patch,
FastByteArrayOutputStream_commons-io[2].patch
Original Estimate: 24h
Remaining Estimate: 24h
In CASSANDRA-2820 I reintoduced the FastByteArrayInputStream and
FastByteArrayOutputStream to cassandra. These steams are un-synchronized
versions of the Apache Harmony ByteArrayInputStream and ByteArrayOutputStream
respectively.
During my own testing of the streams I found a big difference in the
performance of the standard JDK BA*S steams and the FBA*S streams on most
JREs. Then cassandra load testing also showed an up to 10% improvement in
cassandra performance using these streams.
Then Thrift has TByteArrayOutputStream which contains a way to get the
underlying byte[] buffer without a deep copy that would probably be a good
further enhancement.
Patch to follow.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-255) XML handler to serialize/de-serialize FlieEntrys to/from XML
[ https://issues.apache.org/jira/browse/IO-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238232#comment-13238232 ] Aaron Digulla commented on IO-255: -- Please fix the typo in the bug title: FlieEntrys should be FileEntrys XML handler to serialize/de-serialize FlieEntrys to/from XML Key: IO-255 URL: https://issues.apache.org/jira/browse/IO-255 Project: Commons IO Issue Type: New Feature Affects Versions: 2.0 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Attachments: FileEntryXmlHandler.java It may be usefule to *capture* the state of a Filesystem and serialize it. I've been playing with a handler that can serialize/de-serialize a FileEntry and its children to/from XML. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-218) Introduce new filter input stream with replacement facilities
[
https://issues.apache.org/jira/browse/IO-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238233#comment-13238233
]
Aaron Digulla commented on IO-218:
--
Isn't this a duplicate if issue IO-199?
Introduce new filter input stream with replacement facilities
-
Key: IO-218
URL: https://issues.apache.org/jira/browse/IO-218
Project: Commons IO
Issue Type: Improvement
Components: Filters
Affects Versions: 1.4
Environment: all environments
Reporter: Denis Zhdanov
Attachments: ReplaceFilterInputStream.java,
ReplaceFilterInputStreamTest.java
It seems convenient to have a FilterInputStream that allows to apply
predefined repalcement rules against the read data.
For example we may want to configure the following replacements:
{noformat}
{1, 2} - {7, 8}
{1} - {9}
{3, 2} - {}
{noformat}
and apply them to the input like
{noformat}
{4, 3, 2, 1, 2, 1, 3}
{noformat}
in order to get a result like
{noformat}
{4, 7, 8, 9, 3}
{noformat}
I created the class that allows to do that and attached it to this ticket.
Unit test class at junit4 format is attached as well.
So, the task is to review the provided classes, consider if it's worth to add
them to commons-io distribution and perform the inclusion in the case of
possible result.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-233) Add Methods for Buffering Streams/Writers To IOUtils
[
https://issues.apache.org/jira/browse/IO-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238235#comment-13238235
]
Aaron Digulla commented on IO-233:
--
It would be worth if, if you'd add the encoding:
{code}
public static BufferedReader buffer(InputStream inputStream, String encoding) {
return new BufferedReader(new InputStreamReader(inputStream, encoding));
}
{code}
which would a nice API together with my issue IO-315: Replace all String
encoding parameters with a value type
Add Methods for Buffering Streams/Writers To IOUtils
Key: IO-233
URL: https://issues.apache.org/jira/browse/IO-233
Project: Commons IO
Issue Type: Improvement
Components: Streams/Writers
Affects Versions: 2.0
Environment: Java 1.4+
Reporter: Michael Wooten
Priority: Minor
Fix For: 3.x
Original Estimate: 2h
Remaining Estimate: 2h
I suggest adding utility methods for buffering streams and writers to the
IOUtils class. The methods would have the following signatures:
BufferedInputStream buffer(InputStream inputStream)
BufferedOutputStream buffer(OutputStream outputStream)
BufferedReader buffer(Reader reader)
BufferedWriter buffer(Writer writer)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-71) [io] PipedUtils
[ https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238238#comment-13238238 ] Aaron Digulla commented on IO-71: - For the records: I had the same issues and couldn't find a solution without a second thread that doesn't need an unknown amount of memory. Since this isn't easy to get right, I vote to add this code even though is seems broken. My rationale is this: 1. The code is useful 1. It's hard to get right 1. If there is a better solution (i.e. one without the second thread) the outside API doesn't change, so it would be easy to fix later. [io] PipedUtils --- Key: IO-71 URL: https://issues.apache.org/jira/browse/IO-71 Project: Commons IO Issue Type: Improvement Components: Utilities Environment: Operating System: All Platform: All Reporter: David Smiley Priority: Minor Fix For: 3.x Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch I developed some nifty code that takes an OutputStream and sort of reverses it as if it were an InputStream. Error passing and handling close is dealt with. It needs another thread to do the work which runs in parallel. It uses Piped streams. I created this because I had to conform GZIPOutputStream to my framework which demanded an InputStream. See URL to source. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-237) Add Additional toFiles() and toURLs() Methods to FileUtils
[
https://issues.apache.org/jira/browse/IO-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238246#comment-13238246
]
Aaron Digulla commented on IO-237:
--
I suggest to close this.
With Java 5, you can use the generic {{Arrays.asList()}} for this.
If you need to modify the list, you need to wrap the call in {{new
ArrayList()}}. Due to internal optimizations, this is a pretty fast operation.
Add Additional toFiles() and toURLs() Methods to FileUtils
--
Key: IO-237
URL: https://issues.apache.org/jira/browse/IO-237
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 2.0
Environment: Java 1.5+
Reporter: Michael Wooten
Fix For: 3.x
Attachments: path-convert-fileArray-andURLArray-into-varargs.patch
Original Estimate: 10h
Remaining Estimate: 10h
I suggest modifying the signatures of the toFiles() and toURLs() to use
varargs since that approach will automatically accept arrays and also allow
the user to send an arbitrary number of them.
Convert File[] toFiles(URL[]) to File[] toFiles(URL...)
Convert URL[] toURLs(File[]) to URL[] toURLs(File...)
I also suggest adding new methods for converting a collection of URLs or
Files to an array, or to a List.
File[] toFiles(CollectionURL)
ListFile toFilesList(URL...)
ListFile toFilesList(CollectionURL)
URL[] toURLs(CollectionFile)
ListURL toURLsList(File...)
ListURL toURLsList(CollectionFile)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-249) Enhance closeQuietly to indicate success
[
https://issues.apache.org/jira/browse/IO-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238248#comment-13238248
]
Aaron Digulla commented on IO-249:
--
I also like the handler solution but can we have a factory, please? That way, I
could move all the logging code into my own handler implementation and just
call {{handler.close()}} in my {{finally}} block.
Enhance closeQuietly to indicate success
Key: IO-249
URL: https://issues.apache.org/jira/browse/IO-249
Project: Commons IO
Issue Type: Improvement
Components: Utilities
Affects Versions: 2.0
Reporter: Paul Benedict
Assignee: Paul Benedict
Priority: Minor
Fix For: 3.x
Attachments: IO-249-CloseableHandler.patch
A convention of some programmers is to emit a log warning when a resource
fails to close. Granted, such a condition is an error, but there's no
reasonable recourse to the failure. Using IOUtils.closeQuietly() is very
useful but all information about the success/failure is hidden. Returning
Throwable will give insight into the error for diagnostic purposes. This
change will be compatible with today's usage since the method currently
returns void.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238469#comment-13238469
]
Aaron Digulla commented on IO-315:
--
My point is that everyone litters their code with string constants. String
constants are bad for various reasons and APIs should not endorse them. In my
own code, I use an interface so everyone can add more encodings if they need
that but afterwards, I always know what is an encoding and what is text data
(so no mixups like {{FileUtils.write(UTF-8, Hello, world)}}).
But I agree that commons IO is probably the wrong place to add them. Moving to
commons-lang (which also contains code that handles the exception).
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-795) Replace all String encoding parameters with Charset
[
https://issues.apache.org/jira/browse/LANG-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238477#comment-13238477
]
Aaron Digulla commented on LANG-795:
This would be a first step to reduce string constants in other commons projects
like commons-io (https://issues.apache.org/jira/browse/IO-315)
Replace all String encoding parameters with Charset
-
Key: LANG-795
URL: https://issues.apache.org/jira/browse/LANG-795
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.1
Reporter: Aaron Digulla
In several places, String constants are used to specify an encoding for data.
Please add methods that accept {{Charset}} instead, and deprecate the
existing methods.
The goal of this change is to reduce code smell (using String constants
instead of a real value type).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-315) Replace all String encoding parameters with a value type
[
https://issues.apache.org/jira/browse/IO-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238480#comment-13238480
]
Aaron Digulla commented on IO-315:
--
If you don't like to add a new interface, how about supporting {{Charset}}? It
doesn't throw a checked exception, for example and eventually, all the methods
that accept string will have to lookup a {{Charset}}.
I'll try to convince commons-lang to convert the String constants to Charset
constants (https://issues.apache.org/jira/browse/LANG-795)
Replace all String encoding parameters with a value type
--
Key: IO-315
URL: https://issues.apache.org/jira/browse/IO-315
Project: Commons IO
Issue Type: New Feature
Components: Streams/Writers
Affects Versions: 2.1
Reporter: Aaron Digulla
Please create an interface Encoding plus a set of useful defaults (UTF_8,
ISO_LATIN_1, CP_1250 and CP_1252).
Use this interface in all places where String encoding is used now. This
would make the API more reliable, improve code reuse and reduce futile catch
blocks for {{UnsupportedEncodingException}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
