{"id":12,"date":"2006-08-03T02:48:31","date_gmt":"2006-08-03T02:48:31","guid":{"rendered":""},"modified":"2017-03-07T19:51:21","modified_gmt":"2017-03-07T19:51:21","slug":"java_home_pointing_to_generation_1_syste","status":"publish","type":"post","link":"https:\/\/blogs.gentoo.org\/nichoj\/2006\/08\/03\/java_home_pointing_to_generation_1_syste\/","title":{"rendered":"JAVA_HOME pointing to generation-1 system vm"},"content":{"rendered":"<p>So, one of the issues that has come up on occaision is that JAVA_HOME ends up pointing at, for instance, \/opt\/blackdown-jdk-1.4.2.03, instead of the shiny, recently unmasked Java 1.5 you installed and set as your VM of choice.<\/p>\n<p>The reason for this has is legacy support. java-config-1 isn&#8217;t so smart. It determines what the current VM is based on JAVA_HOME in the environment. It expects it to be living under \/opt\/${P}, where ${P} is the name and version of the VM.<\/p>\n<p>The workaround we found is described in the <a href=\"http:\/\/www.gentoo.org\/proj\/en\/java\/java-upgrade.xml#doc_chap6\">upgrade guide<\/a>. However, the problem is, that java-config-1 would then no longer be able to know what VM is currently being used, which is a bit problematic.<\/p>\n<p>Thanks to the hax0ring skills, we now have a patched java-config-1 that uses VMHANDLE instead of JAVA_HOME. VMHANDLE is the token by which a VM is identified with the new Java system, and happens to be in the environment.<\/p>\n<p>We have added a new entry for \/etc\/profile.d, which uses the prescribed way of setting JAVA_HOME from the upgrade guide. This means that JAVA_HOME would be set correctly most of the time. The only time it wouldn&#8217;t be accurate would be if you did not have a user vm set (JAVA_HOME points at \/etc\/java-config-2\/current-system-vm), and then you set a user vm, JAVA_HOME would point at current-system-vm, instead of ~\/.gentoo\/java-config-2\/current-user-vm. Running &#8216;source \/etc\/profile&#8217; though, remedies the problem.<\/p>\n<p>Perhaps java-config-2 can be updated to give notice that you need to source \/etc\/profile ? Or perhaps it can directly update JAVA_HOME&#8230; The only problem with the the latter point ist hat it would probably only fix JAVA_HOME in the current terminal, and not in all the other open terminals.<\/p>\n<p>I&#8217;ve added revision bumps of java-config to the tree that work as described here. Because of the changes though, I&#8217;ve put them in package.mask while we finish testing the new way of handling JAVA_HOME. The package.mask entry is below, for those interested in testing and providing feedback:<\/p>\n<pre>\r\n# Joshua Nichols &lt;nichoj@gentoo.org&gt; (02 Aug 2006)\r\n# Testing new versions of java-config, which will let us remove\r\n# JAVA_HOME from env, which points to generation-1 system vm\r\n=dev-java\/java-config-1.3.0-r3\r\n=dev-java\/java-config-2.0.26-r6\r\n<\/pre>\n<p>Assuming there aren&#8217;t any issues while testing, I expect to unmask it in a day or two. At that point, I&#8217;ll also update all the env.d files for the VMs, so they no longer export JAVA_HOME (note: this is different from the profile.d, which is actually overwriting the JAVA_HOME originally being set by the env.d file).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>So, one of the issues that has come up on occaision is that JAVA_HOME ends up pointing at, for instance, \/opt\/blackdown-jdk-1.4.2.03, instead of the shiny, recently unmasked Java 1.5 you installed and set as your VM of choice. The reason for this has is legacy support. java-config-1 isn&#8217;t so smart. It determines what the current &hellip; <a href=\"https:\/\/blogs.gentoo.org\/nichoj\/2006\/08\/03\/java_home_pointing_to_generation_1_syste\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">JAVA_HOME pointing to generation-1 system vm<\/span><\/a><\/p>\n","protected":false},"author":35,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/posts\/12"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/users\/35"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/comments?post=12"}],"version-history":[{"count":1,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/posts\/12\/revisions"}],"predecessor-version":[{"id":37,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/posts\/12\/revisions\/37"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/media?parent=12"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/categories?post=12"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/nichoj\/wp-json\/wp\/v2\/tags?post=12"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}