JVM default encoding is not set to UTF-8

[LukaszHoldrowicz-TomTom]

What happened?

Docker image prepared by paketo-buildpacks/bellsoft-liberica using spring-boot-maven-plugin in version 2.3.12.RELEASE is not using UTF-8 as default encoding. UTF-8 encoding is most common encoding type and should be used as a default one.

• What were you attempting to do?
  Integrate java spring-boot application with azure blob storage using com.azure.azure-storage-blob in version 12.6.0 and list blobs which under the hood query azure backend for xml response.

• What did you expect to happen?
  Default encoding of JVM is set to UTF-8 because it's most common encoding.

• What was the actual behavior? Please provide log output, if possible.
  Request listing blob return xml with BOM for UTF-8 <?xml version="1.0" encoding="utf-8"?> which is then incorrectly parsed.

Below log is from spring boot application at runtime (not from buildpack build process).

Caused by: com.azure.core.exception.HttpResponseException: HTTP response has a malformed body.
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.lambda$decode$1(HttpResponseBodyDecoder.java:95)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:118)
	at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123)
	at reactor.core.publisher.FluxHandle$HandleSubscriber.onNext(FluxHandle.java:112)
	at reactor.core.publisher.FluxMap$MapConditionalSubscriber.onNext(FluxMap.java:213)
	at reactor.core.publisher.FluxDoFinally$DoFinallySubscriber.onNext(FluxDoFinally.java:123)
	at reactor.core.publisher.FluxHandleFuseable$HandleFuseableSubscriber.onNext(FluxHandleFuseable.java:178)
	at reactor.core.publisher.FluxContextStart$ContextStartSubscriber.onNext(FluxContextStart.java:96)
	at reactor.core.publisher.Operators$MonoSubscriber.complete(Operators.java:1812)
	at reactor.core.publisher.MonoCollectList$MonoCollectListSubscriber.onComplete(MonoCollectList.java:121)
	at reactor.core.publisher.FluxPeek$PeekSubscriber.onComplete(FluxPeek.java:252)
	at reactor.core.publisher.FluxMap$MapSubscriber.onComplete(FluxMap.java:136)
	at reactor.netty.channel.FluxReceive.onInboundComplete(FluxReceive.java:383)
	at reactor.netty.channel.ChannelOperations.onInboundComplete(ChannelOperations.java:373)
	at reactor.netty.channel.ChannelOperations.terminate(ChannelOperations.java:429)
	at reactor.netty.http.client.HttpClientOperations.onInboundNext(HttpClientOperations.java:655)
	at reactor.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:96)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:436)
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:324)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
	at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:251)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1368)
	at io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1245)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1282)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:507)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:446)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:276)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795)
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	... 1 more
Caused by: com.azure.core.implementation.serializer.MalformedValueException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.azure.core.util.serializer.JacksonAdapter.deserialize(JacksonAdapter.java:184)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.deserializeBody(HttpResponseBodyDecoder.java:176)
	at com.azure.core.implementation.serializer.HttpResponseBodyDecoder.lambda$decode$1(HttpResponseBodyDecoder.java:88)
	... 46 more
Caused by: com.fasterxml.jackson.core.JsonParseException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.fasterxml.jackson.dataformat.xml.util.StaxUtil.throwAsParseException(StaxUtil.java:37)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory._createParser(XmlFactory.java:584)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory.createParser(XmlFactory.java:464)
	at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3468)
	at com.azure.core.util.serializer.JacksonAdapter.deserialize(JacksonAdapter.java:179)
	... 48 more
Caused by: com.ctc.wstx.exc.WstxIOException: Unexpected first character (char code 0xEF), not valid in xml document: could be mangled UTF-8 BOM marker. Make sure that the Reader uses correct encoding or pass an InputStream instead
	at com.ctc.wstx.io.ReaderBootstrapper.bootstrapInput(ReaderBootstrapper.java:175)
	at com.ctc.wstx.stax.WstxInputFactory.doCreateSR(WstxInputFactory.java:573)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:633)
	at com.ctc.wstx.stax.WstxInputFactory.createSR(WstxInputFactory.java:687)
	at com.ctc.wstx.stax.WstxInputFactory.createXMLStreamReader(WstxInputFactory.java:350)
	at com.fasterxml.jackson.dataformat.xml.XmlFactory._createParser(XmlFactory.java:582)
	... 51 more

Build Configuration

default spring boot configuration in version boot 2.3.12.RELEASE

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <layers>
            <enabled>true</enabled>
        </layers>
        <image>
            <name>${docker-image-name}</name>
            <env>
                <BP_JVM_VERSION>${project.java.source}</BP_JVM_VERSION>
            </env>
        </image>
    </configuration>
</plugin>

Problem can be solved by passing JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 but it's not obvious at the beginning

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

[dmikusa]

I'm not inclined to set this because I think it's more of a concern for an application developer. If the default works, great, but if not I think the application developer should choose what encoding to use.

I'm also concerned about diverging from the default behavior in Java. Java has a defined behavior for how it determines the default character set. It's generally well-known, documented, and easy to search and find information about. If the buildpack changes this default behavior, that could create problems for someone also, someone expecting the default behavior.

As you mentioned, you can set -Dfile.encoding=UTF-8 if you like or you can use these instructions to set the locale which influences the JVMs default decision.

Beyond that, I would say let's keep this issue open and let it gather feedback. If there are enough people interested in the buildpack setting the default character set and none opposing it, then we can revisit making this change.

If you're in favor of this, please 👍. If you think we should keep the JVM default, 👎 . Thanks

[LukaszHoldrowicz-TomTom]

@dmikusa-pivotal i can't find it in JVM documentation but i'm pretty sure that default encoding is set based on operating system, user locale running JVM and others. So default encoding other than UTF-8 comes from base docker image, not from JVM itself.

[dmikusa]

i can't find it in JVM documentation but i'm pretty sure that default encoding is set based on operating system, user locale running JVM and others.

The default behavior of the JVM on Linux is to use the locale. It's in the Javadoc, https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html and StackOverflow, and other places if you search for "java default character set". As always Baeldung has a great write-up.

So default encoding other than UTF-8 comes from base docker image, not from JVM itself.

Correct, but the buildpack doesn't provide the base image. The buildpack can run on any number of different base images and so the locale could differ depending on the base image. If we set this value in the buildpack and it'll squash the default behavior. That means that the buildpack is doing something unique and potentially unexpected to users (like if you set the locale in your base image and expected it to use that).

Again, I'm not necessarily opposed to changing it. It's a default though, so we have to be particularly careful about changing defaults. Thus I'd like to get feedback before doing it. If this seems to be generally useful, then we can move ahead with it.

[tgeens]

Just FYI: Java 18 will use UTF-8 by default - see https://openjdk.java.net/jeps/400

[dmikusa]

I would like to close this out because I don't think we want to have special behavior for the buildpacks. We are also rolling out Java 18 support now, which defaults to UTF-8, and there are also multiple easy fixes if you want to force UTF-8 and are not able to use the latest version.

pack build -e JAVA_TOOL_OPTIONS=-Dfile.encoding=UTF-8 ...

or

pack build -e LANG=en_US.utf8 ...

You could also use the environment-variables buildpack and embed LANG=en_US.utf8 if you don't want to have to set that on build and run.

pack build -e $BPE_DEFAULT_LANG=en_US.utf8 ...

[Schaka]

I ended up here, because this doesn't work for native images.
You can find my specific issue here: paketo-buildpacks/native-image#344

Since it's not using a JVM, it's not honoring JAVA_OPTS or JAVA_TOOL_OPTIONS. Or at least not delegating to the container.

Passing them as environment variables to the container also doesn't work, as they're not used in the startup command that calls the native executable.

The only way to work around that is either
docker run imagehere -Dsun.jnu.encoding=UTF-8

or

services:
  janitorr:
    container_name: janitorr
    image: ghcr.io/schaka/janitorr:native-amd64-80-merge
    command: -Dsun.jnu.encoding=UTF-8
    user: 1000:1000