New candidate JEP: 400: UTF-8 by Default

Bernd Eckenfels ecki at
Thu Mar 11 02:27:05 UTC 2021


Thanks for the hint. The question is if this would return UTF-8 after the JEP is implemented or not (should probably be mentioned in the JEP). If it keeps returning the legacy/platform file encoding that would be a good API for my purpose (but sounds like that would be rather confusing in regards to the default constructor)

Von: Remi Forax <forax at>
Gesendet: Thursday, March 11, 2021 2:19:19 AM
An: Bernd Eckenfels <ecki at>
Cc: core-libs-dev <core-libs-dev at>; jdk-dev <jdk-dev at>
Betreff: Re: New candidate JEP: 400: UTF-8 by Default

----- Mail original -----
> De: "Bernd Eckenfels" <ecki at>
> À: "core-libs-dev" <core-libs-dev at>
> Cc: "jdk-dev" <jdk-dev at>
> Envoyé: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
> For example, in our server application, we do have some code which is specified
> as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
> I understand that this might have it’s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to today’s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

FileReader has a method named getEncoding()

> Gruss
> Bernd
> --


More information about the jdk-dev mailing list