fix: fixed issue with linked() and real paths#110
Conversation
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one) (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The issue was that `linked()` calls `toRealPath()` on a Jdk's home path and then asks all providers which of them manages the Jdk that it points to, using a call to `getInstalledByPath()`. However, if the provider was intialized with a path that contains symlinks, it would not be able to find the Jdk, because the path it was initialized with would not match the real path. The soution was to call `toRealPath()` on the provider's path during initialization.
|
In the end the solution was pretty similar to what your AI PR suggested, just a bit simpler. And at least I understand why this is a good solution at least :-) |
1 participant
The issue was that
linked()callstoRealPath()on a Jdk's home path and then asks all providers which of them manages the Jdk that it points to, using a call togetInstalledByPath(). However, if the provider was intialized with a path that contains symlinks, it would not be able to find the Jdk, because the path it was initialized with would not match the real path. The soution was to calltoRealPath()on the provider's path during initialization.We only do this for providers that don't really care about or deal with links. Providers that specifically deal with links, like the "default" and "linked" providers, are left as-is.