-
Notifications
You must be signed in to change notification settings - Fork 38.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"file:." cannot be resolved to java.nio.file.Path
(and plain "." value resolves to classpath root)
#33124
Comments
Hi @ewoerner, Congratulations on opening your first issue for the Spring Framework! 👍 What happens if you introduce the @Value("file:${dir}") |
@Value
injection of "." into Path
in native image
@sbrannen that causes injection to fail with any value, with the following stacktrace:
|
How about |
That also throws, but with a different root cause:
|
Thanks for trying out both of those variants and providing feedback! I unfortunately don't work on a Windows machine, so I don't have an easy way to test this. Though, perhaps one of my colleagues can test this on Windows. In the interim, please let us know which versions of the following you are using.
From the stack trace, I can deduce that you're using Spring Boot 3.3.1 with Spring Framework 6.1.10. |
There's not much Spring is doing around that call stack. Since you can easily reproduce, it would be helpful to see if the raw Java API usage throws that exception as well. Can you please replace the Paths.get(URI.create(".")); If this fails as well, we know we can close this in favour of a report in GraalVM itself. |
Version info, as requested: Turns out I did not test properly (I ran it from Eclipse), the exception is also reproducible without GraalVM when built as a JAR file:
So the chain seems to be as follows:
The error also happens with any other value that resolves to an existing resource, so --dir=application.properties also throws an Exception. |
@Value
injection of "." into Path
in native image
Without a prefix, Now, with a "." reference specifically, we may debate what that semantically means. According to the
|
I thought we did try to reproduce before asking you to change anything. Turns out that it fails on MacOS as well:
Sorry about that @ewoerner. So yeah, the bottom line is that you can't get a |
In general, the proper solution is to specify a "file:" prefix for an explicit file system reference there. That should also work for "file:." (as suggested above) but unfortunately doesn't, in contrast to |
java.nio.file.Path
(and plain "." value resolves to classpath root)
We're catching the |
Given the following stripped-down demo application:
When run using a JDK in Windows:
When run as native binary compiled with GraalVM:
Expected result for the third call: returns either "." or "", and does not throw an error on native
The text was updated successfully, but these errors were encountered: