If you need to manage multiple JDKs or other SDKs on one machine, Install SDKMAN on Fedora 44 gives you a clean and repeatable workflow. This guide shows the full setup, explains what each command does, and tells you why each step matters.

SDKMAN is a shell-based tool for installing and switching software development kits from the command line. On Fedora 44, it is a strong fit for developers, sysadmins, and anyone who needs version control without manual tarball handling.

A good setup also avoids the usual traps, like missing dependencies, shell init problems, and broken PATH changes. You will get a practical SDKMAN on Fedora 44 setup that is easy to follow and safe to repeat.

Prerequisites

• Fedora 44 installed and updated.
• A user account with sudo access.
• A working internet connection.
• A Bash or Zsh shell.
• Required tools: curl, zip, unzip, and sed.
• Enough disk space in your home directory for SDK downloads and installed candidates.

These tools matter because the installer downloads files, extracts archives, and updates shell config files. Without them, the installation can fail or leave SDKMAN only half configured.

Step 1: Update your system

Keeping Fedora current reduces the chance of package conflicts and broken dependencies.

Run a system refresh

sudo dnf upgrade --refresh -y

This command refreshes package metadata and installs available updates. It helps ensure your system uses the latest package information before you add SDKMAN dependencies.

Expected output includes repository metadata checks and package update progress. You should see DNF finish without errors.

Why this matters

A fresh metadata cache lowers the risk of installing outdated packages. It also gives you a cleaner base for the rest of the setup, which is a good habit for any Linux server tutorial or workstation guide.

Step 2: Install required packages

SDKMAN depends on a few standard utilities to work correctly.

Install the tools

sudo dnf install -y curl zip unzip sed

This installs the core tools needed by the installer and SDK archive handling. curl fetches the installer, zip and unzip handle archive files, and sed helps the installer process shell config changes.

Check the tools

curl --version
zip -v
unzip -v
sed --version

These commands confirm the binaries are present and usable. If one of them fails, SDKMAN may not install cleanly.

Why this matters

The installer does not bundle all of these utilities. It expects your system to already have them, so checking now avoids troubleshooting later.

Step 3: Download the installer safely

A sysadmin should inspect an install script before running it.

Download the script

curl -s "https://get.sdkman.io" -o sdkman-install.sh

This downloads the official installer to a local file instead of piping it straight into Bash. That gives you a chance to review it before execution.

Review the file

less sdkman-install.sh

Look for shell init changes, home directory writes, and remote download logic. You do not need to understand every line, but you should know what the script will change.

Why this matters

This step reduces risk. It follows a safer pattern than blindly piping a script into the shell, which is especially useful on production hosts or controlled workstations.

Step 4: Run the installer

Now you can install SDKMAN itself.

Start the installation

bash sdkman-install.sh

This runs the official installer in your current user context. The script typically creates a ~/.sdkman directory and adds shell initialization to your profile files.

Example expected output

Installing SDKMAN...
Checking candidates...
Setting up shell integration...

The exact text can vary, but the key point is that the installer should finish without errors and tell you to restart your shell or source the init script.

Why this matters

Running the installer as your normal user keeps the setup simple and avoids permission issues. It also matches how SDKMAN is designed to work on Linux systems.

Step 5: Load SDKMAN in your shell

After installation, you need to activate it in the current terminal session.

Source the init script

source "$HOME/.sdkman/bin/sdkman-init.sh"

This loads the sdk command into your current shell without needing to log out and back in. It also prepares the shell environment so SDKMAN can manage PATH changes properly.

Verify the version

sdk version

You should see version output similar to this:

SDKMAN!
script: 5.19.0
native: 0.5.0

The exact numbers may change over time, but the command should return a valid SDKMAN version response.

Why this matters

The install is not complete until the shell knows about SDKMAN. Sourcing the init script confirms that the setup works in the current session, not only after a future login.

Step 6: Confirm shell integration

SDKMAN usually adds a snippet to your shell profile.

Check Bash or Zsh config

grep -n "sdkman-init.sh" ~/.bashrc ~/.bash_profile ~/.profile ~/.zshrc 2>/dev/null

This finds the line that loads SDKMAN on login. It helps you confirm that the installer updated the right file for your shell.

What the snippet usually looks like

[[ -s "$HOME/.sdkman/bin/sdkman-init.sh" ]] && source "$HOME/.sdkman/bin/sdkman-init.sh"

That line makes SDKMAN available every time you open a new shell.

Why this matters

Without shell integration, sdk may work only in the current terminal. For daily use, the init line is what makes the setup persistent.

Step 7: Install a Java SDK

This is where SDKMAN becomes useful in real life.

List available Java versions

sdk list java

This shows supported Java builds from different vendors. You can pick a version based on your project needs, compatibility, or long-term support policy.

Install one version

sdk install java 17.0.12-tem

This installs a specific JDK build. A fixed version is useful when you want predictable builds and consistent behavior across dev machines.

Set a default version

sdk default java 17.0.12-tem

This makes the selected version the default for future shells. It is better than manually changing PATH because SDKMAN manages the switch for you.

Check the active Java version

java -version
which java
sdk current java

These commands confirm the runtime, binary path, and SDKMAN-managed active version. If everything is correct, you should see the SDKMAN path inside your home directory.

Why this matters

This is the main reason people use SDKMAN on Fedora 44. It removes the pain of manual installs and makes version changes fast and clean.

Step 8: Use session-only switching

Sometimes you need a temporary version change.

Switch only for the current shell

sdk use java 17.0.12-tem

This changes the active version only in the current session. When you open a new terminal, SDKMAN goes back to the default version unless you set a new default.

Why this matters

This is ideal for testing, debugging, or checking application compatibility. It lets you try a version without changing your global setup.

Step 9: Tune SDKMAN for your workflow

Fedora 44 users often want cleaner automation or quieter shell behavior.

View the config file

cat ~/.sdkman/etc/config

This file controls options like auto answer, color output, beta channel usage, and self-update behavior. You can adjust it to match workstation, CI, or server needs.

Example safer settings for automation

sdkman_auto_answer=true
sdkman_colour_enable=false
sdkman_selfupdate_feature=false

These settings reduce prompts, make logs easier to read, and avoid unexpected self updates.

Why this matters

A default desktop setup is not always ideal for a build host or managed server. Tuning the config helps keep your SDKMAN on Fedora 44 setup stable and predictable.

Troubleshooting

Here are the most common problems and how to fix them.

1. sdk: command not found

This usually means the shell init file was not loaded. Run:

source "$HOME/.sdkman/bin/sdkman-init.sh"

If that works, check your .bashrc, .bash_profile, or .zshrc for the init line.

2. Missing dependency errors

If the installer complains about curl, zip, unzip, or sed, install them again:

sudo dnf install -y curl zip unzip sed

This usually fixes the problem right away.

3. Java does not switch

If java -version still shows the old release, check your active shell and PATH:

sdk current java
echo $PATH
which java

Then re-source the init script or open a new terminal.

4. Installer fails on shell config changes

If you do not want SDKMAN to edit your shell files, reinstall with no rc update:

curl -s "https://get.sdkman.io?rcupdate=false" | bash

This is useful for CI or locked-down environments.

5. Custom install path errors

If you want a system-wide location, make sure the directory exists and you have permission:

export SDKMAN_DIR="/usr/local/sdkman"
curl -s "https://get.sdkman.io" | bash

The installer needs full write access to that path.