Activity

I don't think this is a good idea.
There are a lot of different encodings, and who is to say which ones are "useful"?
There would still need to be a way to use the String encoding to allow for encodings that are not provided by the interface.

Also, the code would still need to catch UnsupportedEncodingException.
As far as I know there is no requirement for a Java class-library to support any specific encodings, though it would be a fairly useless implementation that did not support UTF-8.

Sebb
added a comment - 26/Mar/12 11:19 I don't think this is a good idea.
There are a lot of different encodings, and who is to say which ones are "useful"?
There would still need to be a way to use the String encoding to allow for encodings that are not provided by the interface.
Also, the code would still need to catch UnsupportedEncodingException .
As far as I know there is no requirement for a Java class-library to support any specific encodings, though it would be a fairly useless implementation that did not support UTF-8.

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

Aaron Digulla
added a comment - 26/Mar/12 15:18 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).

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.

Aaron Digulla
added a comment - 26/Mar/12 15:28 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 )

That makes more sense now, but I think it would be overkill to introduce a new interface here.

Using Charset would be better IMO.

Using Charset would convert the checked UnsupportedEncodingException into the unchecked UnsupportedCharsetException.
This should simplify application code that does not already catch IOException, though of course in Commons IO many methods throw IOE already.

AFAICT, parameters would need to be changed to use (e.g.) Charset.forName("UTF-8") instead of "UTF-8" so user code would be slightly longer.

Sebb
added a comment - 26/Mar/12 17:42 - edited That makes more sense now, but I think it would be overkill to introduce a new interface here.
Using Charset would be better IMO.
Using Charset would convert the checked UnsupportedEncodingException into the unchecked UnsupportedCharsetException .
This should simplify application code that does not already catch IOException , though of course in Commons IO many methods throw IOE already.
AFAICT, parameters would need to be changed to use (e.g.) Charset.forName("UTF-8") instead of "UTF-8" so user code would be slightly longer.

Aaron Digulla
added a comment - 10/Apr/12 21:02 @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=1308315&view=markup