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.bor...@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
