On Tue, 8 Apr 2025 08:18:36 GMT, Danish Nawab wrote:
> ## Description
>
> https://bugs.openjdk.org/browse/JDK-8353840
>
> ### Existing behavior
> Log the error message and terminate in case of missing system class
>
>
> $ jnativescan --class-path reactor-core
On Tue, 8 Apr 2025 14:25:11 GMT, Danish Nawab wrote:
>> Changes look good, thanks!
>>
>> Please note that we will have to wait 24 hours before integrating, in order
>> to give other reviews time to look as well.
>
>> Changes look good, thanks!
>>
>
On Tue, 8 Apr 2025 14:19:07 GMT, Jorn Vernee wrote:
> Changes look good, thanks!
>
> Please note that we will have to wait 24 hours before integrating, in order
> to give other reviews time to look as well.
Great, thanks for your review!
I will wait until tomorrow to issue the `/integrate` (a
etailed/useful
>
> ### stdout vs stderr
>
> One could argue that since this is a non-terminal error, perhaps it should be
> logged to stdout. However, my thinking was that while it may be non-terminal,
> it is still an "error", and thus should be logged to stderr.
On Tue, 8 Apr 2025 12:22:40 GMT, Jorn Vernee wrote:
>> I see what you mean. Let me take a crack at it.
>
> One more thought: I think we should only print the error messages as part of
> `dumpAll` and not `printNativeAccess`, so that the result of the latter can
> still be piped directly to `--e
etailed/useful
>
> ### stdout vs stderr
>
> One could argue that since this is a non-terminal error, perhaps it should be
> logged to stdout. However, my thinking was that while it may be non-terminal,
> it is still an "error", and thus should be logged to stderr.
On Tue, 8 Apr 2025 13:43:54 GMT, Danish Nawab wrote:
>> ## Description
>>
>> https://bugs.openjdk.org/browse/JDK-8353840
>>
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>>
>>
>> $ jnati
On Tue, 8 Apr 2025 12:12:36 GMT, Jorn Vernee wrote:
>> ## Description
>>
>> https://bugs.openjdk.org/browse/JDK-8353840
>>
>> ### Existing behavior
>> Log the error message and terminate in case of missing system class
>>
>>
>> $ jnativescan --class-path reactor-core-3.7.4.jar; echo "Exit co
On Tue, 8 Apr 2025 11:55:58 GMT, Danish Nawab wrote:
>> Also, instead of passing `err` down to this code, I think we should define
>> an interface for `NativeMethodFinder` to log diagnostics instead. e.g.
>> something like:
>>
>>
>> interface Diagnostics {
On Tue, 8 Apr 2025 11:45:49 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java
>> line 91:
>>
>>> 89: err.println("Error while processing
>>> method: " +
>>> 90: MethodRef.of
Thanks for your analysis and explanation.
I took the liberty to propose a PR for JDK-8353840:
https://github.com/openjdk/jdk/pull/24499
I would really appreciate a review on this.
From: Jorn Vernee
Sent: Monday, April 7, 2025 3:46 AM
To: Danish Nawab ; core
## Description
https://bugs.openjdk.org/browse/JDK-8353840
### Existing behavior
Log the error message and terminate in case of missing system class
### New behavior
Still log the error message about the missing system class, but continue the
analysis
## Design choices
Propagate `err` all th
jnativescan terminates when ran on a JAR with a missing class.
Example:
```
jnativescan --class-path reactor-core-3.7.4.jar
ERROR: Error while processing method:
reactor.core.publisher.CallSiteSupplierFactory$SharedSecretsCallSiteSupplierFactory$TracingException::get()String
CAUSED BY: System cl
13 matches
Mail list logo
