Causes several facilties of Eclipse to fail: Java class launch, Error Log.

Status changed to 'Confirmed' because the bug affects multiple users.

Same DistroRelease as above, linux-generic 3.2.0.30.32.

I have pretty much the same as reported, both with 7u7-2.3.2-1ubuntu0.12.04.1 and with 6b24-1.11.4-1ubuntu0.12.04.1.

This started after the following upgrades (from /var/dpkg/log):

2012-09-13 10:24:04 upgrade openjdk-7-jdk 7~u3-2.1.1~pre1-1ubuntu3 7u7-2.3.2-1ubuntu0.12.04.1
2012-09-04 11:26:10 upgrade openjdk-6-jdk 6b24-1.11.3-1ubuntu0.12.04.1 6b24-1.11.4-1ubuntu0.12.04.1

Example from Eclipse .metadata/.log in one of my workspaces:

eclipse.buildId=I20120608-1400
java.version=1.6.0_24
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=nb_NO
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.ui.workbench 4 2 2012-09-14 12:01:40.224
!MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench".
!STACK 1
org.eclipse.core.runtime.CoreException: Plug-in "org.eclipse.equinox.p2.ui.sdk.scheduler" was unable to instantiate class "org.eclipse.equinox.internal.p2.ui.sdk.scheduler.AutomaticUpdateScheduler".
        at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:194)
        at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:188)
        at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
        at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
        at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
        at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:273)
        at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:52)
        at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:269)
        at org.eclipse.ui.internal.EarlyStartupRunnable.getExecutableExtension(EarlyStartupRunnable.java:117)
        at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:66)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.ui.internal.Workbench$52.run(Workbench.java:2357)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Caused by: java.lang.ExceptionInInitializerError
        at com.ibm.icu.util.TimeZone.getDefault(TimeZone.java:754)
        at com.ibm.icu.util.Calendar.getInstanceInternal(Calendar.java:1626)
        at com.ibm.icu.util.Calendar.getInstance(Calendar.java:1590)
        at org.eclipse.equinox.internal.p2.ui.sdk.scheduler.AutomaticUpdateScheduler.<clinit>(AutomaticUpdateScheduler.java:50)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
        at java.lang.Class.newInstance0(Class.java:372)
        at java.lang.Class....

Not sure if this is a clue, buit given that it's the ZoneInfoFile that bombs out, I suspect it might be:

# grep open log | grep -v karltk | grep '/zi/'
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/Europe/Oslo", 0x7fe2ac8a5f50) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/ZoneInfoMappings", 0x7fe2ac8a5f10) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/GMT+01:00", 0x7fe2ac8a5f50) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/ZoneInfoMappings", 0x7fe2ac8a5f10) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/GMT+01:00", 0x7fe2ac8a5f20) = -1 ENOENT (No such file or directory)
[pid 16150] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/ZoneInfoMappings", 0x7fe232b43ab0) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/GMT", 0x7fe2ac8a09a0) = -1 ENOENT (No such file or directory)
[pid 16125] stat("/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/ZoneInfoMappings", 0x7fe2ac8a0950) = -1 ENOENT (No such file or directory)

The zone info files appear to be located elsewhere:

/usr/lib/jvm/java-7-openjdk-common/jre/lib/zi/Europe/Oslo
/usr/share/javazi/Europe/Oslo
/usr/share/zoneinfo/Europe/Oslo
/usr/share/zoneinfo/posix/Europe/Oslo
/usr/share/zoneinfo/right/Europe/Oslo

Following up one the above:

# file /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/Europe/Oslo
/usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi/Europe/Oslo: broken symbolic link to `../../../../../java-7-openjdk-common/jre/lib/zi/Europe/Oslo'

There are multiple levels of symlinks, and the symlinks inside /usr/share/javazi are just plain broken.

these should be the correct symlinks, I guess the update did something wrong with it.

$ ls -l /usr/lib/jvm/java-?-openjdk-amd64/jre/lib/zi
lrwxrwxrwx 1 root root 27 Jan 22 2012 /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi
lrwxrwxrwx 1 root root 27 Feb 25 2012 /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/zi -> ../../../../../share/javazi

This prevented Eclipse from running any Java projects or even showing the list of installed JRE's.
Thanks to the comments above I replaced '/usr/share/javazi' with a symlink to '/usr/lib/jvm/java-7-openjdk-common/jre/lib/zi' and Eclipse can run Java projects again.

I'm pretty sure the java-7-openjdk updates are responsible for this behavior:

Start-Date: 2012-09-12 16:46:50
Commandline: apt-get dist-upgrade
Upgrade: openjdk-7-doc:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), openjdk-7-jdk:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), openjdk-7-jre:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), openjdk-7-source:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), icedtea-7-jre-jamvm:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), openjdk-7-jre-lib:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1), openjdk-7-jre-headless:amd64 (7~u3-2.1.1~pre1-1ubuntu3, 7u7-2.3.2-1ubuntu0.12.04.1)
Remove: icedtea-7-jre-cacao:amd64 (7~u3-2.1.1~pre1-1ubuntu3)
End-Date: 2012-09-12 16:47:29

/usr/share/javazi is installed by tzdata-java and does not consist of symlinks. java-7-openjdk is not even my current update-alternatives selection, yet all of these broken symlinks attempt to point to it:

$ update-alternatives --display java
java - auto mode
  link currently points to /usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java - priority 1061
  slave java.1.gz: /usr/lib/jvm/java-6-openjdk-amd64/jre/man/man1/java.1.gz
/usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java - priority 1051
  slave java.1.gz: /usr/lib/jvm/java-7-openjdk-amd64/jre/man/man1/java.1.gz
Current 'best' version is '/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java'.

$ readlink -f $(which java)
/usr/lib/jvm/java-6-openjdk-amd64/jre/bin/java

I should have mentioned you can restore the files with:

$ sudo apt-get install --reinstall tzdata-java

I can confirm that reinstalling tzdata-java fixes the problem for me too, and that both java-6-openjdk and java-7-openjdk are "healed".

Before the reinstall, the files (not directories) inside /usr/share/javazi/ were broken symlinks into ../../../../../java-7-openjdk-common/jre/lib/zi/.

After reinstalling tzdata-java, the files inside /usr/share/javazi are not symlinks anymore, but the actual timezone data files.

Thus, the "outer-level" symlinks in /usr/lib/jvm/java-?-openjdk-amd64/jre/lib/zi finally work again. Woohoo!

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package openjdk-7 - 7u7-2.3.2a-0ubuntu1

---------------
openjdk-7 (7u7-2.3.2a-0ubuntu1) quantal; urgency=low

  * Repackage the source to drop the cacao tarball (and packaging files).
  * Depend again on system provided tzdata-java and restore the zi
    symlink on upgrade. LP: #1050404.
  * libgnome2-0, libgnomevfs2-0, libgconf2-4 are not prepared for multiarch.
    Don't depend on these so that openjdk-7 can be installed as a multiarch
    package.
 -- Matthias Klose <email address hidden> Sat, 15 Sep 2012 17:01:12 +0200

This bug was fixed in the package openjdk-7 - 7u7-2.3.2a-0ubuntu0.12.04.1

---------------
openjdk-7 (7u7-2.3.2a-0ubuntu0.12.04.1) precise-security; urgency=low

  * Depend on tzdata-java (>= 2012e-0ubuntu0.12.04.1) to force a
    re-installation of the package. LP: #1050404.
  * Build a transitional icedtea-7-jre-cacao package to ease upgrades.
 -- Matthias Klose <email address hidden> Wed, 19 Sep 2012 02:20:26 +0200

This bug was fixed in the package tzdata - 2012e-0ubuntu0.12.04.1

---------------
tzdata (2012e-0ubuntu0.12.04.1) precise-security; urgency=low

  * Re-upload to precise. The openjdk-7 7u7-2.3.2-1ubuntu0.12.04.1
    upload did remove the /usr/share/javazi directory.
    openjdk=7 7u7-2.3.2a-0ubuntu0.12.04.1 now depends on this
    version of the package to fore a reinstallation. LP: #1050404.
 -- Matthias Klose <email address hidden> Sat, 15 Sep 2012 17:16:34 +0200

I'm closing the eclipse task because the update to tzdata and openjdk-7 should have addressed the issue. Please re-open this bug or file a new one if that's not the case. Thanks!

For me, Eclipse hangs (100% CPU) on startup at about 60% through the splash screen progress bar (status: 'Loading Workbench'). This still happens if I purge and reinstall eclipse and delete my ~/.eclipse directory

P.S. my openjdk-7-jre is version 7u9-2.3.3-ubuntu1~12.10.1