Copilot commented on code in PR #1945:
URL: https://github.com/apache/maven-resolver/pull/1945#discussion_r3535133073
##########
maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:
##########
@@ -262,7 +263,15 @@ SocketChannel createClient() throws IOException {
private String getJarPath(Class<?> clazz) {
String classpath;
String className = clazz.getName().replace('.', '/') + ".class";
- String url = clazz.getClassLoader().getResource(className).toString();
+ ClassLoader classLoader = clazz.getClassLoader();
+ if (classLoader == null) {
+ classLoader = ClassLoader.getSystemClassLoader();
+ }
+ URL resource = classLoader.getResource(className);
+ if (resource == null) {
+ throw new IllegalStateException("Unable to find resource for class
" + clazz.getName());
+ }
Review Comment:
Fallback to `ClassLoader.getSystemClassLoader()` does not reliably locate
resources for bootstrap-loaded classes (where `clazz.getClassLoader()` is
null). This can still make `resource` null for JDK classes. Prefer resolving
the `.class` resource via `clazz.getResource(...)` (which supports
bootstrap-loaded classes) and only fall back to a classloader-based lookup if
needed.
##########
maven-resolver-named-locks-ipc/src/main/java/org/eclipse/aether/named/ipc/IpcClient.java:
##########
@@ -262,7 +263,15 @@ SocketChannel createClient() throws IOException {
private String getJarPath(Class<?> clazz) {
String classpath;
String className = clazz.getName().replace('.', '/') + ".class";
- String url = clazz.getClassLoader().getResource(className).toString();
+ ClassLoader classLoader = clazz.getClassLoader();
+ if (classLoader == null) {
+ classLoader = ClassLoader.getSystemClassLoader();
+ }
+ URL resource = classLoader.getResource(className);
+ if (resource == null) {
+ throw new IllegalStateException("Unable to find resource for class
" + clazz.getName());
+ }
Review Comment:
Throwing `IllegalStateException` here may bypass existing
`IOException`-based error handling higher up (e.g., connection setup paths that
already declare/handle `IOException`). Consider converting this failure into an
`IOException` (or an unchecked exception type consistently handled by the
caller) so the failure mode is predictable and does not unexpectedly terminate
IPC client setup.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
