Maven
  1. Maven
  2. MNG-4226

Better detection of JAVA_HOME on Apple Mac OS X

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2.2
    • Component/s: Command Line
    • Labels:
      None

      Description

      On mac JAVA_HOME is detected by using the following code:

                 if [ -z "$JAVA_VERSION" ] ; then
                   JAVA_VERSION="CurrentJDK"
                 else
                   echo "Using Java version: $JAVA_VERSION"
                 fi
                 if [ -z "$JAVA_HOME" ] ; then
                   JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/${JAVA_VERSION}/Home
                 fi
      

      But this does not work in collaboration with Using "Java preferences" to change the actual java version to use as "CurrentJDK" does not change once you update the "java applications" order.

      There is an alternative (at least on Leopard) for determining current java home that is based on Java Preferences by using an apple provided script. So, as a replacement fo rthe code above the following could be used.

                 if [ -z "$JAVA_HOME" ] ; then
                   JAVA_HOME=`/usr/libexec/java_home | tail -1`
                 fi
      

      Could also be taht this is teh first attempt and if fails use the current way of determining home.

        Issue Links

          Activity

          Hide
          Daniel Serodio added a comment -

          Yes, please apply this fix.
          JAVA_HOME=`/usr/libexec/java_home` is the proper way to set JAVA_HOME on OS X. From man java_home, I don't think the | tail -1 is needed.

          Show
          Daniel Serodio added a comment - Yes, please apply this fix. JAVA_HOME=`/usr/libexec/java_home` is the proper way to set JAVA_HOME on OS X. From man java_home , I don't think the | tail -1 is needed.
          Hide
          Robert Elliot added a comment -

          Patch to fix java version detection on OS/X so that it uses the standard Java Preferences mechanism rather than always using Java 6.

          Show
          Robert Elliot added a comment - Patch to fix java version detection on OS/X so that it uses the standard Java Preferences mechanism rather than always using Java 6.
          Hide
          Robert Elliot added a comment -

          I just wasted an evening trying to establish why setting the preferred Java version to Java 7 in Mac's Java Preferences still left Maven using Java 6, due to this issue. Ant does it the right way, via /usr/libexec/java_home. Attached is a patch.

          Show
          Robert Elliot added a comment - I just wasted an evening trying to establish why setting the preferred Java version to Java 7 in Mac's Java Preferences still left Maven using Java 6, due to this issue. Ant does it the right way, via /usr/libexec/java_home. Attached is a patch.
          Hide
          Cservenak, Tamas added a comment - - edited

          You can circumvent current maven deployments (3.0.4 inclusive) without modifying them, by adding following file in /etc/mavenrc:

          JAVA_HOME=`/usr/libexec/java_home -v 1.7`
          

          Note: this will make Maven use same Java system wide!

          Show
          Cservenak, Tamas added a comment - - edited You can circumvent current maven deployments (3.0.4 inclusive) without modifying them, by adding following file in /etc/mavenrc : JAVA_HOME=`/usr/libexec/java_home -v 1.7` Note: this will make Maven use same Java system wide!
          Hide
          Nikolaj Schumacher added a comment -

          This should probably be revisited soon. Apple recently removed the "Java Preferences" and has everything in the system default to Java 7, if that is installed. The pre-installed version of mvn 3.0.3 also uses Java 7, but any upgrade to 3.0.4 will revert back to Java 6 due to this issue.

          I assume this will surprise quite a few people and cost them time tracking it down. And the current hard-coded /System/Library path will probably break as soon as Apple drops their own JRE (which they deprecated in 2010.)

          Show
          Nikolaj Schumacher added a comment - This should probably be revisited soon. Apple recently removed the "Java Preferences" and has everything in the system default to Java 7, if that is installed. The pre-installed version of mvn 3.0.3 also uses Java 7, but any upgrade to 3.0.4 will revert back to Java 6 due to this issue. I assume this will surprise quite a few people and cost them time tracking it down. And the current hard-coded /System/Library path will probably break as soon as Apple drops their own JRE (which they deprecated in 2010.)
          Hide
          Christopher Tubbs added a comment -

          Uploaded new patch that preserves existing behaviour, but makes Maven work out of the box on newer OS X machines.

          See attached git formatted patch 0001-MNG-4226-Detect-JAVA_HOME-on-newer-Mac-OS-X.patch or pull request.

          Show
          Christopher Tubbs added a comment - Uploaded new patch that preserves existing behaviour, but makes Maven work out of the box on newer OS X machines. See attached git formatted patch 0001-MNG-4226-Detect-JAVA_HOME-on-newer-Mac-OS-X.patch or pull request .
          Hide
          Jason van Zyl added a comment -

          Committed on 65863e0a28298b6d95bfbbf7cc28953f6ba91f93
          Submitted by: Christopher Tubbs <ctubbsii@apache.org>
          https://github.com/apache/maven/pull/11

          Show
          Jason van Zyl added a comment - Committed on 65863e0a28298b6d95bfbbf7cc28953f6ba91f93 Submitted by: Christopher Tubbs <ctubbsii@apache.org> https://github.com/apache/maven/pull/11
          Hide
          Hans Aikema added a comment -

          This is not fixed, or broken again. On my MacPro running Mavericks:

          abu:bin aikebah$ java -version
          java version "1.8.0"
          Java(TM) SE Runtime Environment (build 1.8.0-b132)
          Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)
          abu:bin aikebah$ ./mvn -version
          Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T15:51:42+02:00)
          Maven home: /Users/aikebah/Documents/Apps/apache-maven-3.2.2
          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.4", arch: "x86_64", family: "mac"
          abu:bin aikebah$

          Show
          Hans Aikema added a comment - This is not fixed, or broken again. On my MacPro running Mavericks: abu:bin aikebah$ java -version java version "1.8.0" Java(TM) SE Runtime Environment (build 1.8.0-b132) Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode) abu:bin aikebah$ ./mvn -version Apache Maven 3.2.2 (45f7c06d68e745d05611f7fd14efb6594181933e; 2014-06-17T15:51:42+02:00) Maven home: /Users/aikebah/Documents/Apps/apache-maven-3.2.2 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.4", arch: "x86_64", family: "mac" abu:bin aikebah$
          Hide
          Hans Aikema added a comment -

          Forgot to include the results of java_home:

          abu:bin aikebah$ /usr/libexec/java_home
          /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home

          Show
          Hans Aikema added a comment - Forgot to include the results of java_home: abu:bin aikebah$ /usr/libexec/java_home /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home
          Hide
          Ian P. Springer added a comment -

          When you run "java -version", the shell is going to run the first java executable it finds in your PATH, which may not be the same as the java the mvn shell script uses, which is:

          1) if JAVA_HOME defined: $JAVA_HOME/bin/java
          2) else if /System/Library/Java/JavaVirtualMachines/CurrentJDK exists: /System/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home/bin/java

          What is your PATH set to? You can also try running "whereis java".

          Show
          Ian P. Springer added a comment - When you run "java -version", the shell is going to run the first java executable it finds in your PATH, which may not be the same as the java the mvn shell script uses, which is: 1) if JAVA_HOME defined: $JAVA_HOME/bin/java 2) else if /System/Library/Java/JavaVirtualMachines/CurrentJDK exists: /System/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home/bin/java What is your PATH set to? You can also try running "whereis java".
          Hide
          Hans Aikema added a comment -

          abu:classes aikebah$ whereis java
          /usr/bin/java

          And as mentioned earlier in this issue: on modern Mac OS the location of java should be examined using
          1) if JAVA_HOME defined: $JAVA_HOME/bin/java
          2) else if /usr/libexec/java_home is present at the location that /usr/libexec/java_home returns
          3) else if /System/Library/Java/JavaVirtualMachines/CurrentJDK exists: /System/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home/bin/java

          The Oracle Java JDK's do not install to /System/Library/Java/JavaVirtualMachines/CurrentJDK

          The patch that has been applied seems to attempt this, but in the wrong order (i.e. first do 3) and only when it fails to resolve a Java do 2))

          Show
          Hans Aikema added a comment - abu:classes aikebah$ whereis java /usr/bin/java And as mentioned earlier in this issue: on modern Mac OS the location of java should be examined using 1) if JAVA_HOME defined: $JAVA_HOME/bin/java 2) else if /usr/libexec/java_home is present at the location that /usr/libexec/java_home returns 3) else if /System/Library/Java/JavaVirtualMachines/CurrentJDK exists: /System/Library/Java/JavaVirtualMachines/CurrentJDK/Contents/Home/bin/java The Oracle Java JDK's do not install to /System/Library/Java/JavaVirtualMachines/CurrentJDK The patch that has been applied seems to attempt this, but in the wrong order (i.e. first do 3) and only when it fails to resolve a Java do 2))
          Hide
          Christopher Tubbs added a comment -

          The patch that has been applied does it in that order because that was the way to preserve the previous (almost certainly incorrect) behavior of looking at CurrentJDK first. I agree the ordering Hans Aikema lists makes the most sense, but I think it's a question of whether or not to preserve the previous behavior or respect /usr/libexec/java_home first.

          Show
          Christopher Tubbs added a comment - The patch that has been applied does it in that order because that was the way to preserve the previous (almost certainly incorrect) behavior of looking at CurrentJDK first. I agree the ordering Hans Aikema lists makes the most sense, but I think it's a question of whether or not to preserve the previous behavior or respect /usr/libexec/java_home first.

            People

            • Assignee:
              Jason van Zyl
              Reporter:
              Alin Dreghiciu
            • Votes:
              12 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development