Wiki Navigation

Common Problems

java-check-environment tells you to emerge the same VMs over and over. Or, …
Applications try to use JAVA_HOME, which is set to the Generation-1 VM
emerge fails with "There was a problem determining which VM to use for …
Emerge fails because it can't find an env file
Java generates errors like "Java HotSpot?(TM) Client VM warning: Can't …
Can't find dependency for >=dev-java/blackdown-jdk-1.5
I have Java 1.5 JDK installed, but it isn't listed by java-config-1 -L
java-config-1 gives a traceback with KeyError?: 'VMHANDLE'
java-config-1 -L lists no VM as used, java-check-environment says "No …
java-config-1 -L and java-check-environment say "Cannot find JAVA_HOME in …
java-config-1 -L fails with UnboundLocalError?: local variable …

When adding new problems, please follow the example of having a title, example of the problem, cause, and solution.

java-check-environment tells you to emerge the same VMs over and over. Or, java-config-1 -L doesn't list anything

Cause

This is likely due to not fully keywording packages for the new Java system. Specifically, this is usually caused by not keywording all the VMs that you have installed on your system.

Solution

Ensure that you have followed the Java Upgrade Guide fully. Specifically, ensure that you have keyworded all the packages related to the new Java system.

Applications try to use JAVA_HOME, which is set to the Generation-1 VM

Cause

As is, JAVA_HOME will be what your system-vm for Generation-1 is set to (i.e. /etc/env.d/20java). This will be an issue until the particular application is converted to use the new eclasses.

Workaround

This has been addressed with java-config 1.3.1 and 2.0.27. Please update to those versions or above.

emerge fails with "There was a problem determining which VM to use for generation-1"

Example of the problem

 * There was a problem determining which VM to use for generation-1
 * You may need to set your generation-1 VM again, and run env-update &&
source/etc/profile
 * Also, make sure you have followed the Java Upgrade Guide:
 * http://www.gentoo.org/proj/en/java/java-upgrade.xml          

but from "java-config-1 -L" list seems like the system vm is set properly, java-check-environment also reports no problem

Cause

/etc/env/20java wasn't updated to contain GENERATION=2 and VMHANDLE variables. These are not checked by java-config-1 -L (prior to 1.3.2) and java-check-environment (prior to 0.10-r3) but need to be present at emerge time.

Solution

Run java-config-1 -S <system-vm> && env-update && source/etc/profile

This will properly regenerate the env file and source it. Also, java-config version 1.3.2 and java-check-environment in java-config-wrapper version 0.10-r3 and above are updated to catch this problem.

Emerge fails because it can't find an env file

Example of the problem

!!! ERROR: dev-java/sun-jdk-1.5.0.07 failed.
Call stack:
  ebuild.sh, line 1545:   Called dyn_install
  ebuild.sh, line 1019:   Called src_install
  sun-jdk-1.5.0.07.ebuild, line 189:   Called set_java_env
  java-vm-2.eclass, line 66:   Called die

!!! unable to find the env file: /usr/portage/dev-java/sun-jdk/files/sun-jdk-1.5
!!! If you need support, post the topmost build error, and the call stack if relevant.

Cause

The problem here is likely because either you haven't done emerge --sync in a while, and/or you are still using migration-overlay.

Solution

Do an emerge --sync, and remove migration-overlay from your PORTDIR_OVERLAY in /etc/make.conf

Java generates errors like "Java HotSpot?(TM) Client VM warning: Can't detect initial thread stack location"

Example of the problem

# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (4F533F4C494E55583F491418160E4350500387), pid=10311, tid=3085527232
#
# Java VM: Java HotSpot(TM) Client VM (1.4.2_12-b03 mixed mode)
 
---------------  T H R E A D  ---------------
 
Current thread is native thread
 
Stack: [0xbf8ea000,0xbfadc000)
[error occurred during error reporting, step 110, id 0xb]
 
 
[error occurred during error reporting, step 120, id 0xb]

Cause

You probably haven't mounted /proc.

Solution

As root, mount proc.

# mount /proc

Can't find dependency for >=dev-java/blackdown-jdk-1.5

Example of the problem

emerge: there are no ebuilds to satisfy ">=dev-java/blackdown-jdk-1.5".
(dependency required by "dev-util/eclipse-sdk-3.2" [ebuild])

Cause

The way that virtual/jre and virtual/jdk are handled has changed recently. Specifically, they are using 'new-style' virtuals.

Old-style virtuals would have a PROVIDE file that lists which virtuals it provides. The downside of this is that emerge has to check all installed packages to see what package provides a particular virtual that is depended on. It also has the limitation that it isn't smart about the version of the package. For example, kaffe is a 1.4 JDK, but is versioned like 1.1.7, and consequently wouldn't meet the dependency of '>=virtual/jdk-1.4'.

New-style virtuals are basically normal ebuilds that have 'or', ie , dependencies on the packages that provide the dependency. This addressees the two limitations just mentioned.

