8

I'm doing some work using the JavaMail API, and I've run across encodings which Java doesn't support natively (by design), such as UTF7/unicode-1-1-utf-7. For that encoding in particular I found the JUTF7 implementation of a Java Charset and CharsetProvider for UTF7. However, having added the jutf7.jar to my classpath I still get UnsupportedEncodingExceptions, and unicode-1-1-utf-7 is definitely one of JUTF7's aliases.

Is there a way to manually load the Charset or ensure that the Charset is being loaded so that I can rule that out as a cause?

Keeblebrox
  • 382
  • 4
  • 16

2 Answers2

7

There's a bit more to using a new Charset, apart from putting the necessary classes into the classpath. To quote the Javadocs:

A charset provider identifies itself with a provider-configuration file named java.nio.charset.spi.CharsetProvider in the resource directory META-INF/services. The file should contain a list of fully-qualified concrete charset-provider class names, one per line. [...]

( http://download.oracle.com/javase/6/docs/api/java/nio/charset/spi/CharsetProvider.html )

Is this special file present in the JAR?

sleske
  • 81,358
  • 34
  • 189
  • 227
  • That was the issue, thanks! In my efforts to avoid installing Apache Maven I did some quick source migration. I accidentally left the special file out of the jar as a result. I've built a jar with Maven, now, and the issue has been resolved. – Keeblebrox Jun 10 '11 at 19:36
2

You should make sure the jar is loaded by the main classloader. You can achieve this by adding the jar to the JVM's jre/lib/ext extension directory, or by adding it to the classpath of the main program. For example if you are using Tomcat, add -cp /path/to/jutf7.jar to Tomcat's startup script.

Similarly, if you want to test jutf7 from the scala REPL, you need to start it as follows

env JAVA_OPTS="-cp /path/to/jutf7-1.0.0.jar" scala

Tested with Java HotSpot(TM) 64-Bit Server VM (build 20.8-b03-424, mixed mode)

Erik van Oosten
  • 1,541
  • 14
  • 16