Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-755

Default JDK meaning in project options is confusing.

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • maven-plugin
    • None
    • Platform: HP, OS: Windows XP

      When the option for which JDK to use for native m2 builds is set to "default"
      and there is only one jdk configured in hudson the builds should use that jdk
      not the jdk/jre of the container.

      if there are more jdks' configured hudson should use the first one configured
      at the system level for default.

          [JENKINS-755] Default JDK meaning in project options is confusing.

          Maybe it's better off if we just get rid of this "default" thing altogether.
          Does it really buy us anything?

          If there's only one JDK configured in Hudson, I suppose we shouldn't even
          display the JDK selection drop-down and just stick to that JDK.

          Kohsuke Kawaguchi added a comment - Maybe it's better off if we just get rid of this "default" thing altogether. Does it really buy us anything? If there's only one JDK configured in Hudson, I suppose we shouldn't even display the JDK selection drop-down and just stick to that JDK.

          James Nord added a comment -

          Alternativly if you only have one that is the default, but if you have multiple
          then you can select which is the default.

          Then if you wish to upgrade and most of your jobs are using the default you can
          do it in just one place. (and let the projects that need a different jdk use it.)

          ALthough I guess you could do this already by calling a jdk install "latest" and
          just change the path to which jdk it uses...

          James Nord added a comment - Alternativly if you only have one that is the default, but if you have multiple then you can select which is the default. Then if you wish to upgrade and most of your jobs are using the default you can do it in just one place. (and let the projects that need a different jdk use it.) ALthough I guess you could do this already by calling a jdk install "latest" and just change the path to which jdk it uses...

          bimargulies added a comment -

          This problem seems more severe to me.

          I added a second JDK, and selected one of them for my project, and the project
          is still running with the JRE as JAVA_HOME instead of the JDK. I need the JDK.

          Either that or the maven-antrun-plugin is playing a nasty prank on me.

          bimargulies added a comment - This problem seems more severe to me. I added a second JDK, and selected one of them for my project, and the project is still running with the JRE as JAVA_HOME instead of the JDK. I need the JDK. Either that or the maven-antrun-plugin is playing a nasty prank on me.

          Ulli Hafner added a comment -

          The same should be done for the default maven version.

          I would expect that you can configure a list of tools in Hudson. For each tool, you have a default version (in the system configuration) that will be used if a job does not select a version in the job configuration. If it is easier to implement we can use the version at the top of the list (even though this is not so clear to the user). Another idea would be to have a 'Latest' list box entry, that would automatically use the latest available.

          Ulli Hafner added a comment - The same should be done for the default maven version. I would expect that you can configure a list of tools in Hudson. For each tool, you have a default version (in the system configuration) that will be used if a job does not select a version in the job configuration. If it is easier to implement we can use the version at the top of the list (even though this is not so clear to the user). Another idea would be to have a 'Latest' list box entry, that would automatically use the latest available.

          James Nord added a comment -

          WIth 1.389 I no longer see the ability to choose the JDK / Maven version if only one is installed - so as originally reported this is probably fixed (or my test setup is lacking something?).

          However Drulli's comment is valid that you may want a default and have jobs be able to choose that whatever it maps to.

          James Nord added a comment - WIth 1.389 I no longer see the ability to choose the JDK / Maven version if only one is installed - so as originally reported this is probably fixed (or my test setup is lacking something?). However Drulli's comment is valid that you may want a default and have jobs be able to choose that whatever it maps to.

          Ulli Hafner added a comment -

          That is interesting. I still have the default option, but only for freestyle projects and not m2 projects.

          Ulli Hafner added a comment - That is interesting. I still have the default option, but only for freestyle projects and not m2 projects.

          It would be nice to break this into two options: Default and System.
          Default would the the highest one on the list.
          System would use the system jdk.

          Why anyone would use System when Jenkins can manage the JDKs for you, I have no clue.

          Christian Höltje added a comment - It would be nice to break this into two options: Default and System. Default would the the highest one on the list. System would use the system jdk. Why anyone would use System when Jenkins can manage the JDKs for you, I have no clue.

          It'd be worth it to get rid of the "Default" altogether to prevent any confusion as to what the current default is. I believe having new jobs select a specific JDK by default is a completely different issue. I just migrated an old Hudson server and "Default" kind of bit me because it was not what I expected.

          Just my 2 cents

          James Randolph added a comment - It'd be worth it to get rid of the "Default" altogether to prevent any confusion as to what the current default is. I believe having new jobs select a specific JDK by default is a completely different issue. I just migrated an old Hudson server and "Default" kind of bit me because it was not what I expected. Just my 2 cents

          Croesus Kall added a comment -

          Also ran into this: Added a second JDK, and all of a sudden all of the jobs switched to the default "system" jdk, causing a whole bunch of builds to fail.

          This also seems like the behavior for maven, i.e. if more than one maven installation is set up, "default" points to the maven version on the system path?

          Croesus Kall added a comment - Also ran into this: Added a second JDK, and all of a sudden all of the jobs switched to the default "system" jdk, causing a whole bunch of builds to fail. This also seems like the behavior for maven, i.e. if more than one maven installation is set up, "default" points to the maven version on the system path?

          S Stack added a comment -
          • JDK mismatch just caused an important deploy here to fail. Worse, some jobs don't even show the JDK drop-down in their configuration screen. This means we have to modify the job config.xml directly.
          • Completely agree "default" is misleading. Is "default" the 2nd JDK defined?
          • Please consider removing this ambiguity which can cause incidents at the worst possible moment. Thanks.

          S Stack added a comment - JDK mismatch just caused an important deploy here to fail. Worse, some jobs don't even show the JDK drop-down in their configuration screen. This means we have to modify the job config.xml directly. Completely agree "default" is misleading. Is "default" the 2nd JDK defined? Please consider removing this ambiguity which can cause incidents at the worst possible moment. Thanks.

          We REALLY need some way to select what we feel is the global default. Even if the default is just the top-most defined JDK in "Configure System". And all it takes is renaming the option within the job to make it less ambiguous.

          The other problem with this is that when using "Default" it doesn't set JAVA_HOME for any jobs which use it.

          James Hardwick added a comment - We REALLY need some way to select what we feel is the global default. Even if the default is just the top-most defined JDK in "Configure System". And all it takes is renaming the option within the job to make it less ambiguous. The other problem with this is that when using "Default" it doesn't set JAVA_HOME for any jobs which use it.

          Go Tanaka added a comment -

          I met the same issue when added a second JDK on Windows Server.

          In my case, I renamed the files, java.exe, javaw.exe, javaws.exe in Windows\System32, into java_.exe, javaw_.exe, javaws_.exe and finally Jenkins runs using JAVA_HOME's java with "Default".

          I guess installing a second JDK will update java.exe in Windows\System32 and "Default" setting won't use JAVA_HOME.

          Go Tanaka added a comment - I met the same issue when added a second JDK on Windows Server. In my case, I renamed the files, java.exe, javaw.exe, javaws.exe in Windows\System32, into java_.exe, javaw_.exe, javaws_.exe and finally Jenkins runs using JAVA_HOME's java with "Default". I guess installing a second JDK will update java.exe in Windows\System32 and "Default" setting won't use JAVA_HOME.

          Dave Vree added a comment - - edited

          To make matters worse, if you have configured just one JDK, you don't get the choice to select between "default" and that JDK. I think that "default" should be removed from the selections altogether. To make it clear, I think the JDK selection should always be present and it should always have a choice called "Host JDK" (or maybe "Host System JDK"). I would finally add that selecting the "Host System JDK" should come with a warning that upgrading the host will affect all the jobs.

          Dave Vree added a comment - - edited To make matters worse, if you have configured just one JDK, you don't get the choice to select between "default" and that JDK. I think that "default" should be removed from the selections altogether. To make it clear, I think the JDK selection should always be present and it should always have a choice called "Host JDK" (or maybe "Host System JDK"). I would finally add that selecting the "Host System JDK" should come with a warning that upgrading the host will affect all the jobs.

          Farrukh Najmi added a comment -

          Farrukh Najmi added a comment - Following thread relates to this issue: https://groups.google.com/forum/#!topic/jenkinsci-users/p7mUidJfNYQ

          Idan Bidani added a comment -

          Do you think this bug can be more generic and relate to all Jenkins tools: JDK, ant, Maven, Grails etc.
          The "(Default)" option functionality is not clear enough.
          My suggested solutions are:
          1. Renaming it to something like "Find in PATH" or point out it's function in the help of the tools can help a lot.
          2. Remove it completely
          3. Allow the user to choose what is the default action does: "Find tool in PATH", "Use the first entry", "Use <tool_name>"

          Idan Bidani added a comment - Do you think this bug can be more generic and relate to all Jenkins tools: JDK, ant, Maven, Grails etc. The "(Default)" option functionality is not clear enough. My suggested solutions are: 1. Renaming it to something like "Find in PATH" or point out it's function in the help of the tools can help a lot. 2. Remove it completely 3. Allow the user to choose what is the default action does: "Find tool in PATH", "Use the first entry", "Use <tool_name>"

          I think, that the "Default" is good option, because I have a lot of projects with standard configuration and only several project with different JDK requirement.
          Depending on JDK installed on system is not a good idea, because on different systems ( slaves ) could be different JDK installed, so I could get different results.

          There should be "rule" which says : "The first one JDK in configuration is default."
          And would be nice to have possibility change order via drag-n-drop.

          Vladimir Kralik added a comment - I think, that the "Default" is good option, because I have a lot of projects with standard configuration and only several project with different JDK requirement. Depending on JDK installed on system is not a good idea, because on different systems ( slaves ) could be different JDK installed, so I could get different results. There should be "rule" which says : "The first one JDK in configuration is default." And would be nice to have possibility change order via drag-n-drop.

          Greg horvath added a comment -

          This all seems very silly to me. This ticket has been open for 6.5 years, and all about just providing a way to choose a default option? Come now. If I have multiple things installed, I don't want to have to explicitly specify which one I want for every job. Just give a way to select a default, or decide on a way to select a default via heuristic (i.e. first in the list, alphabetical, numerology, whatever) and tell us what it is. But just fix this, please, because it's unnecessarily confusing. And the ticket is 6.5 years old.

          Greg horvath added a comment - This all seems very silly to me. This ticket has been open for 6.5 years, and all about just providing a way to choose a default option? Come now. If I have multiple things installed, I don't want to have to explicitly specify which one I want for every job. Just give a way to select a default, or decide on a way to select a default via heuristic (i.e. first in the list, alphabetical, numerology, whatever) and tell us what it is. But just fix this, please, because it's unnecessarily confusing. And the ticket is 6.5 years old.

          Andreas Horst added a comment -

          I highly vote for fixing this one way or another since - as everybody in here already stated - the ambiguity can cause quite some trouble (see my comment on #10191.

          Andreas Horst added a comment - I highly vote for fixing this one way or another since - as everybody in here already stated - the ambiguity can cause quite some trouble (see my comment on #10191 .

          Daniel Beck added a comment -

          "(System)" or "(System Default)" seem to be appropriate alternative names for the '(Default)' JDK. While not resolving related issues, at least that would be less ambiguous.

          Daniel Beck added a comment - "(System)" or "(System Default)" seem to be appropriate alternative names for the '(Default)' JDK. While not resolving related issues, at least that would be less ambiguous.

          Jesse Glick added a comment -

          See also JENKINS-17373. I think it would be better for tool selectors generally to always show all available options, even when there is only one choice.

          The default JDK is a little tricky because this exists only when Jenkins master (or the relevant slave) is actually running on a JDK, not just a JRE.

          Jesse Glick added a comment - See also JENKINS-17373 . I think it would be better for tool selectors generally to always show all available options, even when there is only one choice. The default JDK is a little tricky because this exists only when Jenkins master (or the relevant slave) is actually running on a JDK, not just a JRE.

          Daniel Beck added a comment -

          It's no different that the 'default' of all the other tools, is it? (Except that generally JDK has a higher chance of actually being available on the PATH.)

          Agreed that tool installations should always be visible. Hiding is just confusing, as is the different job behavior between 0 (don't allow configuring, use System Default), 1 (don't allow configuring, use configured JDK), and 2 (allow configuring, default to system default) configured installations. This behavior breaks jobs just by adding a second JDK to the global config.

          Daniel Beck added a comment - It's no different that the 'default' of all the other tools, is it? (Except that generally JDK has a higher chance of actually being available on the PATH.) Agreed that tool installations should always be visible. Hiding is just confusing, as is the different job behavior between 0 (don't allow configuring, use System Default), 1 (don't allow configuring, use configured JDK), and 2 (allow configuring, default to system default) configured installations. This behavior breaks jobs just by adding a second JDK to the global config.

          Jesse Glick added a comment -

          The default JDK is not determined by $PATH, but by the running JRE. (AFAIK)

          Jesse Glick added a comment - The default JDK is not determined by $PATH , but by the running JRE. (AFAIK)

          Daniel Beck added a comment - - edited

          jglick: Doesn't look like it: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/JDK.java#L148

          And AbstractProject calls Jenkins.getInstance().getJDK(String) from getEnvironment(...) and if none is found by that name (e.g. "(Default)" or the various obsolete localized variants), null is returned and no JAVA_HOME set for the build, hoping for one defined by default.

          Daniel Beck added a comment - - edited jglick : Doesn't look like it: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/JDK.java#L148 And AbstractProject calls Jenkins.getInstance().getJDK(String) from getEnvironment(...) and if none is found by that name (e.g. " (Default) " or the various obsolete localized variants), null is returned and no JAVA_HOME set for the build, hoping for one defined by default.

          Al Murphy added a comment -

          This inordinately long-standing issue is deeply insidious. We're currently in the process of mopping up the carnage caused by having merely added Java 7 to a Jenkins instance which previously only knew of Java 6 – an action that should be additive, and benign.

          If this isn't going to be fixed any time soon, I would strongly recommend at least placing a giant disclaimer on the Jenkins Configuration page, detailing the peril of adding a second JDK. That would at least address the insidiousness, if not the bizarreness of the behaviour.

          Al Murphy added a comment - This inordinately long-standing issue is deeply insidious. We're currently in the process of mopping up the carnage caused by having merely added Java 7 to a Jenkins instance which previously only knew of Java 6 – an action that should be additive, and benign. If this isn't going to be fixed any time soon, I would strongly recommend at least placing a giant disclaimer on the Jenkins Configuration page, detailing the peril of adding a second JDK. That would at least address the insidiousness, if not the bizarreness of the behaviour.

          Not sure, in which direction the issue resolving is going to, but ...
          Imagine the scenario when you have environment with hundreds of already setup build jobs, running with the one and only (default in this case) JDK available for the CI server .
          Then comes a day you need to setup 2 new build jobs to run against the latest and greatest Oracle JDK.
          What practically happens – The latest and greatest JDK installed on the system and configured for the Jenkins, becomes the “Default” one for all available build jobs. And one needs to manually reconfigure hundreds of build jobs, and explicitly to tell them to use the former JDK….
          I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          Dragomir Nedyalkov added a comment - Not sure, in which direction the issue resolving is going to, but ... Imagine the scenario when you have environment with hundreds of already setup build jobs, running with the one and only (default in this case) JDK available for the CI server . Then comes a day you need to setup 2 new build jobs to run against the latest and greatest Oracle JDK. What practically happens – The latest and greatest JDK installed on the system and configured for the Jenkins, becomes the “Default” one for all available build jobs. And one needs to manually reconfigure hundreds of build jobs, and explicitly to tell them to use the former JDK…. I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          Daniel Beck added a comment -

          dragomir: That one is easy: Add a second explicit JDK (that no job will be using) and configure the two jobs to explicitly use the first explicit JDK.

          OTOH if you already had 1 configured JDK that was used by default by 100 jobs, and then add a second, and all jobs then back to System Default, that is a PITA. Either reconfigure a lot of jobs, or be stuck at 1 JDK forever.

          Daniel Beck added a comment - dragomir : That one is easy: Add a second explicit JDK (that no job will be using) and configure the two jobs to explicitly use the first explicit JDK. OTOH if you already had 1 configured JDK that was used by default by 100 jobs, and then add a second, and all jobs then back to System Default, that is a PITA. Either reconfigure a lot of jobs, or be stuck at 1 JDK forever.

          Dragomir said

          I do not see any workaround to get out of this nasty situation easily. Or am I wrong?

          By using Configuration Slicing Plugin there is possible to change JDK in a lot of jobs in simple way.

          Vladimir Kralik added a comment - Dragomir said I do not see any workaround to get out of this nasty situation easily. Or am I wrong? By using Configuration Slicing Plugin there is possible to change JDK in a lot of jobs in simple way.

          I've opened a pull request to improve the wording here: https://github.com/jenkinsci/jenkins/pull/1528

          Wilfred Hughes added a comment - I've opened a pull request to improve the wording here: https://github.com/jenkinsci/jenkins/pull/1528

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4340
          JENKINS-755 Describe the built-in JDK as '(System)'. (Revision ff021d3c374a067d622fdb078a4e391149df7d41)

          Result = SUCCESS
          whughes : ff021d3c374a067d622fdb078a4e391149df7d41
          Files :

          • core/src/main/java/hudson/model/JDK.java

          dogfood added a comment - Integrated in jenkins_main_trunk #4340 JENKINS-755 Describe the built-in JDK as '(System)'. (Revision ff021d3c374a067d622fdb078a4e391149df7d41) Result = SUCCESS whughes : ff021d3c374a067d622fdb078a4e391149df7d41 Files : core/src/main/java/hudson/model/JDK.java

          Oleg Nenashev added a comment -

          Oleg Nenashev added a comment - Fixed in https://github.com/jenkinsci/jenkins/pull/1528

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/0cc465e706f69b7ee0389749233ab2f33ca47eed
          Log:
          Noting fix of JENKINS-755 in https://github.com/jenkinsci/jenkins/pull/1528

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: changelog.html http://jenkins-ci.org/commit/jenkins/0cc465e706f69b7ee0389749233ab2f33ca47eed Log: Noting fix of JENKINS-755 in https://github.com/jenkinsci/jenkins/pull/1528

          The fix for this problem, which was released in Jenkins 1.635, appears to have caused a new bug JENKINS-31217

          Matthew Webber added a comment - The fix for this problem, which was released in Jenkins 1.635, appears to have caused a new bug JENKINS-31217

          Code changed in jenkins
          User: Oleg Nenashev
          Path:
          core/src/main/java/hudson/model/AbstractProject.java
          core/src/main/java/hudson/model/JDK.java
          core/src/main/java/jenkins/model/Jenkins.java
          core/src/test/java/jenkins/model/JDKNameTest.java
          http://jenkins-ci.org/commit/jenkins/730d6ecb2d29b25ef69f5cf49e097fb09dbfc3a6
          Log:
          Merge pull request #1528 from Wilfred/better_default_text

          JENKINS-755 Describe the built-in JDK as '(System)'.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Oleg Nenashev Path: core/src/main/java/hudson/model/AbstractProject.java core/src/main/java/hudson/model/JDK.java core/src/main/java/jenkins/model/Jenkins.java core/src/test/java/jenkins/model/JDKNameTest.java http://jenkins-ci.org/commit/jenkins/730d6ecb2d29b25ef69f5cf49e097fb09dbfc3a6 Log: Merge pull request #1528 from Wilfred/better_default_text JENKINS-755 Describe the built-in JDK as '(System)'.

            wilfredh Wilfred Hughes
            teilo James Nord
            Votes:
            48 Vote for this issue
            Watchers:
            49 Start watching this issue

              Created:
              Updated:
              Resolved: