FS#41846 - [jre8-openjdk] _JAVA_AWT_WM_NONREPARENTING environment variable patch has not been included

Attached to Project: Arch Linux
Opened by Fernando Sanchez (grimpirate) - Saturday, 06 September 2014, 13:36 GMT
Last edited by Guillaume ALAUX (galaux) - Saturday, 20 September 2014, 13:34 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Guillaume ALAUX (galaux)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

In openjdk7 an vendor patch was introduced in order to fix behaviors with certain nonreparenting window managers. The patch has not been applied to openjdk8. This affects the runtime file typically located in /etc/profile.d/jre.sh as it invalidates the _JAVA_AWT_WM_NONREPARENTING environment variable.

Steps to reproduce:

Install package dwm and resize any window to note that resizing windows has no effect on the layout of a Swing application.

Workaround:

Use wmname LG3D to fool the JVM.

Solution:

Patch the source as in openjdk7. I have included the proposed diff file for the XWM.java file in the openjdk8 source.
   XWM.patch (1.4 KiB)
This task depends upon

Closed by  Guillaume ALAUX (galaux)
Saturday, 20 September 2014, 13:34 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in 8.u20-3
Comment by Fernando Sanchez (grimpirate) - Saturday, 06 September 2014, 22:56 GMT
Suggested patch had typographical mistakes, use this instead.
   XWM.patch (1.4 KiB)
   XWM.rev.patch (1.5 KiB)
Comment by Guillaume ALAUX (galaux) - Sunday, 14 September 2014, 15:01 GMT
This kind of patch typically belongs to upstream (either dwm or OpenJDK/IcedTea). It seems SUN had this bug about it [0]. Could you please report it back. Someone may be interested in incorporating it.

[0] http://bugs.java.com/view_bug.do?bug_id=6429775
Comment by Fernando Sanchez (grimpirate) - Monday, 15 September 2014, 00:45 GMT
I'm confused Guillaume the patch I wrote is basically the same as the one here:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk/openjdk7_nonreparenting-wm.diff?h=packages/java7-openjdk
Which is within the source files of the git package for the java7-openjdk project on Arch:
https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/java7-openjdk
Also remarked on here as a vendor-specific fix from Debian, wherein since 2009 the patch has yet to be applied, and I see no indication that it ever will be:
http://awesome.naquadah.org/wiki/Problems_with_Java#Use_OpenJDK_With_Vendor_Fix
Comment by Guillaume ALAUX (galaux) - Monday, 15 September 2014, 11:22 GMT
Yes, this sister patch is included in our jre7-openjdk package and I will include this new one into jre8-openjdk but still I think it definitely belongs to upstream.
Comment by Chauncey Goss (cgoss) - Monday, 15 September 2014, 23:30 GMT
I started the conversation upstream this past week (see the thread starting at http://mail.openjdk.java.net/pipermail/awt-dev/2014-September/008479.html),
and they're up for it. I can't officially send a patch, but maybe one of you could take command of this issue.
Comment by Chauncey Goss (cgoss) - Monday, 15 September 2014, 23:53 GMT
Note that if either of you are interested in upstreaming, the AWT path has changed for Java 9 (where the patch has to be submitted first). For java 9, the appropriate file is "src/java.desktop/unix/classes/sun/awt/X11/XWM.java" vs "src/solaris/classes/sun/awt/X11/XWM.java" for java 8u.
Comment by Guillaume ALAUX (galaux) - Tuesday, 16 September 2014, 11:30 GMT
Excellent, thanks Chauncey. I can't find the bug report you mention in this post [0]. Could you please give a link?

[0] http://mail.openjdk.java.net/pipermail/awt-dev/2014-September/008488.html
Comment by Chauncey Goss (cgoss) - Tuesday, 16 September 2014, 13:38 GMT
I got an email from Oracle saying the bug was under review with that identifier, but I think someone over there probably has to click "ok" on something before they actually publish it. The bug report was just a copy of my initial email to the list, so there's nothing too surprising in there.
Comment by Guillaume ALAUX (galaux) - Wednesday, 17 September 2014, 13:27 GMT
In the meantime, I pushed version 8.u20-3 to testing.

grimpirate, cgoss: could you please test and report back here?
Comment by Chauncey Goss (cgoss) - Wednesday, 17 September 2014, 15:42 GMT
I think you're missing the 003_nonreparenting-wm.patch file. (Also, the gcc 4.9.0 patch shouldn't be necessary on gcc 4.9.1+)
Comment by Guillaume ALAUX (galaux) - Wednesday, 17 September 2014, 16:45 GMT
> I think you're missing the 003_nonreparenting-wm.patch file
-3 is built with it so you can still test it.

Thanks for the gcc hint.
Comment by Chauncey Goss (cgoss) - Wednesday, 17 September 2014, 18:22 GMT
I can confirm that the -3 revision works with dwm
Comment by Chauncey Goss (cgoss) - Friday, 19 September 2014, 21:25 GMT
Sorry to bump, but are either of you planning to continue the upstreaming process?
Comment by Fernando Sanchez (grimpirate) - Friday, 19 September 2014, 22:36 GMT
@galaux: Tested it and I too confirm that the revision worked with dwm.

@cgoss: I never had the intention of moving it upstream. The way they handle window managers to me seems to indicate that they use specific fixes for certain things. The patch I suggested does not support this paradigm, rather it reassigns the default parameters of LG3D generically as a "fix" for other tiling managers (which the code also does for NO_WM). That may not suffice in all cases. There is a notable difference from the jdk7 patch in that I chose to neglect the check for _NET or WIN because I thought it superfluous to check for this if the user/admin has already specified a non-reparenting window manager. Likely, I imagine that for the JDK folk, putting an editable environment variable for every little thing that might come up is not efficient. If all these window managers had the same insets/offsets/etc. then it might make more sense, but I'm not convinced they would include the patch if it it was already shown (and fairly popularized in openjdk7) that they didn't put it in openjdk8. I mentioned it here because I had grown used to it in openjdk7 and then uncovered it was in fact vendor-specific.

Loading...