Proposal: #ModuleNameCharacters (revised)
forax at univ-mlv.fr
forax at univ-mlv.fr
Tue Dec 13 08:12:42 UTC 2016
I think part of the problem is that currently the builder enforces some rules and it should not,
the fact that a ModuleDescriptor is well formed or not should be checked by the configuration and not by the builder itself.
Checks that need to be done:
- no repetition, the ModuleDecriptor interface uses Set so this is enforced by design
- all referenced packages should be present in packages,
currently, the builder see that the other way around, i think it's a mistake.
This parts should be moved when resolving a configuation
- referenced modules exist, this part is already checked when resolving the configuration
- metadata associated with the module descriptor, version, main-class, hashes, all of these should be specified through a kind of Map API,
so build tool/language developers, JDK maintainers could add any metadata when they want.
- the builder should only build a descriptor and not check if it is well formed or not
- when resolving the configuration, additional checks should be done to verify that a module descriptor is well formed
- add a way to specify additional metadata to the module descriptor.
----- Mail original -----
> De: "mark reinhold" <mark.reinhold at oracle.com>
> À: "David M. Lloyd" <david.lloyd at redhat.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, jpms-spec-experts at openjdk.java.net
> Envoyé: Mardi 13 Décembre 2016 00:47:30
> Objet: Re: Proposal: #ModuleNameCharacters (revised)
> 2016/12/10 7:24:18 -0800, david.lloyd at redhat.com:
>> On 12/10/2016 01:50 AM, Remi Forax wrote:
>>> On December 9, 2016 11:05:02 PM GMT+01:00, david.lloyd at redhat.com wrote:
>>>> So... essentially a custom module system has to generate binary
>>>> descriptors? That's going to be a real pain.
>>> No, i hope it's more that ModuleDescriptor will be an interface.
>>> So we can have our own module descriptor builder.
>> Well, maybe we can build on this idea: what about making
>> ModuleDescriptor.Builder non-final, so we can push validation logic into
>> separate overridable methods? This way the default behavior is
>> consistent, and it's much harder to accidentally bypass the logic, but
>> it's also still easy to provide a customized scheme.
> This is easier said than done, and I'm skeptical that the result would
> be of use to more than an extraordinarily small number of developers.
> I don't think it's unreasonable to ask the very, very few people who
> will want unusual module names to roll their own binary descriptors.
> - Mark
More information about the jpms-spec-experts