RFR: JDK-8264488: Improve warning for module names ending with digits

[Alex Buckley]

On 5/23/2023 10:37 PM, Sebastian Stenzel wrote:
> On Wed, 24 May 2023 02:33:40 GMT, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
>> module name {0} should not end with a number, since it may be wrongly interpreted as a version number
> 
> Still confusing: The warning is not to avoid module consumers from _wrongly interpreting_ terminal digits such as in PKCS11 as a version number. It rather warns the module publisher to not append any version number to the module name.
> 
> How about: `module name {0} ends on terminal digits, which must not encode a version number`

"terminal digits" means "the digits at the end", so there's no need to 
say "ends on" -- it would just be "module name {0} has terminal digits". 
In any case, "terminal digits" is a dense phrase that appeals to the 
technical construct of "Java digit" without spelling it out -- this is 
hard work for readers -- "number" is more straightforward.

Also, the phrase "must not" is inappropriate for a warning message. 
"must not" is for error messages.

Here's a rewrite of your suggestion:

   module name {0} ends with a number, which should not encode a version

The good thing about this text is that it starts by stating a fact, and 
only then (after the comma) presenting a judgement. That's how we phrase 
run-time warnings for illegal reflective access and for dynamic 
installation of a Security Manager 
(https://openjdk.org/jeps/411#Issue-warnings). However, javac warnings 
need to be brief, and tend to skip directly to the judgement that X is bad.

Also, this text is pretty easy to read as saying that the number 
_currently_ encodes a version, which will confuse the org.foo.lib.pkcs11 
crowd whose number is not a version.

Here's a plainspoken warning to the module publisher about what they 
have done by calling their module `com.bar.lib_v2` or `org.baz.framework3`:

   module name {0} ends with a number that looks like a version

Alex