Unfortunately, having old PROVIDE files around can confuse portage, giving you the above error.

Solution

Assuming you have the latest version of java-config-wrapper, you can run:

# java-check-environment virtual_provides

This will give you a list of stale provide files, and prompt you to delete them

I have Java 1.5 JDK installed, but it isn't listed by java-config-1 -L

Example of the problem

$ java-config-1 -L
[ibm-jdk-bin-1.4.2.04] "IBM JDK 1.4.2.04" (/etc/env.d/java/20ibm-jdk-bin-1.4.2.04)

$ java-config-2 -L
4) IBM JDK 1.4.2.04 [ibm-jdk-bin-1.4] (/usr/share/java-config-2/vm/ibm-jdk-bin-1.4)
5) IBM JDK 1.5.0.2 [ibm-jdk-bin-1.5] (/usr/share/java-config-2/vm/ibm-jdk-bin-1.5)

Cause

This is intentional. We don't allow the use of Java 1.5 for generation-1 system vm. The reason for this is that doing so would re-introduce all the problems that required Java 1.5 be masked in the first place.

Solution

There really isn't an easy one. The best thing that can be done is help with the effort of migrating packages to the new Java system, and testing the new Java aystem in general so we can get it stablized.

java-config-1 gives a traceback with KeyError?: 'VMHANDLE'

Example of the problem

# java-config-1
Traceback (most recent call last):
  File "/usr/bin/java-config-1", line 14, in ?
    from java_config import jc_options
  File "/usr/lib/python2.4/site-packages/java_config/jc_options.py", line 18, in ?
    from jc_util import get_line_from_env_file
  File "/usr/lib/python2.4/site-packages/java_config/jc_util.py", line 97, in ?
    JAVA_HOME = get_java_home()
  File "/usr/lib/python2.4/site-packages/java_config/jc_util.py", line 82, in get_java_home
    if vmHandle == os.environ['VMHANDLE']:
  File "/usr/lib/python2.4/UserDict.py", line 17, in __getitem__
    def __getitem__(self, key): return self.data[key]
KeyError: 'VMHANDLE'

Cause

You have old buggy java-config-1 (that has been package.masked) installed.

Solution

Upgrade java-config to 1.3.2 or above. Make sure you have no stale java stuff in /etc/portage/package.unmask

java-config-1 -L lists no VM as used, java-check-environment says "No Generation-1 System VM is set!" no matter what I do

Cause

You were using the package.masked java-config ebuilds at some point, and then downgraded but /etc/profile.d/java-config-2.sh was left over.

Solution

This has been fixed with java-config-2.0.27, which is now unmasked.

java-config-1 -L and java-check-environment say "Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc" (or 22fop)

Example of the problem

# java-check-environment
 * === Java Environment Checker ===
 * The purpose of this script is to check the sanity of your Java Environment.
 * We have significantly changed and improved the way Java is handled in many respects.
 * Please refer to http://www.gentoo.org/proj/en/java/java-upgrade.xml for details

 * Checking vm_environment_files ...                                                       [ ok ]

 * Checking user_settings ...
 * Running as root. Don't need to check user settings.                                     [ ok ]

 * Checking generation_1_system_vm ...
Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc                              [ ok ]

 * Checking virtual_provides ...                                                           [ ok ]

 * Java environment is sane. Congratulations!

# java-config-1 -L
Cannot find JAVA_HOME in config file /etc/env.d/java/22javacc
[blackdown-jre-1.4.2.03] "Blackdown JRE 1.4.2.03" (/etc/env.d/java/20blackdown-jre-1.4.2.03)
[sun-jdk-1.4.2.12] "Sun JDK 1.4.2.12" (/etc/env.d/java/20sun-jdk-1.4.2.12) *
[blackdown-jdk-1.4.2.03] "Blackdown JDK 1.4.2.03" (/etc/env.d/java/20blackdown-jdk-1.4.2.03)

Cause

It's just a warning caused by java-config reading env files that don't belong to a VM.

Solution

Upgrade java-config to 1.3.2 which will ignore such files.

java-config-1 -L fails with UnboundLocalError?: local variable 'envVmHandle' referenced before assignment

== Example of the problem ===

localhost / # java-config-1 -L
Traceback (most recent call last):
  File "/usr/bin/java-config-1", line 14, in ?
    from java_config import jc_options
  File "/usr/lib64/python2.4/site-packages/java_config/jc_options.py", line 18, in ?
    from jc_util import get_line_from_env_file
  File "/usr/lib64/python2.4/site-packages/java_config/jc_util.py", line 110, in ?
    JAVA_HOME = get_java_home()
  File "/usr/lib64/python2.4/site-packages/java_config/jc_util.py", line 95, in get_java_home
    if vmHandle == envVmHandle:
UnboundLocalError: local variable 'envVmHandle' referenced before assignment

Cause

This was a bug in java-config-1.3.1.

Solution

This was fixed in java-config-1.3.1-r1.

Download in other formats:

Plain Text