Making the source code utf-8

[Stuart Marks]

On 2/8/23 11:42 AM, Magnus Ihse Bursie wrote:
>
> I think you hit the nail on the head. We only want "controlled" use of non-ASCII.
>
> A first step towards this is understanding what files we have today that are 
> non-ASCII. I made a script some years ago that went through the repo and reported 
> non-ASCII files (this is not as trivial as it sounds, since with too much 
> non-ASCII characters files start looking like binaries, and binary files are of 
> course allowed to have non-ASCII characters in them). I need to dig up that 
> script, make another pass over the code base, and classify what kind of non-ASCII 
> files we have.
>
Yes, it would be really good to have this information.

> As for a JEP, there is precedent for JEPs to cover things about the code base 
> itself, such as the modular source layout (JEP 201) and Git/GitHub migration (JEP 
> 357 and JEP 369). Once things settle out, it would be good to document a policy 
> for what files must be in what encodings, and how this is enforced. This could be 
> an informational JEP, if the overhead of publishing it isn't too high. (An 
> alternative might be a README in the repo itself.)
>
> So, what you are saying is, you can do a JEP but you can also just write a README? 
> :-) I think this means the question of a JEP or not is still open. Or did you mean 
> that the precedents implied that it would indeed be good to have a JEP about 
> source code changes, and not just a post-factum informational JEP?
>
Yes, I guess the question of a JEP is still open.

I wasn't advocating for or against a JEP; I was merely pointing out that there is 
precedent for JEPs to cover things that are going on with the OpenJDK project and 
source code itself and that don't affect people who are using Java and the JDK.

I think that *IF* there is going to be JEP, it would be sufficient to have an 
after-the-fact informational JEP that describes the policy going forward along with 
a bit explanation and rationale.

I do not think it's necessary or useful to draft a JEP up front, have a bunch of 
discussion and review of its text, get the JEP approved, and *then* proceed to 
implement it. I believe that with changes of this nature (build system, source code 
repo, etc.) one tends to discover new issues while things are in progress, and 
decisions are made that will cause course changes and that will affect the final 
outcome. This tends to invalidate documents and decisions made up front. It's 
probably easier to go through the process and then document where we ended up 
after-the-fact.

That said, that documentation could just as well be in a README instead of a JEP. I 
just want to make sure it gets written down in a good place so that people don't 
have to go digging through email threads (like this one) to figure out what happened.

s'marks