The encoding 'UTF-8' is not supported by t

Question

Whenever I start our Apache Felix (OSGi) based application under SUN Java ( build 1.6.0_10-rc2-b32 and other 1.6.x builds) I see the following message output on the console (usually under Ubuntu 8.4):

Warning: The encoding 'UTF-8' is not supported by the Java runtime.

I've seen this message display occasionally when running both Tomcat and Resin as well. If java supports unicode and UTF-8, what causes this message? I've yet to find any reference, or answer to this anywhere else.

Answer 1

If you are getting this message when using a Transformer, try to specify the TransformerFactory:

link

Answer 2

Try the following program:

import java.nio.charset.Charset;

public class TestCharset {
    public static void main(String[] args) {
        System.out.println(Charset.forName("UTF-8"));
    }
}

If this throws an exception, then there is something wrong with your JDK. If it prints "UTF-8" then your JDK is OK, and your application is doing something odd.

If that's the case, run your app under the debugger, and put a breakpoint in http://www.java2s.com/Open-Source/Java-Document/XML/xalan/org/apache/xml/serializer/ToStream.java.htm --that's the place this warning is produced, and step to see why Xalan can't find the encoding.

Answer 3

It should be "UTF8", without the dash.

Answer 4

According the documentation "Every implementation of the Java platform is required to support the following standard charsets... US-ASCII, ISO-8859-1, UTF-8, UTF-16BE, UTF-16LE, UTF-16." So I doubt that Sun have released a build without UTF-8 support.

The actual error message appears to be from here, which is part of the Xerces XML parser. I imagine it is the XML parser where the problem is occurring.

Answer 5

Most probably someone put a catch() expecting to have only unsupported encoding exceptions, so he used the appropriate message. But he has used too wide exception specification (e.g. catch( Exception ex ) ), so when at runtime he's got something else (non-valid XML, NPE, ... ) the message became misleading.

Answer 6

Try a different (stable release) JVM. I had this problem once and it turned out that the machine was running a beta version JVM that indeed did not support UTF-8, contrary to the requirement in the API docs.