RFE simplify usage of patched module [by Robert Scholte, from jdk-dev]

[Robert Scholte]

Hi Simone,

I understand your concern, but the patched module descriptor doesn't have to (or should not) replace the --patch-module option. This proposal is about the additional options you now need to put on the commandline, but which already fit in the module descriptor.

thanks,
Robert
On 5-2-2020 08:19:21, Simone Bordet <simone.bordet at gmail.com> wrote:
Hi,

> With the "patch modifier"-proposal applied as suggested by Robert,
> this manually constructed test module descriptor:
>
> open module foo {
> exports foo;
> requires org.junit.jupiter.api;
> }
>
> from [2] would shrink to:
>
> open patch module foo {
> requires org.junit.jupiter.api;
> }

While I was involved in the original report, I have concerns about its security.

Would not anyone be able to patch an existing module without the
author's consent?
For example:

patch module org.eclipse.jetty.client {
exports org.eclipse.jetty.client.internal;
opens org.eclipse.jetty.client;
}

Doing the same on the command line keeps the end user in control,
rather than having the end user possibly scan hundreds of jar to see
if someone snuck in a patched module descriptor.

However, the need for such "test" module descriptor is evident.

What if patched module descriptors are only effective when a command
line option is present, say "--allow-patch-descriptors", or something
like that?

Thanks!

--
Simone Bordet
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz