Skip to content
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.

Sign up for GitHub

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

Jump to bottom

jenv versions --verbose multiple java versions clarification #345

Open
riemann89 opened this issue Dec 9, 2021 · 2 comments
Open

jenv versions --verbose multiple java versions clarification #345

riemann89 opened this issue Dec 9, 2021 · 2 comments

Comments

@riemann89
Copy link

riemann89 commented Dec 9, 2021 •
edited

I installed java 1.8 by using brew, and then I added it to jenv.

jenv add /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home/bin

when I run jenv versions --verbose I got the following:

  system
         --> ${HOME}

  1.8.0.312
         ${HOME}/.jenv/versions/1.8.0.312
         --> /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home

* openjdk64-1.8.0.312 (set by ${HOME}/.jenv/version)
         ${HOME}/.jenv/versions/openjdk64-1.8.0.312
         --> /Library/Java/JavaVirtualMachines/temurin-8.jdk/Contents/Home

What is the difference btw 1.8.0.312 and openjdk64-1.8.0.312?
Sorry if it duplicates another question but I couldn't find anywhere.
@riemann89 riemann89 changed the title jenv versions --verbose jenv versions --verbose multiple java versions clarification Dec 9, 2021
@marquiswang
Copy link
Contributor

There is no difference. When you added that JDK, it detected the version as openjdk64-1.8.0.312. To help minimize typing when switching versions, it adds multiple aliases for those.

For example, when I added a Zulu 17.0.2 JDK, Jenv created the following aliases:

17
17.0
17.0.2
zulu64-17.0.2

All four of these links point to the same JDK. I can run jenv local 17 or jenv local zulu64-17.0.2, and I will get exactly the same result.

If you install a second JDK that would create an alias that already exists, then it will not recreate the alias. For example, if I now add a Zulu 17.0.1 JDK, it will add zulu64-17.0.1 and 17.0.1, but 17.0 and 17 will still point to zulu64-17.0.2, because it was aliased first.

@erikhuizinga
Copy link

The last comment makes me wonder what happens when a newer version of e.g. 17.x is installed.

E.g. you first install zulu64-17.0.0. This adds the 17 alias. Then you install zulu64-17.0.1. To what JDK does 17 point? As a user I'd expect it to point to the highest possible version match, i.e. zulu64-17.0.1 and not zulu64-17.0.0 simply because it was first.

Also, when installing through brew, e.g. brew install temurin, it currently installs version 18,36. When later a newer version becomes available through brew, an upgrade will replace the installed SDK. To what will Jenv's aliases point after such an update? Will it automatically point to the new version, because the location points to the new JDK? Or does Jenv do nothing automatically?

Stuff like this could be added to the root readme, to clarify the default behaviour.

marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
df3add8 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
c6acd40 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
f794a2d 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
06eb1a3 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
b2ade97 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 9, 2022
Add smart version detection
0f3ed90 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.

The old aliases still work, but users may want to remove those aliases
if they are no longer useful. The aliases take priority over the smart
behavior.
@marquiswang marquiswang mentioned this issue May 9, 2022
Open
marquiswang pushed a commit to marquiswang/jenv that referenced this issue May 26, 2022
Add smart version detection
399b5af 
This commit changes the behavior of `jenv add` and `jenv
global|local|shell [version]`

Previously, jenv add would add "short" aliases of the version. For
example, adding Zulu JDK 11.0.3 would add the following aliases:
* 11
* 11.0
* 11.0.3
* zulu64-11.0.3

This was very convenient in that it prevented you from needing to type
`jenv version zulu64-11.0.3` to change versions, but led to some
confusion among users. See issues jenv#345, jenv#326, jenv#300, jenv#268, etc.

It also made `jenv versions` very verbose if you had a lot of versions.

This commit addresses this by adding "smart" version detection when
running `jenv global|local|shell [version]`, allowing you to run:

$ jenv global 11      # Change to JDK 11
$ jenv global 11.0.2  # Change to JDK 11.0.2
$ jenv local zulu     # Change to Zulu JDK
$ jenv shell x86_64   # Change to x86_64 architecture

With all of these commands, `jenv` will attempt to avoid changing the
other properties. So if the current global version is a Temurin JDK 11,
and you run `jenv global 18`, it will change to a Temurin JDK 18
(assuming you have one installed). If instead you run `jenv global zulu`
it will change to a Zulu JDK 11.

With this change, `jenv add` no longer adds the short version aliases.

The old aliases still work, but users may want to remove those aliases
if they are no longer useful. The aliases take priority over the smart
behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@marquiswang @riemann89 @erikhuizinga