Post by Ess KayPost by David M. LloydJava EE and JBoss Modules both allow this
Two points. Firstly there is a big difference between a character being
allowed and the character actually being used in practice. Are you
saying that in practice anyone anywhere is putting spaces, single quotes
or double quotes within a Java EE and JBoss module name? If the answer
is yes then how common would that be?
I don't have metrics, of course; one only needs to know the API contract
to know that this is allowed. But it is completely irrelevant to the
discussion of the requirement at any rate because you're confusing a few
things which I'll outline down below.
Post by Ess KayAlso, do Java EE and JBoss module names currently allow the characters
in the range 0x00 to 0x1F? If the answer is yes then 100% compatibility
with Java 9 module names is already gone.
Yes it's allowed (not 0x00 but the others are), but I don't think there
is any practical way to actually accomplish injecting most of those
values (at least in a Java EE situation), nor have I ever seen it happen
in practice.
Post by Ess KayThe second point is that we are now talking about Java 9 module names
being embedded as identifiers within Java class files where they will
directly affect downstream users. This was not the case with Java EE
and JBoss Module names. This is a much, much bigger deal.
No, that's not how it works at all. Java source modules can only
reference other Java source modules; nobody is going to be shocked that
you can't reference a manually-built module from a Java source module.
There's nothing to affect downstream users. Only container code will be
creating or referencing such modules.
Post by Ess KayPost by David M. LloydThere has been plenty of serious thought
In the jpms-spec-experts list it is suggested that "for sanity" Java 9
module names should not contain "any character whose Unicode code point
is less than 0x20". Yet the DEL (0x127) character is allowed?
Taking a step backwards, it would appear that it was never considered
that Java 9 module names might need be be specified as identifiers in
existing bytecode processing scripting languages. That is 100%
understandable. However, now that it is known that that is the case,
doesn't it make sense "for sanity" to not allow a Java 9 module name to
contain spaces, single quotes, double quotes, semicolons or asterixes?
From the perspective of container code, those "sanity" characters are
selected completely arbitrarily. They have various usages in various
contexts, but any given module layer implementation doesn't necessarily
align with any of those contexts. For example there may be different
characters which don't make sense, while some of the examples you listed
do. So it makes the most sense to allow anything at the bytecode level,
and rely on the module layer implementation to apply the appropriate policy.
Post by Ess KayThe problem with spaces, single quotes, double quotes in an identifier
that needs to be parsed from a text file is obvious.
Sure, but the lenient rules only apply to class files that were manually
generated. There are zero cases where one would have to parse an
arbitrary module identifier from a text file; every module layer
provider is going to have their own syntax and naming policy.
Post by Ess KayAs mentioned
earlier, the problem with semicolons is that they are commonly used as
terminators in the scripting languages which nearly always use a Java
style syntax. The problem with asterixes is that they are commonly used
as a wildcard character in identifiers in the languages.
In the language, the module identifier is bounded by quite strict
syntax. Modules which are distributed for downstream consumption will
likewise adhere to these criteria (they have no way to avoid it short of
weird bytecode hacking). The only time the more general rules come into
play is when modules are being generated at run time from other module
systems and setups.
Let me put it another way.
Every module system has its own rules and restrictions for how a module
can be named. Those restrictions do not all exactly align. If you ban
the union of all the disallowed characters in all module systems, then
all module systems will break. However if you only ban the intersection
of such systems (i.e. control characters), and allow each layer to
enforce its own policy, then every system will work and interoperate as
expected. There is no downside because anyone who "cleverly" hacks
bytecode to produce a vanilla module with an invalid name will soon
realize that their module can never be found. A user has to go to
extraordinary measures to do so, so there is very little risk of such a
thing happening nor is there a risk of it impacting users in any
relevant way.
Everyone has their own notion of what "offensive" characters would be.
But enforcing these rules is and can only be the job of the layer provider.
Post by Ess KayHi Rémi,
You can update your tool to use an escape character
Sure. However, can you imagine how much work it would be to update a Java
source parser to allow identifiers like package and class names to contain
escaped semi-colons, single quotes or double quotes? My scenario and that
of many others is the same. It can be done but the result will be ugly.
I repeat my earlier question, are there existing module systems out there
that allow spaces, quotes and semi colons to appear in a module name?
Yes. Java EE and JBoss Modules both allow this, as do systems where
a file name is a module name.
All I ask is that serious thought be given to how much
flexibility is
really needed in a module name. There are signs that there has not yet
been much serious thought. For example backspace is not allowed but DEL
(0x127) is allowed.
There has been plenty of serious thought, and I agree that we should
be disallowing all Unicode controls of any kind, but my
understanding is that there are implementation complexities involved
which make this somehow impractical. However UTF-8 parsing is not
difficult so hopefully this can be revisited at some point.
--
- DML
--
- DML