jenv: Jenv not setting JAVA_HOME

Did I miss something; i’m trying to reset my JAVA_HOME with jenv and have tried all the command and it seems it is updating the values but not the JAVA_HOME?

Any reason this should be happening?

Thanks,

Ian.

Ians-MacBook-Pro:~ ian$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
Ians-MacBook-Pro:~ ian$ jenv local oracle64-1.7.0.45
Ians-MacBook-Pro:~ ian$ jenv global oracle64-1.7.0.45 
Ians-MacBook-Pro:~ ian$ jenv shell
shell          shell-options  
Ians-MacBook-Pro:~ ian$ jenv shell oracle64-1.7.0.45 
Ians-MacBook-Pro:~ ian$ jenv version
oracle64-1.7.0.45 (set by JENV_VERSION environment variable)
Ians-MacBook-Pro:~ ian$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
Ians-MacBook-Pro:~ ian$ jenv versions
  system
  oracle64-1.6.0.65
* oracle64-1.7.0.45 (set by JENV_VERSION environment variable)
  oracle64-1.8.0-ea
Ians-MacBook-Pro:~ ian$ echo $JENV_VERSION
oracle64-1.7.0.45
Ians-MacBook-Pro:~ ian$ cat .java-version
oracle64-1.7.0.45
Ians-MacBook-Pro:~ ian$ ```

About this issue

  • Original URL
  • State: closed
  • Created 10 years ago
  • Comments: 89

Commits related to this issue

Most upvoted comments

I solved setting JAVA_HOME by adding these lines to .zshrc after eval “$(jenv init -)”

export JAVA_HOME="$HOME/.jenv/versions/`jenv version-name`"
alias jenv_set_java_home='export JAVA_HOME="$HOME/.jenv/versions/`jenv version-name`"'

I can use jenv_set_java_home alias to set JAVA_HOME after changing it with jenv .

You can set JAVA_HOME (and JDK_HOME) by enabling the export plugin

jenv enable-plugin export

Hello,

The JAVA_HOME is setup for command managed by jenv ( java, javac, … and if plugin activated for mvn, gradle, … ).

If you need external command to be aware of jenv’s java-version, you can try 👍

jenv exec /your/command/here

Sample :

hikage at iKage in ~
$ echo $JAVA_HOME


hikage at iKage in ~
$ jenv exec bash
bash-3.2$ echo $JAVA_HOME
/Users/hikage/.jenv/versions/oracle64-1.8.0-ea
bash-3.2$ exit
exit

hikage at iKage in ~
$ 

I had same issue with maven and JAVA_HOME after upgrading my jenv using homebrew and finally found the solution for me. It seems like plugins need to be disabled and enabled to fix the issue.

jenv disable-plugin maven
jenv disable-plugin export
jenv enable-plugin maven
jenv enable-plugin export

I actually, opened up new terminal after disabling plugins and continued there. Hopefully, it helps someone else having same issue with me.

Can you try the new “export” plugin ?

jenv enable-plugin export

add the following line in .zsh or .bashrc export JAVA_HOME="$(jenv prefix) after if which jenv > /dev/null; then eval "$(jenv init -)"; fi

I’m still confused… Why shouldn’t jenv set the JAVA_HOME globally when requested? there are 1000s of custom programs that rely on this parameter and it would be cool if you can change it with a single command line. FYI, I moved from jenv to simple bash script titled “java7” & “java8” that does just that, i.e. sets the JAVA_HOME & system path to the applicable JDK

On 2 April 2014 21:27, Lari Hotari notifications@github.com wrote:

Thanks for the Spring Boot support.

btw. It looks like gvm is setting my JAVA_HOME now. https://github.com/gvmtool/gvm/blob/master/src/main/bash/gvm-init.sh#L128

(I’d like to see gvm rely on jenv instead. btw. It would be cool if jenv could be installed/updated with gvm.)

Reply to this email directly or view it on GitHubhttps://github.com/gcuisinier/jenv/issues/44#issuecomment-39379160 .

It makes no sense to not set JAVA_HOME.

jenv is supposed to “Manage your Java environment” yet it does not set what’s arguably the most critical java environment variable.

The idea that one must wrap their commands with jenv exec or use a plugin is invasive and impractical. Existing programs, scripts, cronjobs, service monitors, workflows that depend on JAVA_HOME should not have to be tracked down and modified. Why write 10s of plugins in lieu of setting one variable?

A great example: JRuby uses JAVA_HOME to find the underlying JVM. One should not have to type jenv exec ruby a_program.rb.

jenv should be transparent.

Any reason the export plugin isn’t enabled by default? When would you potentially want your $JAVA_HOME not to reflect the virtual environment you just setup and it this more common than wanting all your java settings to be on the same page when you do a jenv global x.y.z?

Intellij IDEA needs this too. It should be a given that you set JAVA_HOME.

Do you try this :

jenv enable-plugin grails jenv enable-plugin groovy

Spring Boot is not yet supported, indeed.

When i do jenv enable-plugin export I get

jenv: no such command `enable-plugin’

