On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee wrote:
> It looks like it's possible to get even more custom by using a custom
> `HelpFormatter` as well, if we wanted.
I think what you have is okay for the first integration, just looks odd to have
the help/usage say "String" and "Path". Using a
On Thu, 20 Jun 2024 17:44:54 GMT, Alan Bateman wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 113:
>>
>>> 111: // Class-Path attribute specifies that jars that
>>> 112: // are not found are simply ignored. Do
On Thu, 20 Jun 2024 19:37:23 GMT, Jorn Vernee wrote:
> I've massaged the parsing code to where the help message now looks like this:
It is better but it might mean looking at HelpFormatter as you mentioned,.
Right now the usage message `--add-modules ` whereas the java --help
will print `--add
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 20 Jun 2024 16:13:04 GMT, Alan Bateman wrote:
> Another thing is that using joptsimple gives up a bit of control, e.g. the
> help output shows the parameter for --class-path as `` where the java
> launcher and other tools will show "path" or "class path". Same thing with
> `--release`
On Thu, 20 Jun 2024 17:40:25 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNative
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Wed, 19 Jun 2024 21:13:33 GMT, Maurizio Cimadamore
wrote:
>> What do you suggest? Just a note in the error message that exploded
>> modules/class paths are not supported?
>
> Something like that yes
An altermative is to use ResolvedModule::reference to get a ModuleReference,
then use its o
On Tue, 18 Jun 2024 16:35:10 GMT, Jorn Vernee wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update man page header to be consisten with the others
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JD
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
On Thu, 20 Jun 2024 12:51:22 GMT, Evemose wrote:
> wouldn't it be better to create one uniform tool
See my reply here:
https://github.com/openjdk/jdk/pull/19774#issuecomment-2179078565
-
PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180653743
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool accepts
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
> `--
14 matches
Mail list logo
