You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SDKMAN seems like a useful thing, so I guess one would also want to have its configuration file in the development environment. From the documentation, there's some friction involved when using it on Windows, so I may only adopt it myself on the holiday laptop, which is Linux.
I don't tear my development environment down between tasks, as one might a Python virtual environment and re-build it from the requirements file. Those who develop using a containerised IDE might appreciate the configuration arriving with the project files. Is the idea to support that kind of working? Isn't there usually a user-specific profile too?
As things stand, though, we don't check-in configuration files for IDEs, but "support" those IDEs through .gitignore.
I notice these pin the build tool and JDK to particular micro-versions. Won't we find we're either pinned to an old version, or constantly updating this file? I think the argument is different for dependencies (JARs) that we bundle in the fat JARs or communicate in the POM, because we test with those. Even there, it is a real nuisance if it really matters exactly which versions are used.
there's some friction involved when using it on Windows
@jeff5, not too much friction. I use it rather seamlessly via Git-Bash after also installing zip.exe which is needed by the SDKMAN install script run from Git-Bash. Once SDKMAN is installed, it is very simple to use it to activate a known tool set.
I just ran the following commands on my Windows PC just now.
Is the idea to support that kind of working?
No. IDE specific information is not stored.
Isn't there usually a user-specific profile too?
No. User specific information is not saved.
SDKMAN simply ensures that the correct version of the required build tools are activated and made available on the command-line.
I notice these pin the build tool and JDK to particular micro-versions.
Won't we find we're either pinned to an old version, or constantly updating this file?
The upside of pinning the versions is that all developers then have bug-compatible versions of the build tools and should consistently see / encounter the same issues or be able to reproduce issues reported by other developers.
The tool versions should not have to change often, maybe only once or twice a year.
The Spring Framework use SDKMAN to specify the version of Java to use to build Spring, see .sdkmanrc file:
The Git-Bash shell can be registered with the Windows Terminal program, making it easy to choose which shell program to use for a specific command-line session.
Activity
jeff5 commentedon May 4, 2025
SDKMAN seems like a useful thing, so I guess one would also want to have its configuration file in the development environment. From the documentation, there's some friction involved when using it on Windows, so I may only adopt it myself on the holiday laptop, which is Linux.
I don't tear my development environment down between tasks, as one might a Python virtual environment and re-build it from the requirements file. Those who develop using a containerised IDE might appreciate the configuration arriving with the project files. Is the idea to support that kind of working? Isn't there usually a user-specific profile too?
As things stand, though, we don't check-in configuration files for IDEs, but "support" those IDEs through
.gitignore.I notice these pin the build tool and JDK to particular micro-versions. Won't we find we're either pinned to an old version, or constantly updating this file? I think the argument is different for dependencies (JARs) that we bundle in the fat JARs or communicate in the POM, because we test with those. Even there, it is a real nuisance if it really matters exactly which versions are used.
koppor commentedon May 16, 2025
.sdkmanrcfiles are also compatible withmise. One could even set both the requiredjavaandpythonversion.Note that
java@21is perfectly valid. Thus, no micro-versioning, but "pinning" to some main java releases.wfouche commentedon Jun 3, 2025
@jeff5, not too much friction. I use it rather seamlessly via Git-Bash after also installing zip.exe which is needed by the SDKMAN install script run from Git-Bash. Once SDKMAN is installed, it is very simple to use it to activate a known tool set.
I just ran the following commands on my Windows PC just now.
No. IDE specific information is not stored.
No. User specific information is not saved.
SDKMAN simply ensures that the correct version of the required build tools are activated and made available on the command-line.
The upside of pinning the versions is that all developers then have bug-compatible versions of the build tools and should consistently see / encounter the same issues or be able to reproduce issues reported by other developers.
The tool versions should not have to change often, maybe only once or twice a year.
The Spring Framework use SDKMAN to specify the version of Java to use to build Spring, see .sdkmanrc file:
The Git-Bash shell can be registered with the Windows Terminal program, making it easy to choose which shell program to use for a specific command-line session.
wfouche commentedon Jun 3, 2025
@koppor , I'm not familiar with
misebut will check it out.