4 ms·
Developers should understand if a dependency use C bindings. But why bother end users with a command line flag. Perhaps there is a manifest entry/flag so the c
by _old_dude_ 3y ago
Developers should understand if a dependency use C bindings. But why bother end users with a command line flag.
Perhaps there is a manifest entry/flag so the command line flag is not required ?
- pron 3y ago1. Application developers frequently don't know how the libraries they're using work, and often don't even know what libraries they're using because they're transitive dependencies (even a version update of a library can pull in a new transitive dependency). If a library imposes any kind of risk on the application, the application has to acknowledge that it accepts it. 2. The last word is given to the application, and the point is that libraries must not make decisions that have a global impact on behalf of the application. That's why an executable JAR, i.e. an application, can grant such permission in its manifest but library JARs cannot. See more here: https://openjdk.org/jeps/8305968 https://openjdk.org/jeps/8305968, https://openjdk.org/jeps/8307341 https://openjdk.org/jeps/8307341
- josephcsible 3y ago> an executable JAR, i.e. an application, can grant such permission in its manifest No it can't. If it would, then the change indeed wouldn't be a problem. Oracle has removed --illegal-access=permit completely, and --add-opens doesn't let you specify wildcards.
- pron 3y agoThe question I answered was about --enable-native-access, not --add-opens. --add-opens indicates an actual problem in the program that has to be fixed, so of course we don't allow wildcards. You can still specify that in the manifest even without wildcards, though.