Bugzilla Bug 156353

java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.

Probably the same problem is also in 1.4 so we should add some built_with_use
tests to the ebuilds. I have not tested with 1.6 yet and don't have the time to
do it today any way as I need to get up early tomorrow morning for the army.

this is a sun java problem.
As reported here:
http://www.debian-news.net/modules/news/article.php?storyid=1782
this bug should be posted to Sun bug tracking

I've found a similar problem adding xcb feature to libX11 and mesa, and rebuild
xfce4 from SVN, but looks like is a libXcomposite bug just fixed:
http://comments.gmane.org/gmane.comp.desktop.xfce.devel.version4/12406

Good luck!

Hi, this looks to be a libXrandr thing:
http://lists.freedesktop.org/archives/xcb/2007-January/002523.html

The patch is available here:
http://gitweb.freedesktop.org/?p=xorg/lib/libXrandr.git;a=blobdiff;h=778422747ddaa16324bd90a31134eb1c7abd852c;hp=577ccd653aa02933e570c66cd6eadd501e739db3;hb=36a4a633a93a89bd854f49e670777925c9751de3;f=src/XrrConfig.c

Didn't see any mention of java in those links. As for the libs, the only one
mentioned in the debian bug that sun-jdk depends on directly is libXi (didn't
check for indirect deps), so maybe that's it?

What happened was that I was trying to use LWJGL on with XCB enabled and I got
this weird problem. For some reason, none of my other java apps had this issue,
so I assumed it was due to LWJGL and I posted in their forums about it. One of
their developers (Elias Naur) was nice enough to spend some time and track down
where the issue really came from.

http://lwjgl.org/forum/index.php/topic,2168.0.html

Oh, the libXrandr patch by itself does not seem to be enough. Maybe just patch
out the assertion for now?

According to this:
https://bugs.freedesktop.org/show_bug.cgi?id=8926
A fix in libX11 was committed on Nov. 11 but libX11-1.1.1 was released on Nov.
30 and some people still have bugs?

Yep, this definetely still occurs with an up to date (well as-of 20070225) ~x86
system. Easly reproducable by invoking appletviewer.

Hmm, I just gave up and patched out the assertion. It makes the locking
pointless, but at least things work now.

Created an attachment (id=113215) [edit]
Java VM crash log

Some more information.. hopefully someone will be able to extract the required
data.

Here is a work around that works on 1.4:
https://bugs.freedesktop.org/show_bug.cgi?id=9336#c13

(In reply to comment #0)
> java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
> 
> Probably the same problem is also in 1.4 so we should add some built_with_use
> tests to the ebuilds. I have not tested with 1.6 yet and don't have the time to
> do it today any way as I need to get up early tomorrow morning for the army.
> 
I found this bug under different circumstances, and have done a little
searching on it.

Apparently xcb has "tightened up" the locking over what Xlib did, and it shows
up all over the place. Sun's JVM is merely one spot. For the 2 I've personally
run into there's also Cadence IC Craftsman 6.1, and one of the collection of
programs in xfce-4.4. (Apparently whatever displays the wallpaper, because
that's what's broken.) There is a patch midway down the page here:
http://planet.gentoo.org/developers/betelgeuse/2006/11/26/do_not_turn_on_the_xcb_use_flag_if_you_p_5
referenced by "Brian [Visitor]" that relaxes xcb locking semantics to match
what Xlib did. While technically not correct, it does allow old code to run,
including closed-source code like Cadence ICC-6.1.

The patch is also controlled by an environment variable, so it's possible to
turn on the loose locking on an as-needed basis, and leave things tight,
otherwise.

I would suggest including this patch as an option.

I do not exactly know is this patch [1] is good or not, but it solves the crash
with sun-jdk-1.6.
A good thing to apply this to libxcb ?

[1]
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11-libs/libxcb/xcb_xlib-no-assert-on-lock.patch

(In reply to comment #12)
> I do not exactly know is this patch [1] is good or not, but it solves the crash
> with sun-jdk-1.6.
> A good thing to apply this to libxcb ?
> 
> [1]
> http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/x11-libs/libxcb/xcb_xlib-no-assert-on-lock.patch
> 
Technically no, practically yes.

This patch allows the locking to be "sloppy", as does the patch I referenced.
The difference is that the patch I referenced makes locking sloppy only when an
environment variable is set, whereas this patch allows locking to be sloppy all
of the time.

Without some sort of patch, xcb is essentially useless, because there is just
too much "broken" software out there. I'm trying to run with "+xcb" in
/etc/make.conf, and have so far set "-xcb" in /etc/portage/package.use for
libX11 and mesa, hoping to pick up some of the benefits. 

This is a problem on EVERY system I maintain, so far. "Fix the client" is
obviously the right answer, but equally obviously it's going to take time.
Within that time, without a patch, xcb is a non-starter for ordinary usage.

CCing x11 for advice... maybe you would include that patch via some
"unsafe-locking" flag?

(In reply to comment #14)
> CCing x11 for advice... maybe you would include that patch via some
> "unsafe-locking" flag?
> 
I was thinking more in terms of keeping safe locking on by default. Then bad
apps could be wrapped in a script, or existing wrappers could be tweaked to add
the "unsafe locking" flag.

BTW, there's another fix available for this, though it's the "universally
unsafe" form: In "/etc/portage/env/x11-libs/libxcb-1.0" I have 'CFLAGS="-O2
-march=pentium3 -fomit-frame-pointer -pipe -DNDEBUG"' and that (the "-DNDEBUG")
seems to solve the problem. At least it allows Cadence IC6.1.1 to run. But it
means I've given up all the enhanced locking safety checking of xcb. Hopefully
a new release of libxcb will fix this, and my tweak will fade silently into the
night.

(In reply to comment #14)
> CCing x11 for advice... maybe you would include that patch via some
> "unsafe-locking" flag?
> 

Distributions have been asked to specifically not do this by upstream.  Most
client bugs have been fixed.

The upstream bug is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373.
 If anyone's willing to provide Sun with a stacktrace, they would really
appreciate it.

(In reply to comment #10)
> Here is a work around that works on 1.4:
> https://bugs.freedesktop.org/show_bug.cgi?id=9336#c13
> 

It really works for jdk-1.4, wouldn't putting a use flag in jdk1.4 specifying
to use system xinerama an "acceptable" workaround?

basically i've put "LD_PRELOAD=/usr/lib/libXinerama.so" in my .profile but i
think a wrapper script for jdk1.4 would be enough
If that fixed jdk1.4 are we maybe only missing some other embedded X library in
the jdk 1.5 and 1.6?

Here's a workaround from in the sun bug. It works for me with
dev-java/sun-jdk-1.5.0.11.

I worked with jcristau and christoph4 via IRC on #debian-x, and we managed to
track down the problem with broken locking in Sun Java 1.5 and 1.6.  It only
occurs if Java finds the Xinerama extension, at which point it does something
broken with locking and triggers the assertion.  If Java never finds the
Xinerama extension, it doesn't trigger the assertion for broken locking.

The following workarounds address this problem:

For sun-java5-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so

For sun-java6-bin:
sed -i 's/XINERAMA/FAKEEXTN/g'
/usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so

The same fix (applied to the appropriate file) might work for other
proprietary JDKs.

- Josh Triplett

You're welcome to try the libxcb ebuild from:
http://bugs.gentoo.org/show_bug.cgi?id=176839#c1

Somewhat ugly, but best way I could see of solving the problem until clients
are updated for the new xcb locking.

(In reply to comment #18)
> 
> The following workarounds address this problem:
> 
> For sun-java5-bin:
> sed -i 's/XINERAMA/FAKEEXTN/g'
> /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib/i386/xawt/libmawt.so
> 
> For sun-java6-bin:
> sed -i 's/XINERAMA/FAKEEXTN/g'
> /usr/lib/jvm/java-6-sun-1.6.0.00/jre/lib/i386/xawt/libmawt.so
> 

Don't know what Sun thinks about modifying their proprietary stuff like this.
Maybe we could add a xcb use flag for this.

(In reply to comment #20)
> Don't know what Sun thinks about modifying their proprietary stuff like this.
> Maybe we could add a xcb use flag for this.

What's the license say?

Please test with the following patch:

http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff_plain;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8;hp=65f0ab5d46d80d55fc04d4eb14fa05f130eb8b9c

That patch is for libX11-1.1.2

(In reply to comment #22)
> Please test with the following patch:
> 
> http://gitweb.freedesktop.org/?p=xorg/lib/libX11.git;a=commitdiff_plain;h=c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8;hp=65f0ab5d46d80d55fc04d4eb14fa05f130eb8b9c
> 

Doesn't seem to fix it here.
pena libX11-1.1.2 # patch -p1 <
/home/betelgeuse/patches/git-c2f88cdf5cd9c94b77e5bfdac572b5ac06ab4aa8.patch
patching file modules/im/ximcp/imDefLkup.c

<compile>

betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.6" jarwizard
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted
betelgeuse@pena ~ $ GENTOO_VM="sun-jdk-1.5" jarwizard
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted

Found this in the Sun bug at $URL:

well, it looks like everyone believe that the cause of the problem is old
version of
Xinerama we use.  We have updated it in 7.0 and so the problem must not be
reproducible 
with latest builds of jdk 7.

Since I can not check this (I have no environment for this :(  It would be nice
to get confirmation from the comunity.
Posted Date : 2007-06-04 08:53:46.0

So betelgeuse, what does openjdk do :)

(In reply to comment #25)
> Found this in the Sun bug at $URL:
> 
> well, it looks like everyone believe that the cause of the problem is old
> version of
> Xinerama we use.  We have updated it in 7.0 and so the problem must not be
> reproducible 
> with latest builds of jdk 7.
> 

The problem is a static copy of libXinerama being linked in. It will not be
solved as long as Sun is building their binaries on some old machine unless
they manually update the libXinerama copy there. So there are no problems with
OpenJDK as it builds against a Gentoo installed copy of libXinerama.

(In reply to comment #26)
> The problem is a static copy of libXinerama being linked in. It will not be
> solved as long as Sun is building their binaries on some old machine unless
> they manually update the libXinerama copy there.

Well they said they updated it for jdk7 builds so might be worth trying out and
reporting back so that they can do the same for 4/5/6 (hopefully at least
6...). Probably current jdk7 b13 isn't fixed yet because it's older than that
comment...

*** Bug 182444 has been marked as a duplicate of this bug. ***

(In reply to comment #27)
> Well they said they updated it for jdk7 builds so might be worth trying out and
> reporting back so that they can do the same for 4/5/6 (hopefully at least
> 6...). Probably current jdk7 b13 isn't fixed yet because it's older than that
> comment...

sun-jdk-1.7.0.0_alpha14 is in java-overlay, dated well after the comment on
upstream bug, so it should be fixed. can anyone test and report?

(In reply to comment #29)
> 
> sun-jdk-1.7.0.0_alpha14 is in java-overlay, dated well after the comment on
> upstream bug, so it should be fixed. can anyone test and report?
> 

betelgeuse@pena ~ $ JAVA_LAUNCHER_DEBUG=1 GENTOO_VM="sun-jdk-1.7" java -version
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b14)
Java HotSpot(TM) Tiered VM (build 1.7.0-ea-b14, mixed mode)
betelgeuse@pena ~ $ JAVA_LAUNCHER_DEBUG=1 GENTOO_VM="sun-jdk-1.7" jarwizard
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
Aborted

It's not.

Would be good to post that to upstream bug, and also that openjdk built against
xinerama version x.y works fine (IIRC you said that).

Parts of a discussion in #openjdk:
13:12 < Betelgeuse> tmarble: What is your stance on applying the sed fix in the
ebuilds?
13:12 < tmarble> until that's done what we've agreed on with the Debian X
maintainer is that the new X which enforces the new behavior will ship with the
binary editor hack to avoid the problem (since we
                 cannot get this fixed for older releases -- in time) and yet
it must work with xcb
13:12 < Betelgeuse> tmarble: At least it's not something that has passed the
TCK any more then.
13:13 < Betelgeuse> tmarble: So Debian will go with the sed?
13:14 < tmarble> right -- and the rationale is that Debian will not be
*distributing* the hacked binary (which would violate the DLJ), but individuals
can apply the fix
13:15 < Betelgeuse> yeah we are not either
13:16 < Betelgeuse> tmarble: I can add a xcb use flag for it so it's optional
13:16 < Betelgeuse> tmarble: You need xcb use flag turned on in the first place
to hit it
13:17 < Betelgeuse> tmarble: And then and einfo message that the binary is
modified and as such not passed the TCK
13:17 < Betelgeuse> tmarble: Does that sound prudent?
13:18 < tmarble> well, my lack of experience with gentoo is a little
challenging here...

Sun developer on Sun upstream bug now believes it's problem of X libraries and
filled a bug there, closing Sun's bug. I'm changing URL of this bug
accordingly.

Disable "xcb" use flag.

emerge --newuse world

Problem solved.

(In reply to comment #34)
> Disable "xcb" use flag.
> 
> emerge --newuse world
> 
> Problem solved.

workaround != solution

The X team has marked this as NOTOURBUG again, since Sun is improperly linking
some libs. Sun has reopened their bug and is in progress below:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373

*** Bug 189773 has been marked as a duplicate of this bug. ***

*** Bug 191810 has been marked as a duplicate of this bug. ***

*** Bug 192118 has been marked as a duplicate of this bug. ***

*** Bug 193184 has been marked as a duplicate of this bug. ***

The best "fix" so far seems to be to add

LIBXCB_ALLOW_SLOPPY_LOCK=1

to the java wrappers.

Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510

(In reply to comment #41)
> The best "fix" so far seems to be to add
> 
> LIBXCB_ALLOW_SLOPPY_LOCK=1
> 
> to the java wrappers.
> 
> Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510
> 

According to the upstream bug
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373), it is now
Closed/Fixed with version 7(b22). I don't know if this changes the status of
this bug at all though. I'm pretty new to bug tracking systems. =) So, I'll
leave that to the more knowledgeable.

(In reply to comment #42)
> (In reply to comment #41)
> > The best "fix" so far seems to be to add
> > 
> > LIBXCB_ALLOW_SLOPPY_LOCK=1
> > 
> > to the java wrappers.
> > 
> > Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510
> > 
> 
> According to the upstream bug
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373), it is now
> Closed/Fixed with version 7(b22). I don't know if this changes the status of
> this bug at all though. I'm pretty new to bug tracking systems. =) So, I'll
> leave that to the more knowledgeable.
> 

Until it hits our tree, this is still a valid bug.

(In reply to comment #41)
> The best "fix" so far seems to be to add
> 
> LIBXCB_ALLOW_SLOPPY_LOCK=1
> 
> to the java wrappers.
> 
> Idea from https://bugzilla.novell.com/show_bug.cgi?id=252510
> 

How? I tried export LIBXCB_ALLOW_SLOPPY_LOCK=1 then run simple javaws, same
error:

~/Desktop $ export LIBXCB_ALLOW_SLOPPY_LOCK=1
~/Desktop $ javaws -viewer
~/Desktop $ java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock'
failed.

You need libxcb 1.1 (or a personally patched 1.0) for that to work.

*** Bug 199074 has been marked as a duplicate of this bug. ***

Is there any workaround for this bug. I cannot use netbeans or eclipse .

Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment.

Sun has marked as closed, but the version annonced to be working is 7(b22).

So, this mean that we have to move to Java 7 (?) to get a working java on our
Compiz-fusion xcb enabled PC ?

> So, this mean that we have to move to Java 7 (?) to get a working java on our
> Compiz-fusion xcb enabled PC ?

That, or see comment 49 

(In reply to comment #48)
> Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment.

How bout we add this to run-java-tool (conditionally with xcb flag in
java-config, which would also pull >=libxcb-1.1)?
Or we can even do some generic "run-java-toolrc" sourcing (in /etc and $HOME)
and xcb flag would install this rc file with the variable in /etc.

(In reply to comment #51)
> (In reply to comment #48)
> > Yes, install libxcb 1.1 and set LIBXCB_ALLOW_SLOPPY_LOCK=1 in your environment.
> 
> How bout we add this to run-java-tool (conditionally with xcb flag in
> java-config, which would also pull >=libxcb-1.1)?
> Or we can even do some generic "run-java-toolrc" sourcing (in /etc and $HOME)
> and xcb flag would install this rc file with the variable in /etc.
> 

An elog describing the process in pkg_postinst(), or probably more usefully, a
pkg_config() that adds a file with the export to /etc/env.d would be the most
sensible solution IMO, it should not be enabled without user interaction since
the sloppy locking is a hack at best.

(In reply to comment #52)
> An elog describing the process in pkg_postinst(), or probably more usefully, a
> pkg_config() that adds a file with the export to /etc/env.d would be the most
> sensible solution IMO, it should not be enabled without user interaction since
> the sloppy locking is a hack at best.

Something like this, which is already in libxcb-1.1?

pkg_postinst() {
    x-modular_pkg_postinst

    elog "libxcb-1.1 adds the LIBXCB_ALLOW_SLOPPY_LOCK variable to allow"
    elog "broken applications to keep running instead of being aborted."
    elog "Set this variable if you need to use broken packages such as Java"
    elog "(for example, add LIBXCB_ALLOW_SLOPPY_LOCK=1 to /etc/env.d/00local"
    elog "and run env-update)."
}

> Something like this, which is already in libxcb-1.1?

Yeah, I'm assuming people don't read it, because they still come and CC on this
bug :) Therefore an out-of-the box workaround seems like a good idea to me.

(In reply to comment #53)
> 
> Something like this, which is already in libxcb-1.1?
> 
> pkg_postinst() {
>     x-modular_pkg_postinst
> 
>     elog "libxcb-1.1 adds the LIBXCB_ALLOW_SLOPPY_LOCK variable to allow"
>     elog "broken applications to keep running instead of being aborted."
>     elog "Set this variable if you need to use broken packages such as Java"
>     elog "(for example, add LIBXCB_ALLOW_SLOPPY_LOCK=1 to /etc/env.d/00local"
>     elog "and run env-update)."
> }
> 

Hehe, yes something like that - basically what I wrote in #176839 but more
sensical ;)  If people can't read, well...

*** Bug 204345 has been marked as a duplicate of this bug. ***

*** Bug 209838 has been marked as a duplicate of this bug. ***

sun-jdk and sun-jre-bin fixed in 1.6.0.06 just commited to CVS
I will leave this open until we get it stable, and should think where to
document that people with xcb should run 1.6 and not 1.5 (which I doubt they
will fix...)

Confirming this got fixed in 1.6.0.06. Please stabilise in few days.

Seems the problem is still present. I get the problem when I try to enable the
OpenGL interface within the program (could it be spawning another process
without carrying over the LIBXCB_ALLOW_SLOPPY_LOCK=1 var?...I'll ask.

kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $ eselect java-vm
list
Available Java Virtual Machines:
  [1]   blackdown-jdk-1.4.2
  [2]   emul-linux-x86-java-1.5
  [3]   emul-linux-x86-java-1.6
  [4]   icedtea
  [5]   icedtea-6
  [6]   sun-jdk-1.5
  [7]   sun-jdk-1.6
  [8]   sun-jre-bin-1.5
  [9]   sun-jre-bin-1.6  system-vm user-vm
kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $
LIBXCB_ALLOW_SLOPPY_LOCK=1 paraprof
java: xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
/home/kyron/TAU/TAU/x86_64/bin/paraprof: line 88:  8334 Aborted                
java -Xmx800m -Dderby.system.home=${LIBDIR} -Dpython.verbose=error
-Djava.library.path=${LIBDIR} -cp ${JARS} ${APPLE_OPTIONS}
edu/uoregon/tau/paraprof/ParaProf ${PPROFOPT} $*
kyron@kyron ~/1_Files/1_ETS/1_Maitrise/Code/K-Means/BLAS_test $             

Try explicitly exporting/setting the variable in a separate command from
running your program. Also make sure you're actually on libxcb 1.1, which is
~arch.

(In reply to comment #60)
> Seems the problem is still present. I get the problem when I try to enable the
> OpenGL interface within the program (could it be spawning another process
> without carrying over the LIBXCB_ALLOW_SLOPPY_LOCK=1 var?...I'll ask.
> 

You shouldn't even need the sloppy lock if you are running with 1.6.

(In reply to comment #61)
> Also make sure you're actually on libxcb 1.1

Yup, that did it. Also, as per Comment #62, I need not the exported variable. I
now only get the following failure in the command line without loosing my app:

Locking assertion failure.  Backtrace:
#0 /usr/lib/libxcb-xlib.so.0 [0x7f1705d5ca1c]
#1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f1705d5cac4]
#2 /usr/lib/libX11.so.6(_XReply+0x260) [0x7f17061afbe0]
#3
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(XineramaQueryScreens+0xd7)
[0x7f1707726167]
#4 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(xineramaInit+0x4b)
[0x7f17076ed88b]
#5 /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(awt_init_Display+0xfd)
[0x7f17076ed9fd]
#6
/opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(Java_sun_awt_X11GraphicsEnvironment_initDisplay+0x9)
[0x7f17076edb99]
#7 [0x7f174348ff80]

(In reply to comment #63)
> #1 /usr/lib/libxcb-xlib.so.0(xcb_xlib_unlock+0x24) [0x7f1705d5cac4]
> #2 /usr/lib/libX11.so.6(_XReply+0x260) [0x7f17061afbe0]
> #3
> /opt/blackdown-jdk-1.4.2.03/jre/lib/amd64/libawt.so(XineramaQueryScreens+0xd7)
> [0x7f1707726167]

Try libXinerama 1.0.3.

(In reply to comment #64)
> Try libXinerama 1.0.3.
> 

Same error messages.

I forgot to mention xinerama is not set in my USE flags (although libXinerama
was already installed as 1.0.2). The switch was made partly because of this
bug.

*** Bug 245129 has been marked as a duplicate of this bug. ***

On sun-jdk 1.5.0.16 as virtual/{jdk,jre}, I have added :
AWT_TOOLKIT=MToolkit
with :
LIBXCB_ALLOW_SLOPPY_LOCK=1
in /etc/env.d/00local.
Else java launches but I got blank (empty) boxes instead of my java (awt) GUIs.

ref : https://answers.launchpad.net/ubuntu/+question/26562

The version that fixed the issues is not even in tree now. Closing as fixed.