Obscure eclipse failures with OpenJDK 7

[Florian Weimer]

A stock build of OpenJDK 7 on Debian sid results in obscure failures
when running Eclipse due to internal errors in java.util.zip:

java.lang.InternalError: error code: -6
	at java.util.zip.Deflater.init(Native Method)
	at java.util.zip.Deflater.<init>(Deflater.java:140)
	at java.util.zip.ZipOutputStream.<init>(ZipOutputStream.java:117)
	at java.util.zip.ZipOutputStream.<init>(ZipOutputStream.java:103)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizer.writeTaskList(TaskListExternalizer.java:105)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizationParticipant$2.execute(TaskListExternalizationParticipant.java:126)
	at org.eclipse.mylyn.internal.tasks.core.TaskList.run(TaskList.java:654)
	at org.eclipse.mylyn.internal.tasks.core.externalization.TaskListExternalizationParticipant.save(TaskListExternalizationParticipant.java:133)
	at org.eclipse.mylyn.internal.tasks.core.externalization.AbstractExternalizationParticipant.execute(AbstractExternalizationParticipant.java:70)
	at org.eclipse.mylyn.internal.tasks.core.externalization.ExternalizationManager$ExternalizationJob.run(ExternalizationManager.java:200)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

I guess that this is an incompatibility between the system zlib (which
is loaded by Eclipse) and OpenJDK's copy.  Both use the same symbols,
and with ELF dynamic linking, it is a bit hard to predict which
definition gets picked up.  (I haven't positively identified such a
symbol clash as the actual cause, but -6 is Z_VERSION_ERROR in the
system zlib, and OpenJDK's zlib copy doesn't return this error code,
so I'm reasonably convinced I've identified the problem.)

There are several ways to work around that: Dynamically link against
the system zlib in OpenJDK (this is what I did, using the patch from
IcedTea), use "ld -r" with some linker script to hide the zlib
symbols, use hidden visibility, use symbol versioning, or rename all
definitions in the source file.

I don't know why this issue only appeared relatively recently.
Perhaps the system zlib and OpenJDK's version were somewhat
compatible, hiding the name clash.  Or there were some changes in
OpenJDK how dlopen was used.