-
-
Notifications
You must be signed in to change notification settings - Fork 628
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
It should be possible to use system artifact instead of sdkman's #673
Comments
I've got to say that I really like the idea of introducing the new In addition I would introduce another new command as counterpart to the So, this is what you would have:
Does this sound like an acceptable approach to everyone? |
I must admit I rather like the other approach:
I think I just more used to that approach in other tools like rvm or pyenv. It's also more in line with other commands of sdkman. I think it will be easier to remember for users. But adding two new commands is just fine as well. It's basically the choosing between:
|
+0 for virtual version. |
@vmj did you mean +1? 😀 |
@marc0der 😄 no, I meant "I don't feel strongly, but if this happens, the virtual version seemed more natural". But now that I think about it more, what would the "system" version be for candidates that do not have any system counterpart or have multiple? It's probably "whatever the system was set up it to be". I.e. sdkman will just step aside and let things be as messy as they were before it. In that case, I feel that unuse/system commands might be a bit easier to understand:
So yes, I'm changing my vote to "+0 for new commands". Sorry 😜 But maybe the name of the |
@vmj no worries! thanks for clarifying. And yes, good point about |
If you are going for new methods maybe better names will be:
As you see, default is also not a verb. Maybe change to |
@cardil we are using |
Why not simply check if it exists and if there is no system-wide available installation then ask user’s confirmation if that is surely what is wanted? For multiple choices, sdk can use the system’s alternatives/default resolution tool to show current OS default version like update-alternatives does in Ubuntu for an example. Hm… maybe sdk can use system alternatives/default configuration tools to show system version in listing as well while using new version marking like “s” (lowercase) for system-wide available and “S” (uppercase) for currently set system wide default version in addition to “+” and “*”? |
Introducing a dependency on tools that are available only on certain platforms is not good because we would need to start maintaining code branches for every platform under the sun. At the moment sdkman is decoupled as much as possible from it's environment and I think we should keep it that way. Therefore I'm not in favour of depending on tools like
It's not that simple. We don't know what we are checking for as sdkman is completely agnostic of the contents of the sdks that it serves. ie. we don't know (and don't want to care) what's in the |
Uprate-alternatives requires root access. Sdkman is user space program, it shouldn't rely on update-alternatives. System option is pretty good option even you got nothing installed on system. You are using system, but there nothing there so it effectively unset a tool and disable it's usage. |
Came across the need to do this today... I have Oracle JDK 7 & 8 installed on mac using the installer(s) and OpenJDK 10 & 11 using sdkman. Switching back to either of the "system" versions after switching to sdk managed version requires mucking about with the +1 for |
@martin-walsh That is absolutely not necessary. Simply use sdkman's local version feature: |
@marc0der The local version feature does not seem to work as documented in https://sdkman.io/usage#localversion |
Local feature works a charm for me on macOS!
SDKMAN 5.7.3+337 |
@hickst It certainly is working. Try using a version that is unique. I think |
Success! Thanks for clarifying how it works. The fact that you cannot use the same name as |
Even better, maybe sdkman itself should tell you that it is a reserved version string. Wdyt? |
@marc0der Yes, having the tool itself help one to do it correctly definitely sounds like the best idea. I also recommend a "local" Java example in the documentation, similar to the one @martin-walsh showed above (thanks for the help @martin-walsh!) |
@hickst afaik, it is already documented. Regarding letting the tool itself help you do it correctly, want to raise a PR for that one? |
@marc0der which "it" is already documented? In the documentation for
would become
|
@marc0der I would be happy to open a new issue but do we need to move this discussion to Gitter before I am allowed to do that? |
Don't worry about the gitter discussion. You can update the website docs in this project with a PR: Of course the help can be updated in this project. |
May I also suggest an E.g. |
@jamesdh that might be confusing for users as the |
@marc0der isn't that In any case, it'd be nice to somehow remove any link to an installed version without actually uninstalling. |
@jamesdh yes you're right, my bad. |
I would also like to express my support for this functionality. I've installed graalvm with sdk to play around with native compilation. If there was an option to disable/unset sdk graal then I could have avoided the un-instalation. I do hope sdkman implements this functionality. It is necessary. |
@ieugen a better workaround is probably to install the default JDK (AdoptOpenJDK) and make that your system default. Then you shouldn't have any conflicts with Node. You can then apply the |
Thanks that is a good suggestion. I do have an issue with it. I already have adoptopenjdk installed via Debian package system. I do prefer that since I have unattended-upgrades in place. |
Some feedback. The sdk use java XXX method works. However I still need to keep the java version installed in Debian since I have other packages that depend on it. This does/can create some issues:
|
Using a localversion Java also worked for me. I am still unhappy about the fact, that sdkman sets JAVA_HOME to ~/.sdkman/candidates/java/current if I wish to use the system Java. I wish a solution which lets JAVA_HOME as it is defined by the system. |
Ive discovered that a simple aproach is to use an bash function to enable sdkman, just enclose the 2 sdkamn lines into a function and call them if you need sdkman, but once loaded i dont know how a clean way to unload it would look like. |
I was able to link system java sdk to sdkman using Install local version https://sdkman.io/usage#localversion. For example:
Apply the local sdk version
List all java version from sdk
|
Any news on this? sdkman is basically breaking my Debian system, insisting in wanting to set its own |
Under Arch Linux, there is a way to create the virtual
Since /usr/lib/jvm/default is a symlink managed by However, it would be much nicer if SDKMan rather can roll back the changes in the environment regarding to the Java Runtime, and let system's default behavior happen whatever is that. |
Please tick one:
Please explain the Issue / Feature Request here:
It's currently impossible, after using sdkman, to restore Java to use default installed in operation system. It should be possible to do that, even temporarly.
It's done this way by multiple tool version managers like:
I think sdkman could simply remove current binding for a tool with special command, removing
current
symlink for example:sdk use java system
or
sdk unuse java
The text was updated successfully, but these errors were encountered: