Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #35797 > unrolled thread

java.net.URLEncoder.encode + UTF-8 (rant)

Back to article view | Back to comp.lang.java.programmer

Contents

  java.net.URLEncoder.encode + UTF-8 (rant) Andreas Leitgeb <avl@logic.at> - 2016-10-17 12:38 +0000
    Re: java.net.URLEncoder.encode + UTF-8 (rant) j4n bur53 <janburse@fastmail.fm> - 2016-10-17 16:55 +0200
    Re: java.net.URLEncoder.encode + UTF-8 (rant) Arne Vajhøj <arne@vajhoej.dk> - 2016-10-19 21:35 -0400
    Re: java.net.URLEncoder.encode + UTF-8 (rant) Daniele Futtorovic <da.futt.news@laposte.net> - 2016-11-14 20:05 +0100
      Re: java.net.URLEncoder.encode + UTF-8 (rant) Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-11-14 14:45 -0500

#35797 — java.net.URLEncoder.encode + UTF-8 (rant)

<rant target="java.net.URLEncoder.encode(String s, String enc)">

This method should (according to the w3c) only be used with UTF-8
and UTF-8 is always supposed to be supported by Java.

Why is there no java.net.URLEncoder.encodeUTF8(String s) that
would free me from that boring
  try {...} catch (UnsupportedEncodingException ign) {...}
boilerplate?  (What code do good(tm) Java programmers even put
into this catch clause, that is expected to never run, anyway?)

Other JSL methods dealing with encodings at least let me specify the
encoding as an instance of Charset, so I can pass StandardCharsets.UTF_8
there and be safe against typos leading to an exception at runtime -
one, whose only fix would be correcting the source.

For URLEncoder it would even make sense to "re-precate" the plain 
encoding(String s) to always use UTF-8 instead of native encoding.
It surely would fix more ancient applications than it would break.

</rant>

[toc] | [next] | [standalone]

#35800

Andreas Leitgeb schrieb:
> <rant target="java.net.URLEncoder.encode(String s, String enc)">
>
> This method should (according to the w3c) only be used with UTF-8
> and UTF-8 is always supposed to be supported by Java.
>
> Why is there no java.net.URLEncoder.encodeUTF8(String s) that
> would free me from that boring
>    try {...} catch (UnsupportedEncodingException ign) {...}
> boilerplate?  (What code do good(tm) Java programmers even put
> into this catch clause, that is expected to never run, anyway?)
>
> Other JSL methods dealing with encodings at least let me specify the
> encoding as an instance of Charset, so I can pass StandardCharsets.UTF_8
> there and be safe against typos leading to an exception at runtime -
> one, whose only fix would be correcting the source.
>
> For URLEncoder it would even make sense to "re-precate" the plain
> encoding(String s) to always use UTF-8 instead of native encoding.
> It surely would fix more ancient applications than it would break.
>
> </rant>
>

Since JDK 1.8 or so UTF-8 is required to exist.

Annoying indeed, so I rolled my own(*):

- Some methods such as encode() or decode() still
   throw an UnsupportedEncodingException exception.

- Other methods such as sysUriHash() etc.. that
   assume UTF-8, don't throw it.

- MalformedURLException and CharacterCodingException
   are still thrown, have some special role here.

To answer your question, I am using the following idiom:

         try {
             [...]
         } catch (UnsupportedEncodingException x) {
             throw new RuntimeException(SHOULDNT_HAPPEN, x);
         }

i.e. map the checked exception, to an unchecked exception.
Could also map to Error, but RuntimeException is less severe.

Bye

(*)
https://github.com/jburse/jekejeke-devel/blob/master/utils/headless/matula/util/system/ForeignUri.java
Disclaimer: There is no warranty for the excerpts.

[toc] | [prev] | [next] | [standalone]

#35837

On 10/17/2016 8:38 AM, Andreas Leitgeb wrote:
> <rant target="java.net.URLEncoder.encode(String s, String enc)">
>
> This method should (according to the w3c) only be used with UTF-8
> and UTF-8 is always supposed to be supported by Java.
>
> Why is there no java.net.URLEncoder.encodeUTF8(String s) that
> would free me from that boring
>   try {...} catch (UnsupportedEncodingException ign) {...}
> boilerplate?  (What code do good(tm) Java programmers even put
> into this catch clause, that is expected to never run, anyway?)
>
> Other JSL methods dealing with encodings at least let me specify the
> encoding as an instance of Charset, so I can pass StandardCharsets.UTF_8
> there and be safe against typos leading to an exception at runtime -
> one, whose only fix would be correcting the source.
>
> For URLEncoder it would even make sense to "re-precate" the plain
> encoding(String s) to always use UTF-8 instead of native encoding.
> It surely would fix more ancient applications than it would break.
>
> </rant>

There is probably a lot of convenience methods that would be nice
to have for some people.

Traditionally Java has been behind regarding such.

I think Java 7 and 8 actually did introduce some such.

But apparently they have not gotten to this one yet. Or maybe
they have and decided it was not important enough. There is
so much stuff that could be added - prioritization is a must.

Arne

[toc] | [prev] | [next] | [standalone]

#35896

On 2016-10-17 14:38, Andreas Leitgeb wrote:
> <rant target="java.net.URLEncoder.encode(String s, String enc)">
> 
> This method should (according to the w3c) only be used with UTF-8
> and UTF-8 is always supposed to be supported by Java.
> 
> Why is there no java.net.URLEncoder.encodeUTF8(String s) that
> would free me from that boring
>   try {...} catch (UnsupportedEncodingException ign) {...}
> boilerplate?  (What code do good(tm) Java programmers even put
> into this catch clause, that is expected to never run, anyway?)

throw new AssertionError( ing.toString() );

But yeah, it's annoying.

df.

[toc] | [prev] | [next] | [standalone]

#35897

On 11/14/2016 2:05 PM, Daniele Futtorovic wrote:
> On 2016-10-17 14:38, Andreas Leitgeb wrote:
>> <rant target="java.net.URLEncoder.encode(String s, String enc)">
>>
>> This method should (according to the w3c) only be used with UTF-8
>> and UTF-8 is always supposed to be supported by Java.
>>
>> Why is there no java.net.URLEncoder.encodeUTF8(String s) that
>> would free me from that boring
>>   try {...} catch (UnsupportedEncodingException ign) {...}
>> boilerplate?  (What code do good(tm) Java programmers even put
>> into this catch clause, that is expected to never run, anyway?)
>
> throw new AssertionError( ing.toString() );

     In situations like this, I think

	throw new AssertionError("BUG!", ign);

is marginally better in that it preserves all the information from
the "cannot happen" exception instead of only its message text.  (If
you ever catch a "cannot happen" exception something very odd must
have happened, and if something *that* odd happens you'll be glad of
every possible clue ...)

> But yeah, it's annoying.

     Yes.  Sometimes, anyhow.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web