Gonna go delete jenv from my machine…

Nearly nothing suggested here for fish worked for me, nor in the readme, or in the scripts output. I added this to my .config/fish/config.fish set -x JAVA_HOME (jenv prefix)

When running jenv global x.y.z (local, neither) it doesn’t seem to automatically update JAVA_HOME in the current shell.

Since no one mentioned it, and it was blocking me, per https://github.com/jenv/jenv/issues/78#issuecomment-94264183, if you have ~/.mavenrc present and pointing to a JDK, it will ignore what you do with jenv, even if you have everything else set up properly. Nothing from this thread was working for me, and then I commented out the line in that file setting JAVA_HOME and now everything is working great 👍

@HaoH you forgot to put " at the end of the line

export JAVA_HOME="$(jenv prefix)"

Thanks, it worked

What I did is a little bit of a hack, but I think that it would remove the need for all of the plugins.

Inside of the .jenv directory, I created a fake-java-home/bin with a symlink to the shims directory. Then in my bash, I pointed JAVA_HOME to the .jenv/fake-java-home directory. This means that any program trying to use java, will be redirected to the shim automatically.

bakerj1-mbpdu:.jenv bakerj$ ls -al
total 32
drwxr-xr-x  21 bakerj  OCLC\Domain Users   714 Apr 13 14:12 .
drwxr-xr-x+ 56 bakerj  OCLC\Domain Users  1904 Apr 13 14:44 ..
drwxr-xr-x  13 bakerj  OCLC\Domain Users   442 Apr  9 16:15 .git
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 1.7.0.45.time
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 1.7.time
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 1.8.0.05.time
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 1.8.time
-rw-r--r--   1 bakerj  OCLC\Domain Users  1060 Apr  9 16:15 LICENSE
-rw-r--r--   1 bakerj  OCLC\Domain Users  6385 Apr  9 16:15 README.md
drwxr-xr-x  13 bakerj  OCLC\Domain Users   442 Apr  9 16:15 available-plugins
drwxr-xr-x   3 bakerj  OCLC\Domain Users   102 Apr  9 16:15 bin
drwxr-xr-x   4 bakerj  OCLC\Domain Users   136 Apr  9 16:15 completions
drwxr-xr-x   3 bakerj  OCLC\Domain Users   102 Apr 13 14:13 fake-java-home
drwxr-xr-x   4 bakerj  OCLC\Domain Users   136 Apr  9 16:15 fish
drwxr-xr-x  44 bakerj  OCLC\Domain Users  1496 Apr  9 16:15 libexec
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 oracle64-1.7.0.45.time
-rw-r--r--   1 bakerj  OCLC\Domain Users     0 Apr  9 16:20 oracle64-1.8.0.05.time
drwxr-xr-x   4 bakerj  OCLC\Domain Users   136 Apr 13 14:42 plugins
drwxr-xr-x  51 bakerj  OCLC\Domain Users  1734 Apr 13 14:44 shims
-rw-r--r--   1 bakerj  OCLC\Domain Users    18 Apr  9 16:20 version
drwxr-xr-x   8 bakerj  OCLC\Domain Users   272 Apr  9 16:20 versions
bakerj1-mbpdu:.jenv bakerj$ pwd
/Users/bakerj/.jenv
bakerj1-mbpdu:.jenv bakerj$ echo $JAVA_HOME
/Users/bakerj/.jenv/fake-java-home
bakerj1-mbpdu:.jenv bakerj$ 
bakerj1-mbpdu:.jenv bakerj$ ls  $JAVA_HOME/bin
appletviewer    jar     javadoc     jcmd        jhat        jmc     jstack      keytool     policytool  schemagen   unpack200
apt     jarsigner   javafxpackager  jconsole    jinfo       jps     jstat       native2ascii    rmic        serialver   wsgen
extcheck    java        javah       jdb     jjs     jrunscript  jstatd      orbd        rmid        servertool  wsimport
idlj        javac       javap       jdeps       jmap        jsadebugd   jvisualvm   pack200     rmiregistry tnameserv   xjc
bakerj1-mbpdu:.jenv bakerj$ 

Groovy and Maven and Gradle all react as expected (meaning they react to any local .java-version files)

You can try :

jenv enable-plugin export

ok, I found the bug. I expect the shell to be “bash”, “zsh” or "fish …

Here it’s “/usr/lcal/bin/shell” … and so that’s don’t work correctly.

To fix, modify you .bash_profiles from :

eval "$(jenv init -)

to

eval "$(jenv init - bash)

Any reason the export plugin isn’t enabled by default?

This would be much better. Especially since it seems quite tricky/error-prone to even get the plugin enabled, particularly in a scripted/unattended fashion that doesn’t rely on “restart your terminal to fix” (see https://github.com/jenv/jenv/issues/64).

To get maven to us the java version from jenv (maven uses JAVA_HOME):

echo 'JAVA_HOME=$(/usr/libexec/java_home -v $(jenv version-name))' >> ~/.mavenrc source ~/.mavenrc

https://medium.com/@danielnenkov/multiple-jdk-versions-on-mac-os-x-with-jenv-5ea5522ddc9b

Ok… It seems that the maven plugin is not correctly loaded. Could you try again :

jenv enable-plugin maven

command -v mvn

I’ve published a new version of jenv in homebrew. Could you upgrade and run 👍

jenv doctor

Thanks

Hmm ok it seems that it has nothing to do with the maven enforcer plugin jenv does not set the java version properly for maven. If I run maven with the -X it shows up that maven still runs with the system java environment:

Apache Maven 3.2.1 (ea8b2b07643dbb1b84b6d16e1f08391b666bc1e9; 2014-02-14T18:37:52+01:00)
Maven home: /usr/local/Cellar/maven/3.2.1/libexec
Java version: 1.6.0_65, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.9.2", arch: "x86_64", family: "mac"

despite I enabled the maven plugin for jenv.

@gcuisinier No specific tool in mind- i’m more relating this to every day development - i may need to compile/execute 1 sourceset in JDK7 and another in JDK8 meaning that I need to change the JDK version frequently

On 3 April 2014 10:41, Gildas Cuisinier notifications@github.com wrote:

@lhotari https://github.com/lhotari I agree, shell function could be a solution to update JAVA_HOME on directory change.

@kellizer https://github.com/kellizer Which tools do you have in mind? At this time, specifics tools that need JAVA_HOME are supported with plugins ( jenv enable-plugins ).

Reply to this email directly or view it on GitHubhttps://github.com/gcuisinier/jenv/issues/44#issuecomment-39432365 .

It’s not mandatory to user “jenv exec” to get the good version of Java. Jenv modify the path to use the good one (base one global, local or shell).

But in Java, some tools need to know where is the JDK. And the JAVA_HOME env variable is used for this. JAVA_HOME must point to the selected Java, not the global one. At this time, I export the JAVA_HOME in the jenv exec ( which is called by the java “wrapper” ).

So, if your command is a script that need to know where is the JAVA_HOME before calling java, you should call jenv exec yourScript

If your command used the “java” in the path, it’s not mandatory.