From Sergey.Bylokhov at oracle.com Tue Jul 2 00:19:20 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 1 Jul 2019 17:19:20 -0700 Subject: [13] Review Request: 8225372 accessibility errors in tables in java.desktop files In-Reply-To: <00becf2b-b1e4-7937-4671-f829490ea200@oracle.com> References: <7a29ed58-906a-7048-07e1-04e9fdbc0bca@oracle.com> <00becf2b-b1e4-7937-4671-f829490ea200@oracle.com> Message-ID: Hi, Alexey. Thank you for review, the new version is here: Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.01 Doc: http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/module-summary.html See comments inline: On 14/06/2019 09:19, Alexey Ivanov wrote: > *GridBagLayout.java* > Does it make sense to use nested lists for valid values> It could make the presentation clearer rather than a paragraph followed by a list. We can: http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/GridBagLayout.html But I am not sure that it looks better due to the current default styles for nested
  • > The value ?center? is invalid for ?float? property in CSS, so it must be removed, including style attribute of element. I dropped all incorrect "float" attributes whenever possible. > *DesktopProperties.html* > I'm still unsure we should suppress rendering in bold, should we not? I changed the code to use default style as-is. > *Modality.html* > The table in examples could be replaced by a series of
      element with , followed by

      > Then goes
      . > I would probably add titles to the examples to make the distinction between the examples clearer. If each example is preceded by

      Example #

      , then style="clear: left" can be applied to it. > If this sounds reasonable, I can file a new bug to handle this. This way we'll get rid of presentation table. I think that the final result will be quite similar to the existing table? We can change the order of columns, so the a11y tool will read the text of the image(Example 1/Example 2/etc) and then the current description of the example. http://cr.openjdk.java.net/~serb/8225372/docs.01/api/java.desktop/java/awt/doc-files/Modality.html > > *NumericShaper.html* > The table has only one row group, so you have to add row groups: > elements create the row group that will be associated with ?Arabic? row group header. fixed. > *gif_metadata.html* > As you mention, some tables don't have meaningful row header. And it's not required in this case. > Adding the additional index column which does not make the table clearer does not make any sense to me. We already have column headers (yes, scope="col" should be added), and that resolves the missing header problem, doesn't it? > > See ?Tables with one header? article in Web Accessibility Tutorial: > https://www.w3.org/WAI/tutorials/tables/one-header/#table-with-ambiguous-data The current document checker requires both row and columns headers. We can fix the checker, but I do not see an issue with "index", these tables look like a grid which contains enumerated data. > *tiff_metadata.html* > Compression type headers should be in (lines 516?518) and other table content in > > In case of Mapping the Standard Metadata Format to TIFF Native Image Metadata, the first column could probably be the row header. I'm not sure. I added index to all these tables, otherwise, the tables looks non-unified. > > The extra row in this table, lines 869?872 could be removed completely. Fixed. > > *BoxLayout.java* > It would suggest more semantic mark-up for "Example" (lines 39?44): >

      Example: >

      > instead of changing only text presentation by ?font-weight: bold? property on

      element. > This is applicable to other similar cases. > [1] has new semantics since HTML5; [2] can also be used, however, in this case this snipped does not represent anything of certain importance.> > style attribute on element has invalid value of ?bottom? for property ?float?, so it must be removed. Fixed. > > [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/b > [2] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/strong > > > *componentProperties.html* > The same as DesktopProperties.html: should we suppress rendering in bold? > > JFileChooser, JInternalFrame, JInternalFrameTitlePane, JProgressBar, JSlider, JTabbedPane, Text Properties tables lack element around the header row. Because of the style applied, the header row is not rendered in bold. So suppressing bold rendering proved to be useful. > > On 12/06/2019 06:29, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8225372 >> Fix: http://cr.openjdk.java.net/~serb/8225372/webrev.00 >> Doc: http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/module-summary.html >> >> In the fix, some(most) of the issues which were reported by the accessibility checker were fixed. >> >> Changes description: >> >> ?- In the simplest case, the "scope=col/row" attribute was added to the tables: >> http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html.sdiff.html >> >> ?- The tables which are used for a layout were replaced by the
      .(In fact, this is just emulation of
      ): >> http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/swing/JScrollPane.java.sdiff.html >> >> ?- Some tables do not have the meaningful cell to be row header, so I have added an additional column "index" and use it cells as row header: >> http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html.sdiff.html >> >> ?- In one place I have added a special role to the table "role=presentation" because the table was used just for layout and its content can be read without information about this table: >> http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/java/awt/doc-files/Modality.html#Examples >> >> ?- In some cases I have dropped the table, and replace it by the list of elements: >> http://cr.openjdk.java.net/~serb/8225372/webrev.00/src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java.sdiff.html >> ???? New: http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/print/attribute/standard/Finishings.html >> ???? Old: https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/print/attribute/standard/Finishings.html >> >> Note that I cannot fix two reported issues: >> ?? Take a look to the "Common dialog" and "HTML Content of example above" on the links below: >> http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/swing/JOptionPane.html >> http://cr.openjdk.java.net/~serb/8225372/docs/api/java.desktop/javax/swing/text/html/HTMLDocument.html >> >> I tried to mark these tables as "role=presentation" or "aria-hidden=true", but it does not work because Javadoc tool generates HTML4 and these attributes are supported by the HTML5. >> -- Best regards, Sergey. From philip.race at oracle.com Fri Jul 5 18:12:12 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 05 Jul 2019 11:12:12 -0700 Subject: [OpenJDK 2D-Dev] JDK-8226654 Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK libraries" In-Reply-To: <0b47babe-1869-4372-6150-4826230ff566@oracle.com> References: <0b47babe-1869-4372-6150-4826230ff566@oracle.com> Message-ID: <5D1F92FC.40507@oracle.com> Looks ok to me too, but I think awt-dev (added) is the most appropriate email list since this is AWT Robot code. -phil. On 7/5/19, 1:51 AM, Prasanta Sadhukhan wrote: > > looks ok to me but the review should have been done in swing-dev alias. > > Regards > Prasanta > On 04-Jul-19 6:38 PM, Alexey Ushakov wrote: >> Hello, >> >> Here is a fix of the regression caused by JDK-8225118. Please, have a >> look. >> I?ve moved resolving gdk_window_get_scale_factor symbol under gtk >> version check as was suggested in the comments. >> >> Webrev: http://cr.openjdk.java.net/~avu/JDK-8226654/webrev.00 >> >> >> Best Regards, >> Alexey > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sun Jul 7 23:51:05 2019 From: philip.race at oracle.com (Philip Race) Date: Sun, 07 Jul 2019 16:51:05 -0700 Subject: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr. In-Reply-To: References: Message-ID: <5D228569.1000909@oracle.com> 1) 646 * If the invoking thread is interrupted while waiting, then its interrupt 647 * status will be set and this method returns immediately. This is OK except for sounding a bit odd, in that if a thread is interrupted why do you need to set it again ? Rather explain the implementation I'd phrase this as 646 * If the invoking thread is interrupted while waiting, then it will 647 * return immediately with the interrupt status set. 2) However I am still worried by this change of behaviour. We have a sequence of Robot.delay() calls in a typical test and if one of them gets interrupted, then the next one will also return immediately .. since the status is already but right before it returns it will again reset the interrupt status and so the same happens to the next one :- Consider this :- public class I { public static void main(String[] args) { Thread.currentThread().interrupt(); try { Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } } } java I java.lang.InterruptedException: sleep interrupted at java.lang.Thread.sleep(Native Method) at I.main(I.java:5) Are we to update all Robot tests to clear the interrupt status before calling delay ? Or should delay clear the status on entry to delay ? Or something else ? -phil. On 4/14/19, 8:24 PM, Sergey Bylokhov wrote: > Hello, > > Here is another proposal: > Bug: https://bugs.openjdk.java.net/browse/JDK-8210231 > Fix: http://cr.openjdk.java.net/~serb/8210231/webrev.01/ > > 1. This version describes what happens if the thread will be > interrupted while waiting. > 2. The reference to the "Thread.sleep()" was removed, because it is > not a part of the spec for the current method. > 3. "synchronized" keyword was removed, because of this bug: "if two > threads call delay(1000) at around the same time then one of them will > be a delay for 2000ms". > >> Hello. >> Please review the fix for jdk12. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210231 >> Webrev: http://cr.openjdk.java.net/~serb/8210231/webrev.00 >> >> The Robot.delay() is a simple wrapper on top of Thread.sleep(), which >> ignores the InterruptedException. But in case of InterruptedException >> it prints the stack trace, which is unspecified behavior. >> >> In the fix the "printStackTrace()" was removed, and the interrupted >> state of the thread is restored. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Tue Jul 9 14:21:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 9 Jul 2019 14:21:24 +0000 Subject: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file Message-ID: Hello, please review this small change that enhances logging a bit . When reading the fcinfo - file (fontconfig info file) we currently have very limited logging. This should be enhanced to get more info in case of errors , and to have at least some info in the log when -Dsun.java2d.debugfonts=true is set. Currently the logging writes a ton of info about lots of non-existant files , but misses the fcinfo file . Example output , we run here with -Dsun.java2d.debugfonts=true set : (with my added "successfully parsed the fontconfig file at ..." from the patch ) ... INFO: Creating standard Font Configuration Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.Linux.4.12.14-25.25-default.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.Linux.4.12.14-25.25-default.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.Linux.4.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.Linux.4.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.Linux.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.Linux.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.4.12.14-25.25-default.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.4.12.14-25.25-default.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.4.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.4.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for text fontconfig file : /images/jdk/lib/fontconfig.properties Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.bfc Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findFontConfigFile INFO: Did not find a fontconfig file. Jul 09, 2019 3:36:59 PM sun.font.FcFontConfiguration readFcInfo INFO: successfully parsed the fontconfig file at /myhomedir/user/.java/fonts/14.0.0.1-internal/fcinfo-1-thismachine-Linux-4.12.14-25.25-default-en-US.properties Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227441 http://cr.openjdk.java.net/~mbaesken/webrevs/8227441.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Jul 9 15:25:31 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 09 Jul 2019 08:25:31 -0700 Subject: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file In-Reply-To: References: Message-ID: <5D24B1EB.10201@oracle.com> Hi, Before I, or anyone else, starts to look at or comment on this, can you instead post to the correct list : 2d-dev. -phil. On 7/9/19, 7:21 AM, Baesken, Matthias wrote: > > Hello, please review this small change that enhances logging a bit . > > When reading the fcinfo - file (fontconfig info file) we currently > have very limited logging. > This should be enhanced to get more info in case of errors , and to > have at least some info in the log when -Dsun.java2d.debugfonts=true > is set. > > Currently the logging writes a ton of info about lots of > non-existant files , but misses the fcinfo file . > > Example output , we run here with -Dsun.java2d.debugfonts=true set > : (with my added "successfully parsed the fontconfig file at > ..." from the patch ) > > ... > > INFO: Creating standard Font Configuration > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.Linux.4.12.14-25.25-default.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /images/jdk/lib/fontconfig.Linux.4.12.14-25.25-default.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.Linux.4.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /images/jdk/lib/fontconfig.Linux.4.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.Linux.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /images/jdk/lib/fontconfig.Linux.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.4.12.14-25.25-default.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /images/jdk/lib/fontconfig.4.12.14-25.25-default.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.4.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : > /images/jdk/lib/fontconfig.4.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for text fontconfig file : > /images/jdk/lib/fontconfig.properties > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findImpl > > INFO: Looking for binary fontconfig file : /images/jdk/lib/fontconfig.bfc > > Jul 09, 2019 3:36:59 PM sun.awt.FontConfiguration findFontConfigFile > > INFO: Did not find a fontconfig file. > > Jul 09, 2019 3:36:59 PM sun.font.FcFontConfiguration readFcInfo > > INFO: successfully parsed the fontconfig file at > /myhomedir/user/.java/fonts/14.0.0.1-internal/fcinfo-1-thismachine-Linux-4.12.14-25.25-default-en-US.properties > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8227441 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8227441.0/ > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Jul 9 18:01:06 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 9 Jul 2019 11:01:06 -0700 Subject: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr. In-Reply-To: <5D228569.1000909@oracle.com> References: <5D228569.1000909@oracle.com> Message-ID: On 07/07/2019 16:51, Philip Race wrote: 2) However I am still worried by this change of behaviour. We have a sequence of Robot.delay() calls in a typical test and if one of them gets interrupted, then the next one will also return immediately .. since the status is already but right before it returns it will again reset the interrupt status and so the same happens to the next one : Right, this is what I proposed if the thread was interrupted then all subsequent calls to delay will be skipped(before this fix only the first delay was skipped). So the test will ends immediately, or by some exception if it uses the methods like Thread.sleep(), EventQueue.invokeAndWait() etc. - Consider this :- public class I { public static void main(String[] args) { Thread.currentThread().interrupt(); try { Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } } } > > java I > java.lang.InterruptedException: sleep interrupted > ??? at java.lang.Thread.sleep(Native Method) > ??? at I.main(I.java:5) > > Are we to update all Robot tests to clear the interrupt status before calling delay ? > > Or should delay clear the status on entry to delay ? > > Or something else ? My proposal is do not change any tests or code which use delay(), I guess it is not necessary. -- Best regards, Sergey. From philip.race at oracle.com Tue Jul 9 20:54:05 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 9 Jul 2019 13:54:05 -0700 Subject: [12] Review Request: 8210231 Robot.delay() catches InterruptedException and prints stacktrace to stderr. In-Reply-To: References: <5D228569.1000909@oracle.com> Message-ID: <2479b503-1fe4-8e05-104d-55d464c4bbbf@oracle.com> So in all likelihood the executing thread is going to bail, but Robot isn't just used in tests, applications can use it if they want. I don't know what in practice is likely to cause this exception (other than someone deliberately interrupting the thread) and so I find it hard to predict what unwanted consequences will manifest. A test harness timing out a test may be the most likely but in that case the test already will be called failed, does this make that failure "better" ? Perhaps but is this change going to help make tests more reliable? There has to be a positive benefit that makes it worth the compatibility risks. The CSR for this bug needs to call out all of the potential downsides. -phil. On 7/9/19 11:01 AM, Sergey Bylokhov wrote: > On 07/07/2019 16:51, Philip Race wrote: > 2) However I am still worried by this change of behaviour. We have a > sequence of Robot.delay() calls in a typical test and if one of them > gets interrupted, then the next one will also return immediately .. > since the status is already but right before it returns it will again > reset the interrupt status and so the same happens to the next one : > > Right, this is what I proposed if the thread was interrupted then all > subsequent calls to delay will be skipped(before this fix only the > first delay was skipped). So the test will ends immediately, or by > some exception if it uses the methods like Thread.sleep(), > EventQueue.invokeAndWait() etc. > > - Consider this :- public class I { public static void main(String[] > args) { Thread.currentThread().interrupt(); try { Thread.sleep(5000); > } catch (InterruptedException e) { e.printStackTrace(); } } } >> >> java I >> java.lang.InterruptedException: sleep interrupted >> ???? at java.lang.Thread.sleep(Native Method) >> ???? at I.main(I.java:5) >> >> Are we to update all Robot tests to clear the interrupt status before >> calling delay ? >> >> Or should delay clear the status on entry to delay ? >> >> Or something else ? > My proposal is do not change any tests or code which use delay(), I > guess it is not necessary. > From Roger.Riggs at oracle.com Thu Jul 11 14:10:59 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 11 Jul 2019 10:10:59 -0400 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> Message-ID: <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> Hi Claes, JavaLangAccess.java: 316: Add @param tag System.java:? 2282, 2287 Runtime.loadLibrary0 makes a second check for a security manager. Is there any potential gain by calling ClassLoader.loadLibrary directly? None of the internal uses would have a separatorChar. I expect most of the files need a copyright update. The script in /make/scripts/update_copyright_year.sh should do the work for modified files. Roger On 7/11/19 9:43 AM, Claes Redestad wrote: > Hi, > > by adding a method to load libraries with privileges to JavaLangAccess, > we can simplify a slew of places where we are currently implementing > adhoc privileged actions. This is a tiny but measurable gain on a range > of startup tests. > > Webrev:? http://cr.openjdk.java.net/~redestad/8227587/open.00 > Bug:???? https://bugs.openjdk.java.net/browse/JDK-8227587 > Testing: tier1-3 > > Thanks! > > /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From Roger.Riggs at oracle.com Fri Jul 12 13:27:51 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 12 Jul 2019 09:27:51 -0400 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> Message-ID: <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Hi Claes, Looks fine. Thanks for the updates, Roger On 7/11/19 10:39 AM, Claes Redestad wrote: > Hi Roger, > > On 2019-07-11 16:10, Roger Riggs wrote: >> Hi Claes, >> >> JavaLangAccess.java: >> 316: Add @param tag > > done. > >> >> System.java:? 2282, 2287 >> Runtime.loadLibrary0 makes a second check for a security manager. >> Is there any potential gain by calling ClassLoader.loadLibrary directly? >> None of the internal uses would have a separatorChar. > > Most of the gain comes from not having to load one-off PA classes or > lambdas, but of course avoiding the indexOf and a few indirections are > marginally helpful to startup. We should at least assert that the > library names are sane, though. > >> >> I expect most of the files need a copyright update. >> The script in /make/scripts/update_copyright_year.sh should do >> the work for modified files. > > Fixed copyrights and updated in place: > http://cr.openjdk.java.net/~redestad/8227587/open.00 > > Thanks! > > /Claes -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 12 14:14:55 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Jul 2019 07:14:55 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Message-ID: <5D2895DF.8070001@oracle.com> Hi, Regarding all the touches on the desktop module 1) awt-dev isn't the only list, you should have included swing-dev and 2d-dev at least 2) I am wondering what client testing you propose to do to verify this ? 3) I've spent spare time over a number of months trying to decrease unnecessary coupling between desktop and base modules. This seems to create additional technical debt there with minimal benefit, so in other words I'd much prefer that either you don't do this at all or the many, many, uses in the desktop module that are the heaviest Java->native code user in the JDK are dealt with entirely separately (separate bug) and at a minimum there is one place in the desktop module that they all call to and perhaps only then *through*. So do not push this. -phil. On 7/12/19, 6:27 AM, Roger Riggs wrote: > Hi Claes, > > Looks fine. > > Thanks for the updates, Roger > > > On 7/11/19 10:39 AM, Claes Redestad wrote: >> Hi Roger, >> >> On 2019-07-11 16:10, Roger Riggs wrote: >>> Hi Claes, >>> >>> JavaLangAccess.java: >>> 316: Add @param tag >> >> done. >> >>> >>> System.java: 2282, 2287 >>> Runtime.loadLibrary0 makes a second check for a security manager. >>> Is there any potential gain by calling ClassLoader.loadLibrary >>> directly? >>> None of the internal uses would have a separatorChar. >> >> Most of the gain comes from not having to load one-off PA classes or >> lambdas, but of course avoiding the indexOf and a few indirections are >> marginally helpful to startup. We should at least assert that the >> library names are sane, though. >> >>> >>> I expect most of the files need a copyright update. >>> The script in /make/scripts/update_copyright_year.sh should do >>> the work for modified files. >> >> Fixed copyrights and updated in place: >> http://cr.openjdk.java.net/~redestad/8227587/open.00 >> >> Thanks! >> >> /Claes > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at oracle.com Fri Jul 12 15:25:05 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Jul 2019 08:25:05 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> Message-ID: <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> Claes, Thanks for exploring this.? I would like to see if we can avoid introducing an internal @CS method (keep @CSM only for public APIs will help security analysis). There are other alternatives to improve the footprint performance. One idea is java.base and java.desktop each has its own utility method to load library.? No change is needed for java.net since only one loadLibrary call. Another idea is to add BootLoader.loadLibrary that skips the security permission overhead and only for boot loader use.? It would require refactoring. I think java.base and java.desktop having its own utility method is a simpler solution. Mandy On 7/12/19 7:55 AM, Claes Redestad wrote: > Hi, > > I'm dropping the java.desktop changes, and Mandy has asked me to explore > options that does not add a new @CallerSensitive entry point, even to a > strongly encapsulated API like JavaLangAccess > > Easiest of these is to explicitly provide the class context we're > calling from - with proper assertions. This is marginally more > performant due avoiding the Reflection.getCallerClass, but slightly less > convenient. > > http://cr.openjdk.java.net/~redestad/8227587/open.01/ > > /Claes > > On 2019-07-12 15:27, Roger Riggs wrote: >> Hi Claes, >> >> Looks fine. >> >> Thanks for the updates, Roger >> >> >> On 7/11/19 10:39 AM, Claes Redestad wrote: >>> Hi Roger, >>> >>> On 2019-07-11 16:10, Roger Riggs wrote: >>>> Hi Claes, >>>> >>>> JavaLangAccess.java: >>>> 316: Add @param tag >>> >>> done. >>> >>>> >>>> System.java:? 2282, 2287 >>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>> directly? >>>> None of the internal uses would have a separatorChar. >>> >>> Most of the gain comes from not having to load one-off PA classes or >>> lambdas, but of course avoiding the indexOf and a few indirections are >>> marginally helpful to startup. We should at least assert that the >>> library names are sane, though. >>> >>>> >>>> I expect most of the files need a copyright update. >>>> The script in /make/scripts/update_copyright_year.sh should >>>> do the work for modified files. >>> >>> Fixed copyrights and updated in place: >>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>> >>> Thanks! >>> >>> /Claes >> From mandy.chung at oracle.com Fri Jul 12 18:03:20 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Jul 2019 11:03:20 -0700 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <15a57e3c-065c-55c5-b6af-0644ed8f775b@oracle.com> Message-ID: Just to recap what we discussed offline: We could introduce BootLoader::loadLibrary to load a system native library for boot loader.? sys_path and systemNativeLibraries in ClassLoader implementation are solely for boot loader and it seems cleaner for BootLoader to handle loading of system native libraries where it can be optimized for boot loader.? This would require some refactoring. One possible solution is to add a shared secret to simply call package-private ClassLoader::loadLibrary(Class fromClass, String name) method and have BootLoader::loadLibrary to check if SM is present and wrap the call with doPriv; otherwise, just call the shared secret loadLibrary method. Then we can investigate in the future to refactor the native library loading implementation to jdk.internal.loader. what do you think? Mandy On 7/12/19 8:25 AM, Mandy Chung wrote: > Claes, > > Thanks for exploring this.? I would like to see if we can avoid > introducing > an internal @CS method (keep @CSM only for public APIs will help security > analysis). > > There are other alternatives to improve the footprint performance. > > One idea is java.base and java.desktop each has its own utility method > to load library.? No change is needed for java.net since only one > loadLibrary > call. > > Another idea is to add BootLoader.loadLibrary that skips the security > permission overhead and only for boot loader use.? It would require > refactoring. > > I think java.base and java.desktop having its own utility method is > a simpler solution. > > Mandy > > On 7/12/19 7:55 AM, Claes Redestad wrote: >> Hi, >> >> I'm dropping the java.desktop changes, and Mandy has asked me to explore >> options that does not add a new @CallerSensitive entry point, even to a >> strongly encapsulated API like JavaLangAccess >> >> Easiest of these is to explicitly provide the class context we're >> calling from - with proper assertions. This is marginally more >> performant due avoiding the Reflection.getCallerClass, but slightly less >> convenient. >> >> http://cr.openjdk.java.net/~redestad/8227587/open.01/ >> >> /Claes >> >> On 2019-07-12 15:27, Roger Riggs wrote: >>> Hi Claes, >>> >>> Looks fine. >>> >>> Thanks for the updates, Roger >>> >>> >>> On 7/11/19 10:39 AM, Claes Redestad wrote: >>>> Hi Roger, >>>> >>>> On 2019-07-11 16:10, Roger Riggs wrote: >>>>> Hi Claes, >>>>> >>>>> JavaLangAccess.java: >>>>> 316: Add @param tag >>>> >>>> done. >>>> >>>>> >>>>> System.java:? 2282, 2287 >>>>> Runtime.loadLibrary0 makes a second check for a security manager. >>>>> Is there any potential gain by calling ClassLoader.loadLibrary >>>>> directly? >>>>> None of the internal uses would have a separatorChar. >>>> >>>> Most of the gain comes from not having to load one-off PA classes or >>>> lambdas, but of course avoiding the indexOf and a few indirections are >>>> marginally helpful to startup. We should at least assert that the >>>> library names are sane, though. >>>> >>>>> >>>>> I expect most of the files need a copyright update. >>>>> The script in /make/scripts/update_copyright_year.sh should >>>>> do the work for modified files. >>>> >>>> Fixed copyrights and updated in place: >>>> http://cr.openjdk.java.net/~redestad/8227587/open.00 >>>> >>>> Thanks! >>>> >>>> /Claes >>> > From matthias.baesken at sap.com Tue Jul 16 15:04:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Jul 2019 15:04:19 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX Message-ID: Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Wed Jul 17 07:39:47 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 17 Jul 2019 07:39:47 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs ; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jul 17 07:55:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 17 Jul 2019 07:55:38 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Thanks ! * How far are we then from enabling "warnings as errors" on AIX? :P * I count in the opt/product jdk/jdk AIX build currently 60 remaining matches of compiler warnings . Plus additionally a number of those (probably linker warnings ?) : 1500-029: (W) WARNING: subprogram ... could not be inline Guess we have to suppress / ignore at least most of the linker inlining warnings (we ignore them for a decade IMHO). >From the 60 remaining compiler warnings I mentioned are ~ 30 of type Wformat : warning: format specifies type 'int *' but the argument has type 'int' [-Wformat] warning: format specifies type 'unsigned long long' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat] Guess those can the easily fixed (and should be fixed). Regards, Matthias From: Langer, Christoph Sent: Mittwoch, 17. Juli 2019 09:40 To: Baesken, Matthias ; Java Core Libs ; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev > On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Thu Jul 18 13:01:25 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 18 Jul 2019 13:01:25 +0000 Subject: RFR [XS] : 8228368: avoid incompatible pointer to integer conversion initializing gint in gtk2_interface Message-ID: Hello, please review this very small fix . Currently we assign NULL two times in gtk2_interface.c to gint values. This leads to warning like this (xlc16 / clang) : /jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:2454:10: warning: incompatible pointer to integer conversion initializing 'gint' (aka 'int') with an expression of type 'void *' [-Wint-conversion] gint intval = NULL; ^ ~~~~ /jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:2461:10: warning: incompatible pointer to integer conversion initializing 'gint' (aka 'int') with an expression of type 'void *' [-Wint-conversion] gint intval = NULL; ^ ~~~~ Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8228368 http://cr.openjdk.java.net/~mbaesken/webrevs/8228368.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Jul 18 14:25:50 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 18 Jul 2019 07:25:50 -0700 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8228368: avoid incompatible pointer to integer conversion initializing gint in gtk2_interface In-Reply-To: References: Message-ID: <5D30816E.2020208@oracle.com> Looks OK. -phil. On 7/18/19, 6:01 AM, Baesken, Matthias wrote: > > Hello, please review this very small fix . > > Currently we assign NULL two times in gtk2_interface.c to gint values. > This leads to warning like this (xlc16 / clang) : > > /jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:2454:10: > warning: incompatible pointer to integer conversion initializing > 'gint' (aka 'int') with an expression of type 'void *' [-Wint-conversion] > gint intval = NULL; > ^ ~~~~ > /jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:2461:10: > warning: incompatible pointer to integer conversion initializing > 'gint' (aka 'int') with an expression of type 'void *' [-Wint-conversion] > gint intval = NULL; > ^ ~~~~ > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8228368 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228368.0/ > > > Thanks, Matthias > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Jul 19 07:50:03 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Jul 2019 07:50:03 +0000 Subject: RFR : 8227737: avoid implicit-function-declaration on AIX In-Reply-To: References: Message-ID: Thanks for the additional review ! Best regards, Matthias From: Lindenmaier, Goetz Sent: Freitag, 19. Juli 2019 09:33 To: Baesken, Matthias ; Schmidt, Lutz ; Doerr, Martin Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, This looks good, thanks for doing this. Best regards, Goetz. From: Langer, Christoph Sent: Mittwoch, 17. Juli 2019 09:40 To: Baesken, Matthias >; Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: RE: RFR : 8227737: avoid implicit-function-declaration on AIX Hi Matthias, looks good, thanks for doing this. How far are we then from enabling "warnings as errors" on AIX? :P Best regards Christoph From: awt-dev > On Behalf Of Baesken, Matthias Sent: Dienstag, 16. Juli 2019 17:04 To: Java Core Libs >; nio-dev at openjdk.java.net; net-dev at openjdk.java.net; awt-dev at openjdk.java.net Cc: 'ppc-aix-port-dev at openjdk.java.net' > Subject: [CAUTION] RFR : 8227737: avoid implicit-function-declaration on AIX Hello, please review the following AIX related change . It fixes a number of missing inclusions leading to implicit-function-declaration warnings when compiling with the recent xlc16 /xlclang . At various places in the native C coding in jdk, we miss header inclusions on AIX. This leads to warnings like : /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: warning: implicitly declaring library function 'snprintf' with type 'int (char *, unsigned long, const char *, ...)' [-Wimplicit-function-declaration] snprintf(aix_fd_dir, 32, "/proc/%d/fd", getpid()); ^ /nightly/jdk/src/java.base/unix/native/libjava/childproc.c:99:5: note: include the header or explicitly provide a declaration for 'snprintf' or /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: warning: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Wimplicit-function-declaration] memset((void *)info, 0, sizeof(Dl_info)); /nightly/jdk/src/java.base/aix/native/libjli/java_md_aix.c:38:5: note: include the header or explicitly provide a declaration for 'memset' Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8227737 http://cr.openjdk.java.net/~mbaesken/webrevs/8227737.0/ Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Jul 19 12:01:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 19 Jul 2019 12:01:51 +0000 Subject: awt_Robot.c : format string contains '\0' within the string body Message-ID: Hello, is there a special reason to put a '\0' at the end of the "atom_name" - parameter of the XInternAtom call in isXCompositeDisplay ? jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c : static jboolean isXCompositeDisplay(Display *display, int screenNumber) { char NET_WM_CM_Sn[25]; snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Atom managerSelection = XInternAtom(display, NET_WM_CM_Sn, 0); I think on UNIX the snprintf implementations are conforming and zero-terminate ( exception was VS before VS2015 but this is unix/native code ). Reason why I ask is this warning we have in our AIX xlc16/xlclang build : /jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:153:65: warning: format string contains '\0' within the string body [-Wformat] snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Fri Jul 19 13:57:49 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 19 Jul 2019 22:57:49 +0900 Subject: 8227919: 8213232 causes crashes on solaris sparc64 Message-ID: Hello. I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] Please follow the steps: 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC 2. Run xim_root on desktop 3. Move input focus to XIM demo window 4. Press Ctrl key and Press Right mouse button Please put the output into JDK-8227919 [1] or post it into mailing list. I really appreciate if you are using XIM like IIIMF. [1] https://bugs.openjdk.java.net/browse/JDK-8227919 [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c Thanks, Ichiroh Takiguchi From vkempik at azul.com Fri Jul 19 14:29:14 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 19 Jul 2019 14:29:14 +0000 Subject: 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: Message-ID: Hello I?m probably missing something about XIM on X side here, using ssh -X from ubuntu(with Xserver) to solaris11 sparc64 machine the output is fevent = 0x3 topwindow = 0x3800001, window = 0x3800002 ClientMessage is received WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 XSetInputFocus() is called FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) FocusIn: window=0x3800002(Internal Window) XSetICFocus FocusOut: window=0x3800002(Internal Window) XUnsetICFocus FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) ClientMessage is received WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 XSetInputFocus() is called ButtonPress: [1]w=0x0 [2]w=0x0 [1]state=0x0 [2]state=0x0 State: Unknown FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) FocusIn: window=0x3800002(Internal Window) I also had to press left button, not right one. I think when you initialy created 8213232 you were targeting linux ppc64 BE system in your patch and simply forgot about another 64-bit BE system - solaris sparc64 I would propose this fix for 8227919 --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c @@ -1671,7 +1671,7 @@ { X11InputMethodData *pX11IMData = NULL; char * ret = NULL; -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) // XIMPreeditState value which is used for XGetICValues must be 32bit on BigEndian XOrg's xlib unsigned int state = XIMPreeditUnKnown; #else Such change already allowed to pass our internal tests on solaris sparc64 if you think it?s ok then let me take over and finish with 8227919 Thanks, Vladimir 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi > ???????(?): Hello. I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] Please follow the steps: 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC 2. Run xim_root on desktop 3. Move input focus to XIM demo window 4. Press Ctrl key and Press Right mouse button Please put the output into JDK-8227919 [1] or post it into mailing list. I really appreciate if you are using XIM like IIIMF. [1] https://bugs.openjdk.java.net/browse/JDK-8227919 [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c Thanks, Ichiroh Takiguchi -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Fri Jul 19 21:05:52 2019 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 19 Jul 2019 21:05:52 +0000 (UTC) Subject: awt_Robot.c : format string contains '\0' within the string body Message-ID: <6995d056-c026-4925-839c-f1829deeacfd@default> Hi, Matthias. I think it is unneeded and can be removed. ----- matthias.baesken at sap.com wrote: > > > Hello, is there a special reason to put a '\0' at the end of the ?atom_name? - parameter of the XInternAtom call in isXCompositeDisplay ? jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c : static jboolean isXCompositeDisplay(Display *display, int screenNumber) { char NET_WM_CM_Sn[25]; snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Atom managerSelection = XInternAtom(display, NET_WM_CM_Sn, 0); I think on UNIX the snprintf implementations are conforming and zero-terminate ( exception was VS before VS2015 but this is unix/native code ). Reason why I ask is this warning we have in our AIX xlc16/xlclang build : /jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:153:65: warning: format string contains '\0' within the string body [-Wformat] snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualgl.org Sun Jul 21 00:03:02 2019 From: drc at virtualgl.org (DRC) Date: Sat, 20 Jul 2019 19:03:02 -0500 Subject: Replacement for com.apple.eawt.FullScreen* Message-ID: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> I've been beating my head against the wall about this for quite a while, but I can't figure out how to programmatically toggle "Lion Full-Screen Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the deprecated com.apple.eawt.FullScreen* classes, which are problematic at best when including a custom JRE in my app using jlink. I looked at the OpenJDK 12 source, and it doesn't appear that the native code to do this toggling has any other touch points besides the com.apple.eawt.FullScreen* classes. What am I missing? The problem is that, because I'm writing a remote desktop client, I have to provide users with a way to switch in and out of full-screen mode with a keystroke and menu option, and I also have to be able to detect when the user clicks the full-screen button in the window's titlebar. I don't know how to do that without invoking com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and com.apple.eawt.Application.requestToggleFullScreen(). Any advice is appreciated. DRC From matthias.baesken at sap.com Mon Jul 22 08:26:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 22 Jul 2019 08:26:24 +0000 Subject: RFR: [XXS] 8228468: awt_Robot.c : format string contains 0 within the string body - was : RE: awt_Robot.c : format string contains '\0' within the string body Message-ID: Hi Sergey, thanks for the reply ! I created a bug + webrev . Please review . https://bugs.openjdk.java.net/browse/JDK-8228468 http://cr.openjdk.java.net/~mbaesken/webrevs/8228468.0/ Best regards, Matthias From: Sergey Bylokhov Sent: Freitag, 19. Juli 2019 23:06 To: Baesken, Matthias Cc: awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net Subject: Re: awt_Robot.c : format string contains '\0' within the string body Hi, Matthias. I think it is unneeded and can be removed. ----- matthias.baesken at sap.com wrote: > > > Hello, is there a special reason to put a '\0' at the end of the ?atom_name? - parameter of the XInternAtom call in isXCompositeDisplay ? jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c : static jboolean isXCompositeDisplay(Display *display, int screenNumber) { char NET_WM_CM_Sn[25]; snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Atom managerSelection = XInternAtom(display, NET_WM_CM_Sn, 0); I think on UNIX the snprintf implementations are conforming and zero-terminate ( exception was VS before VS2015 but this is unix/native code ). Reason why I ask is this warning we have in our AIX xlc16/xlclang build : /jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:153:65: warning: format string contains '\0' within the string body [-Wformat] snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Mon Jul 22 12:12:44 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 22 Jul 2019 21:12:44 +0900 Subject: 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: Message-ID: Hello Vladimir. I appreciate your reply. I did not expect "[1]w=0x0", it means xim_root could not receive focus window via XIC. I checked ibus XIM server on Linux s390x platform again, it also returned "[1]w=0" ... I was confused. I'd like to add new instruction 5. Run xim_root with XMODIFIERS=@im=local environment variable on desktop, like $ XMODIFIERS=@im=local ./xim_root 6. Move input focus to XIM demo window 7. Press Ctrl key and Press Right mouse button I tested xim_root on Linux s390x platform. $ XMODIFIERS=@im=ibus ./xim_root fevent = 0x3 topwindow = 0x1e00001, window = 0x1e00002 ClientMessage is received WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 XSetInputFocus() is called FocusOut: window=0x1e00002(Internal Window) XUnsetICFocus FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) FocusIn: window=0x1e00002(Internal Window) XSetICFocus KeyPress: ButtonPress: [1]w=0x0 [2]w=0x0 [1]state=0x0 [2]state=0x0 State: Unknown ClientMessage is received I tried it with XMODIFIERS=@im=local $ XMODIFIERS=@im=local ./xim_root fevent = 0 topwindow = 0x2000001, window = 0x2000002 ClientMessage is received WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 XSetInputFocus() is called FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) FocusIn: window=0x2000002(Internal Window) XSetICFocus KeyPress: ButtonPress: [1]w=0x2000002 [2]w=0x2000002 [1]state=0x2 [2]state=0x2 State: IM Off ClientMessage is received I was expected this result. $ XMODIFIERS=@im=kinput2 ./xim_root fevent = 0x3 topwindow = 0x2000001, window = 0x2000002 ClientMessage is received WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 XSetInputFocus() is called FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) FocusIn: window=0x2000002(Internal Window) XSetICFocus KeyPress: ButtonPress: [1]w=0x200000200000000 [2]w=0x2000002 [1]state=0x200000000 [2]state=0x2 State: IM Off ClientMessage is received I'm sorry, it seemed current code did not work on even if Linux s390x platform. Thanks, Ichiroh Takiguchi On 2019-07-19 23:29, Vladimir Kempik wrote: > Hello > I?m probably missing something about XIM on X side here, using ssh > -X from ubuntu(with Xserver) to solaris11 sparc64 machine > > the output is > > fevent = 0x3 > topwindow = 0x3800001, window = 0x3800002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 > XSetInputFocus() is called > FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) > FocusIn: window=0x3800002(Internal Window) > XSetICFocus > FocusOut: window=0x3800002(Internal Window) > XUnsetICFocus > FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 > XSetInputFocus() is called > ButtonPress: > [1]w=0x0 > [2]w=0x0 > [1]state=0x0 > [2]state=0x0 > State: Unknown > FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) > FocusIn: window=0x3800002(Internal Window) > > > I also had to press left button, not right one. > > > I think when you initialy created 8213232 you were targeting linux > ppc64 BE system in your patch and simply forgot about another 64-bit > BE system - solaris sparc64 > > I would propose this fix for 8227919 > > --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > @@ -1671,7 +1671,7 @@ > { > X11InputMethodData *pX11IMData = NULL; > char * ret = NULL; > -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) > +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) > // XIMPreeditState value which is used for XGetICValues must be > 32bit on BigEndian XOrg's xlib > unsigned int state = XIMPreeditUnKnown; > #else > > Such change already allowed to pass our internal tests on solaris > sparc64 > > if you think it?s ok then let me take over and finish with 8227919 > > Thanks, Vladimir > 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi > > > ???????(?): > > Hello. > > I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] > > Please follow the steps: > 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC > 2. Run xim_root on desktop > 3. Move input focus to XIM demo window > 4. Press Ctrl key and Press Right mouse button > > Please put the output into JDK-8227919 [1] or post it into mailing > list. > I really appreciate if you are using XIM like IIIMF. > > [1] https://bugs.openjdk.java.net/browse/JDK-8227919 > [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c > > Thanks, > Ichiroh Takiguchi From vkempik at azul.com Mon Jul 22 14:58:38 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 22 Jul 2019 14:58:38 +0000 Subject: 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: Message-ID: Hello I?m getting Bus Error on startup with XMODIFIERS=@im=local ./xim_root nothing yet in log at that moment. Thanks, Vladimir > 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi ???????(?): > > Hello Vladimir. > > I appreciate your reply. > > I did not expect "[1]w=0x0", it means xim_root could not receive focus window via XIC. > I checked ibus XIM server on Linux s390x platform again, it also returned "[1]w=0" ... > I was confused. > > I'd like to add new instruction > 5. Run xim_root with XMODIFIERS=@im=local environment variable on desktop, like > $ XMODIFIERS=@im=local ./xim_root > 6. Move input focus to XIM demo window > 7. Press Ctrl key and Press Right mouse button > > I tested xim_root on Linux s390x platform. > > $ XMODIFIERS=@im=ibus ./xim_root > fevent = 0x3 > topwindow = 0x1e00001, window = 0x1e00002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 > XSetInputFocus() is called > FocusOut: window=0x1e00002(Internal Window) > XUnsetICFocus > FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) > FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) > FocusIn: window=0x1e00002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x0 > [2]w=0x0 > [1]state=0x0 > [2]state=0x0 > State: Unknown > ClientMessage is received > > I tried it with XMODIFIERS=@im=local > $ XMODIFIERS=@im=local ./xim_root > fevent = 0 > topwindow = 0x2000001, window = 0x2000002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 > XSetInputFocus() is called > FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) > FocusIn: window=0x2000002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x2000002 > [2]w=0x2000002 > [1]state=0x2 > [2]state=0x2 > State: IM Off > ClientMessage is received > > I was expected this result. > $ XMODIFIERS=@im=kinput2 ./xim_root > fevent = 0x3 > topwindow = 0x2000001, window = 0x2000002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 > XSetInputFocus() is called > FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) > FocusIn: window=0x2000002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x200000200000000 > [2]w=0x2000002 > [1]state=0x200000000 > [2]state=0x2 > State: IM Off > ClientMessage is received > > I'm sorry, it seemed current code did not work on even if Linux s390x platform. > > Thanks, > Ichiroh Takiguchi > > On 2019-07-19 23:29, Vladimir Kempik wrote: >> Hello >> I?m probably missing something about XIM on X side here, using ssh >> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >> the output is >> fevent = 0x3 >> topwindow = 0x3800001, window = 0x3800002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >> XSetInputFocus() is called >> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x3800002(Internal Window) >> XSetICFocus >> FocusOut: window=0x3800002(Internal Window) >> XUnsetICFocus >> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >> XSetInputFocus() is called >> ButtonPress: >> [1]w=0x0 >> [2]w=0x0 >> [1]state=0x0 >> [2]state=0x0 >> State: Unknown >> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x3800002(Internal Window) >> I also had to press left button, not right one. >> I think when you initialy created 8213232 you were targeting linux >> ppc64 BE system in your patch and simply forgot about another 64-bit >> BE system - solaris sparc64 >> I would propose this fix for 8227919 >> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> @@ -1671,7 +1671,7 @@ >> { >> X11InputMethodData *pX11IMData = NULL; >> char * ret = NULL; >> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >> // XIMPreeditState value which is used for XGetICValues must be >> 32bit on BigEndian XOrg's xlib >> unsigned int state = XIMPreeditUnKnown; >> #else >> Such change already allowed to pass our internal tests on solaris sparc64 >> if you think it?s ok then let me take over and finish with 8227919 >> Thanks, Vladimir >> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >> >> >> ???????(?): >> Hello. >> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >> Please follow the steps: >> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >> 2. Run xim_root on desktop >> 3. Move input focus to XIM demo window >> 4. Press Ctrl key and Press Right mouse button >> Please put the output into JDK-8227919 [1] or post it into mailing list. >> I really appreciate if you are using XIM like IIIMF. >> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >> Thanks, >> Ichiroh Takiguchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From takiguc at linux.vnet.ibm.com Mon Jul 22 18:08:14 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Tue, 23 Jul 2019 03:08:14 +0900 Subject: 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: Message-ID: Hello Vladimir. I really appreciate your help. "XMODIFIERS=@im=local" is related Multi key Compose feature [1] One of document said "XMODIFIERS=@im=none" [2] Could you try "XMODIFIERS=@im=none" ? [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml [2] https://fedoraproject.org/wiki/I18N/InputMethods Thanks, Ichiroh Takiguchi On 2019-07-22 23:58, Vladimir Kempik wrote: > Hello > I?m getting Bus Error on startup with > XMODIFIERS=@im=local ./xim_root > nothing yet in log at that moment. > > Thanks, Vladimir > >> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >> ???????(?): >> >> Hello Vladimir. >> >> I appreciate your reply. >> >> I did not expect "[1]w=0x0", it means xim_root could not receive focus >> window via XIC. >> I checked ibus XIM server on Linux s390x platform again, it also >> returned "[1]w=0" ... >> I was confused. >> >> I'd like to add new instruction >> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >> desktop, like >> $ XMODIFIERS=@im=local ./xim_root >> 6. Move input focus to XIM demo window >> 7. Press Ctrl key and Press Right mouse button >> >> I tested xim_root on Linux s390x platform. >> >> $ XMODIFIERS=@im=ibus ./xim_root >> fevent = 0x3 >> topwindow = 0x1e00001, window = 0x1e00002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >> XSetInputFocus() is called >> FocusOut: window=0x1e00002(Internal Window) >> XUnsetICFocus >> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x1e00002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x0 >> [2]w=0x0 >> [1]state=0x0 >> [2]state=0x0 >> State: Unknown >> ClientMessage is received >> >> I tried it with XMODIFIERS=@im=local >> $ XMODIFIERS=@im=local ./xim_root >> fevent = 0 >> topwindow = 0x2000001, window = 0x2000002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >> XSetInputFocus() is called >> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x2000002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x2000002 >> [2]w=0x2000002 >> [1]state=0x2 >> [2]state=0x2 >> State: IM Off >> ClientMessage is received >> >> I was expected this result. >> $ XMODIFIERS=@im=kinput2 ./xim_root >> fevent = 0x3 >> topwindow = 0x2000001, window = 0x2000002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >> XSetInputFocus() is called >> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x2000002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x200000200000000 >> [2]w=0x2000002 >> [1]state=0x200000000 >> [2]state=0x2 >> State: IM Off >> ClientMessage is received >> >> I'm sorry, it seemed current code did not work on even if Linux s390x >> platform. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-07-19 23:29, Vladimir Kempik wrote: >>> Hello >>> I?m probably missing something about XIM on X side here, using ssh >>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>> the output is >>> fevent = 0x3 >>> topwindow = 0x3800001, window = 0x3800002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>> XSetInputFocus() is called >>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x3800002(Internal Window) >>> XSetICFocus >>> FocusOut: window=0x3800002(Internal Window) >>> XUnsetICFocus >>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>> XSetInputFocus() is called >>> ButtonPress: >>> [1]w=0x0 >>> [2]w=0x0 >>> [1]state=0x0 >>> [2]state=0x0 >>> State: Unknown >>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x3800002(Internal Window) >>> I also had to press left button, not right one. >>> I think when you initialy created 8213232 you were targeting linux >>> ppc64 BE system in your patch and simply forgot about another 64-bit >>> BE system - solaris sparc64 >>> I would propose this fix for 8227919 >>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> @@ -1671,7 +1671,7 @@ >>> { >>> X11InputMethodData *pX11IMData = NULL; >>> char * ret = NULL; >>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> // XIMPreeditState value which is used for XGetICValues must be >>> 32bit on BigEndian XOrg's xlib >>> unsigned int state = XIMPreeditUnKnown; >>> #else >>> Such change already allowed to pass our internal tests on solaris >>> sparc64 >>> if you think it?s ok then let me take over and finish with 8227919 >>> Thanks, Vladimir >>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>> >> >> >> >>> ???????(?): >>> Hello. >>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>> Please follow the steps: >>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>> 2. Run xim_root on desktop >>> 3. Move input focus to XIM demo window >>> 4. Press Ctrl key and Press Right mouse button >>> Please put the output into JDK-8227919 [1] or post it into mailing >>> list. >>> I really appreciate if you are using XIM like IIIMF. >>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>> Thanks, >>> Ichiroh Takiguchi From Sergey.Bylokhov at oracle.com Mon Jul 22 21:22:08 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Jul 2019 14:22:08 -0700 Subject: RFR: [XXS] 8228468: awt_Robot.c : format string contains 0 within the string body - was : RE: awt_Robot.c : format string contains '\0' within the string body In-Reply-To: References: Message-ID: Looks fine. On 22/07/2019 01:26, Baesken, Matthias wrote: > Hi Sergey, thanks for the reply ! > > I created a bug + webrev . Please review . > > https://bugs.openjdk.java.net/browse/JDK-8228468 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228468.0/ > > Best regards, Matthias > > *From:*Sergey Bylokhov > *Sent:* Freitag, 19. Juli 2019 23:06 > *To:* Baesken, Matthias > *Cc:* awt-dev at openjdk.java.net; 2d-dev at openjdk.java.net > *Subject:* Re: awt_Robot.c : format string contains '\0' within the string body > > Hi, Matthias. > > I think it is unneeded and can be removed. > > ----- matthias.baesken at sap.com wrote: >> > >> > >> > > Hello,?? is there a special reason to put? a? '\0'? at the end of ?the?? ?atom_name?? - parameter? of the XInternAtom call in? isXCompositeDisplay? ? > > jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c : > > static jboolean isXCompositeDisplay(Display *display, int screenNumber) { > > char NET_WM_CM_Sn[25]; > > snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); > > ??? Atom managerSelection = XInternAtom(display, NET_WM_CM_Sn, 0); > > I think on UNIX? the snprintf implementations? are conforming and zero-terminate? ( exception was VS before VS2015?? but this? is? unix/native ?code ). > > Reason why I ask is this warning we ?have? in our AIX xlc16/xlclang? build? : > > /jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:153:65: warning: format string contains '\0' within the string body [-Wformat] > > ??? snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber); > > Thanks, Matthias > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Jul 22 21:58:06 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 22 Jul 2019 14:58:06 -0700 Subject: Replacement for com.apple.eawt.FullScreen* In-Reply-To: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> References: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> Message-ID: <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> Hi, DRC. I guess this feature have to be implemented by this CR: https://bugs.openjdk.java.net/browse/JDK-8143914 The idea was to use the sequence of: "setExtendedState() + MAXIMIZED_BOTH" to toggle the "fullscreen" window. And use the client property to enable/disable this functionality. But it looks like something has changed since then, and the window does not move to the "fullscreen" when we zoom it. Please file a bug for this. Interesting that the "fullscreen" works fine if the user clicks on the zoom button. On 20/07/2019 17:03, DRC wrote: > I've been beating my head against the wall about this for quite a while, > but I can't figure out how to programmatically toggle "Lion Full-Screen > Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the > deprecated com.apple.eawt.FullScreen* classes, which are problematic at > best when including a custom JRE in my app using jlink. I looked at the > OpenJDK 12 source, and it doesn't appear that the native code to do this > toggling has any other touch points besides the > com.apple.eawt.FullScreen* classes. What am I missing? The problem is > that, because I'm writing a remote desktop client, I have to provide > users with a way to switch in and out of full-screen mode with a > keystroke and menu option, and I also have to be able to detect when the > user clicks the full-screen button in the window's titlebar. I don't > know how to do that without invoking > com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and > com.apple.eawt.Application.requestToggleFullScreen(). Any advice is > appreciated. > > DRC > -- Best regards, Sergey. From vkempik at azul.com Tue Jul 23 11:00:01 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Tue, 23 Jul 2019 11:00:01 +0000 Subject: 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: Message-ID: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> Hello it still crashes with "Bus Error" I guess I may miss something on X server side. Thanks, Vladimir. > 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi ???????(?): > > Hello Vladimir. > > I really appreciate your help. > > "XMODIFIERS=@im=local" is related Multi key Compose feature [1] > One of document said "XMODIFIERS=@im=none" [2] > > Could you try "XMODIFIERS=@im=none" ? > > [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml > [2] https://fedoraproject.org/wiki/I18N/InputMethods > > Thanks, > Ichiroh Takiguchi > > On 2019-07-22 23:58, Vladimir Kempik wrote: >> Hello >> I?m getting Bus Error on startup with >> XMODIFIERS=@im=local ./xim_root >> nothing yet in log at that moment. >> Thanks, Vladimir >>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi ???????(?): >>> Hello Vladimir. >>> I appreciate your reply. >>> I did not expect "[1]w=0x0", it means xim_root could not receive focus window via XIC. >>> I checked ibus XIM server on Linux s390x platform again, it also returned "[1]w=0" ... >>> I was confused. >>> I'd like to add new instruction >>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on desktop, like >>> $ XMODIFIERS=@im=local ./xim_root >>> 6. Move input focus to XIM demo window >>> 7. Press Ctrl key and Press Right mouse button >>> I tested xim_root on Linux s390x platform. >>> $ XMODIFIERS=@im=ibus ./xim_root >>> fevent = 0x3 >>> topwindow = 0x1e00001, window = 0x1e00002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>> XSetInputFocus() is called >>> FocusOut: window=0x1e00002(Internal Window) >>> XUnsetICFocus >>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x1e00002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x0 >>> [2]w=0x0 >>> [1]state=0x0 >>> [2]state=0x0 >>> State: Unknown >>> ClientMessage is received >>> I tried it with XMODIFIERS=@im=local >>> $ XMODIFIERS=@im=local ./xim_root >>> fevent = 0 >>> topwindow = 0x2000001, window = 0x2000002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>> XSetInputFocus() is called >>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x2000002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x2000002 >>> [2]w=0x2000002 >>> [1]state=0x2 >>> [2]state=0x2 >>> State: IM Off >>> ClientMessage is received >>> I was expected this result. >>> $ XMODIFIERS=@im=kinput2 ./xim_root >>> fevent = 0x3 >>> topwindow = 0x2000001, window = 0x2000002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>> XSetInputFocus() is called >>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x2000002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x200000200000000 >>> [2]w=0x2000002 >>> [1]state=0x200000000 >>> [2]state=0x2 >>> State: IM Off >>> ClientMessage is received >>> I'm sorry, it seemed current code did not work on even if Linux s390x platform. >>> Thanks, >>> Ichiroh Takiguchi >>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>> Hello >>>> I?m probably missing something about XIM on X side here, using ssh >>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>> the output is >>>> fevent = 0x3 >>>> topwindow = 0x3800001, window = 0x3800002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x3800002(Internal Window) >>>> XSetICFocus >>>> FocusOut: window=0x3800002(Internal Window) >>>> XUnsetICFocus >>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>> XSetInputFocus() is called >>>> ButtonPress: >>>> [1]w=0x0 >>>> [2]w=0x0 >>>> [1]state=0x0 >>>> [2]state=0x0 >>>> State: Unknown >>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x3800002(Internal Window) >>>> I also had to press left button, not right one. >>>> I think when you initialy created 8213232 you were targeting linux >>>> ppc64 BE system in your patch and simply forgot about another 64-bit >>>> BE system - solaris sparc64 >>>> I would propose this fix for 8227919 >>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> @@ -1671,7 +1671,7 @@ >>>> { >>>> X11InputMethodData *pX11IMData = NULL; >>>> char * ret = NULL; >>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> // XIMPreeditState value which is used for XGetICValues must be >>>> 32bit on BigEndian XOrg's xlib >>>> unsigned int state = XIMPreeditUnKnown; >>>> #else >>>> Such change already allowed to pass our internal tests on solaris sparc64 >>>> if you think it?s ok then let me take over and finish with 8227919 >>>> Thanks, Vladimir >>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>> >>>> >>>> ???????(?): >>>> Hello. >>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>>> Please follow the steps: >>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>> 2. Run xim_root on desktop >>>> 3. Move input focus to XIM demo window >>>> 4. Press Ctrl key and Press Right mouse button >>>> Please put the output into JDK-8227919 [1] or post it into mailing list. >>>> I really appreciate if you are using XIM like IIIMF. >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>> Thanks, >>>> Ichiroh Takiguchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From drc at virtualgl.org Wed Jul 24 20:55:02 2019 From: drc at virtualgl.org (DRC) Date: Wed, 24 Jul 2019 15:55:02 -0500 Subject: Replacement for com.apple.eawt.FullScreen* In-Reply-To: <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> References: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> Message-ID: <6b571e74-c9ec-0645-57d4-06c07659424c@virtualgl.org> I looked at the code that supposedly implements the new behavior (activating full-screen mode with setExtendedState(MAXIMIZED_BOTH).) That code appears unchanged in OpenJDK 11 vs. OpenJDK 9, where it was introduced. I don't see how the code could possibly duplicate the functionality of com.apple.eawt.Application.requestToggleFullScreen(). The com.apple.eawt.Application.requestToggleFullScreen() method hooks into CPlatformWindow.toggleFullScreen(). The new code implemented in JDK-8143914 provides additional hooks into CPlatformWindow.toggleFullScreen(), but they appear to be activated only if: 1. getRootPane().putClientProperty("apple.awt.fullscreenable", false) is called and the window is already in full-screen mode, or 2. setResizable(false) is called and the window is already in full-screen mode. That does not expose the same functionality to applications as com.apple.eawt.Application.requestToggleFullScreen(). Even if it did, it could not replace com.apple.eawt.FullScreenListener, which is needed in order for applications to be notified when full-screen mode is activated or deactivated. On 7/22/19 4:58 PM, Sergey Bylokhov wrote: > Hi, DRC. > > I guess this feature have to be implemented by this CR: > https://bugs.openjdk.java.net/browse/JDK-8143914 > > The idea was to use the sequence of: "setExtendedState() + MAXIMIZED_BOTH" > to toggle the "fullscreen" window. And use the client property to > enable/disable > this functionality. But it looks like something has changed since then, and > the window does not move to the "fullscreen" when we zoom it. > Please file a bug for this. > > Interesting that the "fullscreen" works fine if the user clicks on the > zoom button. > > > On 20/07/2019 17:03, DRC wrote: >> I've been beating my head against the wall about this for quite a while, >> but I can't figure out how to programmatically toggle "Lion Full-Screen >> Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the >> deprecated com.apple.eawt.FullScreen* classes, which are problematic at >> best when including a custom JRE in my app using jlink.? I looked at the >> OpenJDK 12 source, and it doesn't appear that the native code to do this >> toggling has any other touch points besides the >> com.apple.eawt.FullScreen* classes.? What am I missing?? The problem is >> that, because I'm writing a remote desktop client, I have to provide >> users with a way to switch in and out of full-screen mode with a >> keystroke and menu option, and I also have to be able to detect when the >> user clicks the full-screen button in the window's titlebar.? I don't >> know how to do that without invoking >> com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and >> com.apple.eawt.Application.requestToggleFullScreen().? Any advice is >> appreciated. >> >> DRC >> > > From drc at virtualgl.org Wed Jul 24 21:03:42 2019 From: drc at virtualgl.org (DRC) Date: Wed, 24 Jul 2019 16:03:42 -0500 Subject: Replacement for com.apple.eawt.FullScreen* In-Reply-To: <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> References: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> Message-ID: As far as filing a bug report, I would love to, but the rules for obtaining a bug tracker account are rather stringent, and I doubt that I qualify (https://wiki.openjdk.java.net/display/general/JBS+Overview). I am an application developer that relies upon OpenJDK, and I have some familiarity with the source code vis-a-vis diagnosing issues such as this, but I'm not an OpenJDK author. Sorry if this is the wrong forum for me to post issues like this, but I didn't know where else to post. On 7/22/19 4:58 PM, Sergey Bylokhov wrote: > Hi, DRC. > > I guess this feature have to be implemented by this CR: > https://bugs.openjdk.java.net/browse/JDK-8143914 > > The idea was to use the sequence of: "setExtendedState() + MAXIMIZED_BOTH" > to toggle the "fullscreen" window. And use the client property to > enable/disable > this functionality. But it looks like something has changed since then, and > the window does not move to the "fullscreen" when we zoom it. > Please file a bug for this. > > Interesting that the "fullscreen" works fine if the user clicks on the > zoom button. > > > On 20/07/2019 17:03, DRC wrote: >> I've been beating my head against the wall about this for quite a while, >> but I can't figure out how to programmatically toggle "Lion Full-Screen >> Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the >> deprecated com.apple.eawt.FullScreen* classes, which are problematic at >> best when including a custom JRE in my app using jlink.? I looked at the >> OpenJDK 12 source, and it doesn't appear that the native code to do this >> toggling has any other touch points besides the >> com.apple.eawt.FullScreen* classes.? What am I missing?? The problem is >> that, because I'm writing a remote desktop client, I have to provide >> users with a way to switch in and out of full-screen mode with a >> keystroke and menu option, and I also have to be able to detect when the >> user clicks the full-screen button in the window's titlebar.? I don't >> know how to do that without invoking >> com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and >> com.apple.eawt.Application.requestToggleFullScreen().? Any advice is >> appreciated. >> >> DRC >> > > From Sergey.Bylokhov at oracle.com Wed Jul 24 21:27:41 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 24 Jul 2019 14:27:41 -0700 Subject: Replacement for com.apple.eawt.FullScreen* In-Reply-To: References: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> Message-ID: On 24.07.2019 14:03, DRC wrote: > As far as filing a bug report, I would love to, but the rules for > obtaining a bug tracker account are rather stringent, and I doubt that I > qualify (https://wiki.openjdk.java.net/display/general/JBS+Overview). I It is not necessary to have an JBS account to create a new bugs, you can file it here: https://bugs.java.com/bugdatabase > am an application developer that relies upon OpenJDK, and I have some > familiarity with the source code vis-a-vis diagnosing issues such as > this, but I'm not an OpenJDK author. Sorry if this is the wrong forum > for me to post issues like this, but I didn't know where else to post. > > On 7/22/19 4:58 PM, Sergey Bylokhov wrote: >> Hi, DRC. >> >> I guess this feature have to be implemented by this CR: >> https://bugs.openjdk.java.net/browse/JDK-8143914 >> >> The idea was to use the sequence of: "setExtendedState() + MAXIMIZED_BOTH" >> to toggle the "fullscreen" window. And use the client property to >> enable/disable >> this functionality. But it looks like something has changed since then, and >> the window does not move to the "fullscreen" when we zoom it. >> Please file a bug for this. >> >> Interesting that the "fullscreen" works fine if the user clicks on the >> zoom button. >> >> >> On 20/07/2019 17:03, DRC wrote: >>> I've been beating my head against the wall about this for quite a while, >>> but I can't figure out how to programmatically toggle "Lion Full-Screen >>> Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the >>> deprecated com.apple.eawt.FullScreen* classes, which are problematic at >>> best when including a custom JRE in my app using jlink.? I looked at the >>> OpenJDK 12 source, and it doesn't appear that the native code to do this >>> toggling has any other touch points besides the >>> com.apple.eawt.FullScreen* classes.? What am I missing?? The problem is >>> that, because I'm writing a remote desktop client, I have to provide >>> users with a way to switch in and out of full-screen mode with a >>> keystroke and menu option, and I also have to be able to detect when the >>> user clicks the full-screen button in the window's titlebar.? I don't >>> know how to do that without invoking >>> com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and >>> com.apple.eawt.Application.requestToggleFullScreen().? Any advice is >>> appreciated. >>> >>> DRC >>> >> >> -- Best regards, Sergey. From drc at virtualgl.org Wed Jul 24 20:53:52 2019 From: drc at virtualgl.org (DRC) Date: Wed, 24 Jul 2019 15:53:52 -0500 Subject: Replacement for com.apple.eawt.FullScreen* In-Reply-To: <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> References: <1614bcc0-c058-41ab-3753-e8bb9baac37c@virtualgl.org> <08ae5bb7-52a8-d8b1-9fc5-f9268b31d5a0@oracle.com> Message-ID: <39ce39ab-b4b9-a66c-ed26-c0b672ba8c17@virtualgl.org> I looked at the code that supposedly implements the new behavior (activating full-screen mode with setExtendedState(MAXIMIZED_BOTH).)? That code appears unchanged in OpenJDK 11 vs. OpenJDK 9, where it was introduced.? I don't see how the code could possibly duplicate the functionality of com.apple.eawt.Application.requestToggleFullScreen().? The com.apple.eawt.Application.requestToggleFullScreen() method hooks into CPlatformWindow.toggleFullScreen().? The new code implemented in JDK-8143914 provides additional hooks into CPlatformWindow.toggleFullScreen(), but they appear to be activated only if:? 1. getRootPane().putClientProperty("apple.awt.fullscreenable", false) is called and the window is already in full-screen mode, or 2. setResizable(false) is called and the window is already in full-screen mode. That does not expose the same functionality to applications as com.apple.eawt.Application.requestToggleFullScreen().? Even if it did,?it could not replace com.apple.eawt.FullScreenListener, which is needed in order for applications to be notified when full-screen mode is activated or deactivated. On 7/22/19 4:58 PM, Sergey Bylokhov wrote: > Hi, DRC. > > I guess this feature have to be implemented by this CR: > https://bugs.openjdk.java.net/browse/JDK-8143914 > > The idea was to use the sequence of: "setExtendedState() + > MAXIMIZED_BOTH" > to toggle the "fullscreen" window. And use the client property to > enable/disable > this functionality. But it looks like something has changed since > then, and > the window does not move to the "fullscreen" when we zoom it. > Please file a bug for this. > > Interesting that the "fullscreen" works fine if the user clicks on the > zoom button. > > > On 20/07/2019 17:03, DRC wrote: >> I've been beating my head against the wall about this for quite a while, >> but I can't figure out how to programmatically toggle "Lion Full-Screen >> Mode" (i.e. "Full-Screen Mode Using Spaces") on macOS without using the >> deprecated com.apple.eawt.FullScreen* classes, which are problematic at >> best when including a custom JRE in my app using jlink.? I looked at the >> OpenJDK 12 source, and it doesn't appear that the native code to do this >> toggling has any other touch points besides the >> com.apple.eawt.FullScreen* classes.? What am I missing?? The problem is >> that, because I'm writing a remote desktop client, I have to provide >> users with a way to switch in and out of full-screen mode with a >> keystroke and menu option, and I also have to be able to detect when the >> user clicks the full-screen button in the window's titlebar.? I don't >> know how to do that without invoking >> com.apple.eawt.FullScreenListener.addFullScreenListenerTo() and >> com.apple.eawt.Application.requestToggleFullScreen().? Any advice is >> appreciated. >> >> DRC >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Jul 11 13:43:34 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Jul 2019 15:43:34 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary Message-ID: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> Hi, by adding a method to load libraries with privileges to JavaLangAccess, we can simplify a slew of places where we are currently implementing adhoc privileged actions. This is a tiny but measurable gain on a range of startup tests. Webrev: http://cr.openjdk.java.net/~redestad/8227587/open.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8227587 Testing: tier1-3 Thanks! /Claes From claes.redestad at oracle.com Thu Jul 11 14:39:46 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Jul 2019 16:39:46 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> Message-ID: <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> Hi Roger, On 2019-07-11 16:10, Roger Riggs wrote: > Hi Claes, > > JavaLangAccess.java: > 316: Add @param tag done. > > System.java:? 2282, 2287 > Runtime.loadLibrary0 makes a second check for a security manager. > Is there any potential gain by calling ClassLoader.loadLibrary directly? > None of the internal uses would have a separatorChar. Most of the gain comes from not having to load one-off PA classes or lambdas, but of course avoiding the indexOf and a few indirections are marginally helpful to startup. We should at least assert that the library names are sane, though. > > I expect most of the files need a copyright update. > The script in /make/scripts/update_copyright_year.sh should do the > work for modified files. Fixed copyrights and updated in place: http://cr.openjdk.java.net/~redestad/8227587/open.00 Thanks! /Claes From claes.redestad at oracle.com Fri Jul 12 14:37:42 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 12 Jul 2019 16:37:42 +0200 Subject: RFR: 8227587: Add internal privileged System.loadLibrary In-Reply-To: <5D2895DF.8070001@oracle.com> References: <8cf6ed4d-194a-4428-f381-e7e3c0452cd6@oracle.com> <4943b69c-bc3a-f147-abb8-5b369eec5737@oracle.com> <2cbfd5d8-c4a0-4a2d-ba62-6fed14dc7155@oracle.com> <60d95350-c42c-1498-5c72-174736e863c0@oracle.com> <5D2895DF.8070001@oracle.com> Message-ID: Hi, I'm dropping the changes to java.desktop from this RFE. On 2019-07-12 16:14, Philip Race wrote: > 3) I've spent spare time over a number of months trying to decrease > unnecessary coupling between desktop and base modules. This seems to create > additional technical debt there with minimal benefit, so in other words > I'd much prefer that either you don't do this at all or the many, many, > uses in the desktop module that are the heaviest Java->native code > user in the JDK are dealt with entirely separately (separate bug) and at > a minimum > there is one place in the desktop module that they all call to and > perhaps only then *through*. Right, 20 of the 31 usages in java.desktop are loading "awt", and could just be switched out with a call to NativeLibLoader.loadLibraries(). Quick and easy win, but I have better things to do than spend time where I'm not welcome. /Claes From Sergey.Bylokhov at oracle.com Fri Jul 26 00:55:52 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Jul 2019 17:55:52 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 Message-ID: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> Hello. Please review the fix for JDK 13. Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 This is an upgrade of the libpng library to the latest version. Most changes are just "drop and replace". -- Best regards, Sergey. From kevin.rushforth at oracle.com Fri Jul 26 01:33:08 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jul 2019 18:33:08 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> Message-ID: <85aa2fd4-4c2d-883b-1562-6f4e3b1a4aa3@oracle.com> Looks good to me. -- Kevin On 7/25/2019 5:55 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 > Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 > > This is an upgrade of the libpng library to the latest version. > Most changes are just "drop and replace". > From matthias.baesken at sap.com Fri Jul 26 09:02:51 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 26 Jul 2019 09:02:51 +0000 Subject: question regarding test java/awt/PrinterJob/SameService.java (tests that print services are not re-created) Message-ID: Hello, I have a question regarding the test java/awt/PrinterJob/SameService.java ; the test deals with @bug 6446094 . It checks that print services are not re-created , which was addressed (or at least discussed ) in 6446094 , See https://bugs.openjdk.java.net/browse/JDK-6446094 Win32PrintServiceLookup.getPrintServiceByName() should not recreate duplicate instances. However 6446094 just talks about Windows , and I see sporadic failures on some Linux test machine in java/awt/PrinterJob/SameService.java because the print service is (seldom) recreated on Linux ( it is even non-deterministic, on the same machine the test fails in ~ 30 % of runs and succeeds in the other cases ) . Can we make the test Windows-only ( I think the API does not guarantee that print services are not re-created , although it is desired ) ? Best regards, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From takiguc at linux.vnet.ibm.com Fri Jul 26 12:53:49 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Fri, 26 Jul 2019 21:53:49 +0900 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> Message-ID: Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ It's crash issue for Solaris SPARC platform. If possible, please push this fix into 13. XIMPreditState is changed to unsigned long instead of unsigned int on 64bit Big endian. It's same as Java8. I think Solaris SPARC's issue can be fixed by this fix. Vladimir, I appreciate your great help. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2019-07-23 20:00, Vladimir Kempik wrote: > Hello > > it still crashes with "Bus Error" > > I guess I may miss something on X server side. > Thanks, Vladimir. > >> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >> ???????(?): >> >> Hello Vladimir. >> >> I really appreciate your help. >> >> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >> One of document said "XMODIFIERS=@im=none" [2] >> >> Could you try "XMODIFIERS=@im=none" ? >> >> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml >> >> [2] https://fedoraproject.org/wiki/I18N/InputMethods >> >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-07-22 23:58, Vladimir Kempik wrote: >>> Hello >>> I?m getting Bus Error on startup with >>> XMODIFIERS=@im=local ./xim_root >>> nothing yet in log at that moment. >>> Thanks, Vladimir >>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>>> ???????(?): >>>> Hello Vladimir. >>>> I appreciate your reply. >>>> I did not expect "[1]w=0x0", it means xim_root could not receive >>>> focus window via XIC. >>>> I checked ibus XIM server on Linux s390x platform again, it also >>>> returned "[1]w=0" ... >>>> I was confused. >>>> I'd like to add new instruction >>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>>> desktop, like >>>> $ XMODIFIERS=@im=local ./xim_root >>>> 6. Move input focus to XIM demo window >>>> 7. Press Ctrl key and Press Right mouse button >>>> I tested xim_root on Linux s390x platform. >>>> $ XMODIFIERS=@im=ibus ./xim_root >>>> fevent = 0x3 >>>> topwindow = 0x1e00001, window = 0x1e00002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>> XSetInputFocus() is called >>>> FocusOut: window=0x1e00002(Internal Window) >>>> XUnsetICFocus >>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x1e00002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x0 >>>> [2]w=0x0 >>>> [1]state=0x0 >>>> [2]state=0x0 >>>> State: Unknown >>>> ClientMessage is received >>>> I tried it with XMODIFIERS=@im=local >>>> $ XMODIFIERS=@im=local ./xim_root >>>> fevent = 0 >>>> topwindow = 0x2000001, window = 0x2000002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x2000002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x2000002 >>>> [2]w=0x2000002 >>>> [1]state=0x2 >>>> [2]state=0x2 >>>> State: IM Off >>>> ClientMessage is received >>>> I was expected this result. >>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>> fevent = 0x3 >>>> topwindow = 0x2000001, window = 0x2000002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x2000002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x200000200000000 >>>> [2]w=0x2000002 >>>> [1]state=0x200000000 >>>> [2]state=0x2 >>>> State: IM Off >>>> ClientMessage is received >>>> I'm sorry, it seemed current code did not work on even if Linux >>>> s390x platform. >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>>> Hello >>>>> I?m probably missing something about XIM on X side here, using >>>>> ssh >>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>>> the output is >>>>> fevent = 0x3 >>>>> topwindow = 0x3800001, window = 0x3800002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x3800002(Internal Window) >>>>> XSetICFocus >>>>> FocusOut: window=0x3800002(Internal Window) >>>>> XUnsetICFocus >>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>>> XSetInputFocus() is called >>>>> ButtonPress: >>>>> [1]w=0x0 >>>>> [2]w=0x0 >>>>> [1]state=0x0 >>>>> [2]state=0x0 >>>>> State: Unknown >>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x3800002(Internal Window) >>>>> I also had to press left button, not right one. >>>>> I think when you initialy created 8213232 you were targeting linux >>>>> ppc64 BE system in your patch and simply forgot about another >>>>> 64-bit >>>>> BE system - solaris sparc64 >>>>> I would propose this fix for 8227919 >>>>> --- >>>>> a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> +++ >>>>> b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> @@ -1671,7 +1671,7 @@ >>>>> { >>>>> X11InputMethodData *pX11IMData = NULL; >>>>> char * ret = NULL; >>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>> +#if defined(__linux__) && defined(_LP64) && >>>>> !defined(_LITTLE_ENDIAN) >>>>> // XIMPreeditState value which is used for XGetICValues must be >>>>> 32bit on BigEndian XOrg's xlib >>>>> unsigned int state = XIMPreeditUnKnown; >>>>> #else >>>>> Such change already allowed to pass our internal tests on solaris >>>>> sparc64 >>>>> if you think it?s ok then let me take over and finish with >>>>> 8227919 >>>>> Thanks, Vladimir >>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>>> >>>>> >>>> >>>>> >>>> >>> >>>>> ???????(?): >>>>> Hello. >>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 >>>>> [1] >>>>> Please follow the steps: >>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>>> 2. Run xim_root on desktop >>>>> 3. Move input focus to XIM demo window >>>>> 4. Press Ctrl key and Press Right mouse button >>>>> Please put the output into JDK-8227919 [1] or post it into mailing >>>>> list. >>>>> I really appreciate if you are using XIM like IIIMF. >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>>> Thanks, >>>>> Ichiroh Takiguchi From vkempik at azul.com Fri Jul 26 12:59:59 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Fri, 26 Jul 2019 12:59:59 +0000 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> Message-ID: <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> Hello what still bothers me is this: The first Big Endian block: 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) 1630 // On 64bit BigEndian, 1631 // Window value may be stored on high 32bit by XGetICValues via XIM 1632 if (w > 0xffffffffL) w = w >> 32; 1633 #endif is inside linux&macos block 1622 #if defined(__linux__) || defined(MACOSX) however the second Big Endian block is for every platform: 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) 1699 // On 64bit BigEndian, 1700 // XIMPreeditState value may be stored on high 32bit by XGetICValues via XIM 1701 if (state > 0xffffffffL) state = state >> 32; 1702 #endif I?m not sure if it?s ok or not. Also, since XIMPreeditState is unsigned 64-bit int, I think we need to compare it against 0xffffffffUL instead of 0xffffffffL typedef unsigned long int XIMPreeditState; Thanks, Vladimir > 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi ???????(?): > > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 > Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ > > It's crash issue for Solaris SPARC platform. > If possible, please push this fix into 13. > > XIMPreditState is changed to unsigned long instead of unsigned int on 64bit Big endian. > It's same as Java8. > I think Solaris SPARC's issue can be fixed by this fix. > > Vladimir, > I appreciate your great help. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-07-23 20:00, Vladimir Kempik wrote: >> Hello >> it still crashes with "Bus Error" >> I guess I may miss something on X server side. >> Thanks, Vladimir. >>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi ???????(?): >>> Hello Vladimir. >>> I really appreciate your help. >>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>> One of document said "XMODIFIERS=@im=none" [2] >>> Could you try "XMODIFIERS=@im=none" ? >>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml >>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >>> Thanks, >>> Ichiroh Takiguchi >>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>>> Hello >>>> I?m getting Bus Error on startup with >>>> XMODIFIERS=@im=local ./xim_root >>>> nothing yet in log at that moment. >>>> Thanks, Vladimir >>>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi ???????(?): >>>>> Hello Vladimir. >>>>> I appreciate your reply. >>>>> I did not expect "[1]w=0x0", it means xim_root could not receive focus window via XIC. >>>>> I checked ibus XIM server on Linux s390x platform again, it also returned "[1]w=0" ... >>>>> I was confused. >>>>> I'd like to add new instruction >>>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on desktop, like >>>>> $ XMODIFIERS=@im=local ./xim_root >>>>> 6. Move input focus to XIM demo window >>>>> 7. Press Ctrl key and Press Right mouse button >>>>> I tested xim_root on Linux s390x platform. >>>>> $ XMODIFIERS=@im=ibus ./xim_root >>>>> fevent = 0x3 >>>>> topwindow = 0x1e00001, window = 0x1e00002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>>> XSetInputFocus() is called >>>>> FocusOut: window=0x1e00002(Internal Window) >>>>> XUnsetICFocus >>>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x1e00002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x0 >>>>> [2]w=0x0 >>>>> [1]state=0x0 >>>>> [2]state=0x0 >>>>> State: Unknown >>>>> ClientMessage is received >>>>> I tried it with XMODIFIERS=@im=local >>>>> $ XMODIFIERS=@im=local ./xim_root >>>>> fevent = 0 >>>>> topwindow = 0x2000001, window = 0x2000002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x2000002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x2000002 >>>>> [2]w=0x2000002 >>>>> [1]state=0x2 >>>>> [2]state=0x2 >>>>> State: IM Off >>>>> ClientMessage is received >>>>> I was expected this result. >>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>> fevent = 0x3 >>>>> topwindow = 0x2000001, window = 0x2000002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x2000002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x200000200000000 >>>>> [2]w=0x2000002 >>>>> [1]state=0x200000000 >>>>> [2]state=0x2 >>>>> State: IM Off >>>>> ClientMessage is received >>>>> I'm sorry, it seemed current code did not work on even if Linux s390x platform. >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>>>> Hello >>>>>> I?m probably missing something about XIM on X side here, using ssh >>>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>>>> the output is >>>>>> fevent = 0x3 >>>>>> topwindow = 0x3800001, window = 0x3800002 >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>>>> XSetInputFocus() is called >>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>> XSetICFocus >>>>>> FocusOut: window=0x3800002(Internal Window) >>>>>> XUnsetICFocus >>>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>>>> XSetInputFocus() is called >>>>>> ButtonPress: >>>>>> [1]w=0x0 >>>>>> [2]w=0x0 >>>>>> [1]state=0x0 >>>>>> [2]state=0x0 >>>>>> State: Unknown >>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>> I also had to press left button, not right one. >>>>>> I think when you initialy created 8213232 you were targeting linux >>>>>> ppc64 BE system in your patch and simply forgot about another 64-bit >>>>>> BE system - solaris sparc64 >>>>>> I would propose this fix for 8227919 >>>>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>> @@ -1671,7 +1671,7 @@ >>>>>> { >>>>>> X11InputMethodData *pX11IMData = NULL; >>>>>> char * ret = NULL; >>>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> // XIMPreeditState value which is used for XGetICValues must be >>>>>> 32bit on BigEndian XOrg's xlib >>>>>> unsigned int state = XIMPreeditUnKnown; >>>>>> #else >>>>>> Such change already allowed to pass our internal tests on solaris sparc64 >>>>>> if you think it?s ok then let me take over and finish with 8227919 >>>>>> Thanks, Vladimir >>>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>>>> >>>> >>>>>> ???????(?): >>>>>> Hello. >>>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>>>>> Please follow the steps: >>>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>>>> 2. Run xim_root on desktop >>>>>> 3. Move input focus to XIM demo window >>>>>> 4. Press Ctrl key and Press Right mouse button >>>>>> Please put the output into JDK-8227919 [1] or post it into mailing list. >>>>>> I really appreciate if you are using XIM like IIIMF. >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>>>> Thanks, >>>>>> Ichiroh Takiguchi -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From jayathirth.d.v at oracle.com Fri Jul 26 04:28:25 2019 From: jayathirth.d.v at oracle.com (Jayathirth Rao) Date: Fri, 26 Jul 2019 09:58:25 +0530 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> Message-ID: Changes are fine. Thanks, Jay > On 26-Jul-2019, at 6:25 AM, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 > Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 > > This is an upgrade of the libpng library to the latest version. > Most changes are just "drop and replace". > > -- > Best regards, Sergey. From TAKIGUC at jp.ibm.com Mon Jul 29 12:44:46 2019 From: TAKIGUC at jp.ibm.com (Ichiroh Takiguchi) Date: Mon, 29 Jul 2019 21:44:46 +0900 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> Message-ID: Hello Vladimir. I appreciate your suggestion. And I'm very sorry for bad response. Our mail server for external mailing list is downed in these days. So I'd like to use another email address. Please see following 2 outputs. > $ XMODIFIERS=@im=local ./xim_root ...... > ButtonPress: > [1]w=0x2000002 > [2]w=0x2000002 > [1]state=0x2 > [2]state=0x2 > $ XMODIFIERS=@im=kinput2 ./xim_root ...... > ButtonPress: > [1]w=0x200000200000000 > [2]w=0x2000002 > [1]state=0x200000000 > [2]state=0x2 These mean @im=local is used low 32bit on 64bit long <= The data comes from Xlib @im=kinput2 is used high 32bit on 64bit long <= The data comes from XIM protocol So following code changes is required on Linux s390x, it was my mistake. if (w > 0xffffffffUL) w = w >> 32; I created another fix, could you review it ? Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ It changes: * 0xffffffffL is changed to 0xffffffffUL * defined(__linux__) is added into defined(_LP64) line Thanks, ------ Ichiro Takiguchi IBM Japan Ltd. "awt-dev" wrote on 2019/07/26 21:59:59: > From: Vladimir Kempik > To: Ichiroh Takiguchi > Cc: "awt-dev at openjdk.java.net" , "i18n- > dev at openjdk.java.net" > Date: 2019/07/26 22:01 > Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes > crashes on solaris sparc64 > Sent by: "awt-dev" > > Hello > > what still bothers me is this: > > The first Big Endian block: > > 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) > 1630 // On 64bit BigEndian, > 1631 // Window value may be stored on high 32bit by > XGetICValues via XIM > 1632 if (w > 0xffffffffL) w = w >> 32; > 1633 #endif > > is inside linux&macos block > > 1622 #if defined(__linux__) || defined(MACOSX) > > however the second Big Endian block is for every platform: > > 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) > 1699 // On 64bit BigEndian, > 1700 // XIMPreeditState value may be stored on high 32bit by > XGetICValues via XIM > 1701 if (state > 0xffffffffL) state = state >> 32; > 1702 #endif > I?m not sure if it?s ok or not. > > Also, since XIMPreeditState is unsigned 64-bit int, I think we need > to compare it against 0xffffffffUL instead of 0xffffffffL > > typedef unsigned long int XIMPreeditState; > > Thanks, Vladimir > > 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi > ???????(?): > > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 > Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ > > It's crash issue for Solaris SPARC platform. > If possible, please push this fix into 13. > > XIMPreditState is changed to unsigned long instead of unsigned int > on 64bit Big endian. > It's same as Java8. > I think Solaris SPARC's issue can be fixed by this fix. > > Vladimir, > I appreciate your great help. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2019-07-23 20:00, Vladimir Kempik wrote: > Hello > it still crashes with "Bus Error" > I guess I may miss something on X server side. > Thanks, Vladimir. > 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi > ???????(?): > Hello Vladimir. > I really appreciate your help. > "XMODIFIERS=@im=local" is related Multi key Compose feature [1] > One of document said "XMODIFIERS=@im=none" [2] > Could you try "XMODIFIERS=@im=none" ? > [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < > https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> > [2] https://fedoraproject.org/wiki/I18N/InputMethods fedoraproject.org/wiki/I18N/InputMethods> > Thanks, > Ichiroh Takiguchi > On 2019-07-22 23:58, Vladimir Kempik wrote: > Hello > I?m getting Bus Error on startup with > XMODIFIERS=@im=local ./xim_root > nothing yet in log at that moment. > Thanks, Vladimir > 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi > ???????(?): > Hello Vladimir. > I appreciate your reply. > I did not expect "[1]w=0x0", it means xim_root could not receive > focus window via XIC. > I checked ibus XIM server on Linux s390x platform again, it also > returned "[1]w=0" ... > I was confused. > I'd like to add new instruction > 5. Run xim_root with XMODIFIERS=@im=local environment variable on > desktop, like > $ XMODIFIERS=@im=local ./xim_root > 6. Move input focus to XIM demo window > 7. Press Ctrl key and Press Right mouse button > I tested xim_root on Linux s390x platform. > $ XMODIFIERS=@im=ibus ./xim_root > fevent = 0x3 > topwindow = 0x1e00001, window = 0x1e00002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 > XSetInputFocus() is called > FocusOut: window=0x1e00002(Internal Window) > XUnsetICFocus > FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) > FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) > FocusIn: window=0x1e00002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x0 > [2]w=0x0 > [1]state=0x0 > [2]state=0x0 > State: Unknown > ClientMessage is received > I tried it with XMODIFIERS=@im=local > $ XMODIFIERS=@im=local ./xim_root > fevent = 0 > topwindow = 0x2000001, window = 0x2000002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 > XSetInputFocus() is called > FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) > FocusIn: window=0x2000002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x2000002 > [2]w=0x2000002 > [1]state=0x2 > [2]state=0x2 > State: IM Off > ClientMessage is received > I was expected this result. > $ XMODIFIERS=@im=kinput2 ./xim_root > fevent = 0x3 > topwindow = 0x2000001, window = 0x2000002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 > XSetInputFocus() is called > FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) > FocusIn: window=0x2000002(Internal Window) > XSetICFocus > KeyPress: > ButtonPress: > [1]w=0x200000200000000 > [2]w=0x2000002 > [1]state=0x200000000 > [2]state=0x2 > State: IM Off > ClientMessage is received > I'm sorry, it seemed current code did not work on even if Linux > s390x platform. > Thanks, > Ichiroh Takiguchi > On 2019-07-19 23:29, Vladimir Kempik wrote: > Hello > I?m probably missing something about XIM on X side here, using ssh > -X from ubuntu(with Xserver) to solaris11 sparc64 machine > the output is > fevent = 0x3 > topwindow = 0x3800001, window = 0x3800002 > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 > XSetInputFocus() is called > FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) > FocusIn: window=0x3800002(Internal Window) > XSetICFocus > FocusOut: window=0x3800002(Internal Window) > XUnsetICFocus > FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) > ClientMessage is received > WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 > XSetInputFocus() is called > ButtonPress: > [1]w=0x0 > [2]w=0x0 > [1]state=0x0 > [2]state=0x0 > State: Unknown > FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) > FocusIn: window=0x3800002(Internal Window) > I also had to press left button, not right one. > I think when you initialy created 8213232 you were targeting linux > ppc64 BE system in your patch and simply forgot about another 64-bit > BE system - solaris sparc64 > I would propose this fix for 8227919 > --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > @@ -1671,7 +1671,7 @@ > { > X11InputMethodData *pX11IMData = NULL; > char * ret = NULL; > -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) > +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) > // XIMPreeditState value which is used for XGetICValues must be > 32bit on BigEndian XOrg's xlib > unsigned int state = XIMPreeditUnKnown; > #else > Such change already allowed to pass our internal tests on solaris sparc64 > if you think it?s ok then let me take over and finish with 8227919 > Thanks, Vladimir > 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi > < > mailto:takiguc at linux.vnet.ibm.com >< > mailto:takiguc at linux.vnet.ibm.com < > mailto:takiguc at linux.vnet.ibm.com >>> > ???????(?): > Hello. > I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] > Please follow the steps: > 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC > 2. Run xim_root on desktop > 3. Move input focus to XIM demo window > 4. Press Ctrl key and Press Right mouse button > Please put the output into JDK-8227919 [1] or post it into mailing list. > I really appreciate if you are using XIM like IIIMF. > [1] https://bugs.openjdk.java.net/browse/JDK-8227919 > [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c > Thanks, > Ichiroh Takiguchi From vkempik at azul.com Mon Jul 29 12:49:50 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Mon, 29 Jul 2019 12:49:50 +0000 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> Message-ID: <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> Looks good to me. Now need some reviewers to take a look at it. Thanks, Vladimir. > 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi ???????(?): > > Hello Vladimir. > I appreciate your suggestion. > > And I'm very sorry for bad response. > Our mail server for external mailing list is downed in these days. > So I'd like to use another email address. > > Please see following 2 outputs. >> $ XMODIFIERS=@im=local ./xim_root > ...... >> ButtonPress: >> [1]w=0x2000002 >> [2]w=0x2000002 >> [1]state=0x2 >> [2]state=0x2 > >> $ XMODIFIERS=@im=kinput2 ./xim_root > ...... >> ButtonPress: >> [1]w=0x200000200000000 >> [2]w=0x2000002 >> [1]state=0x200000000 >> [2]state=0x2 > > These mean > @im=local is used low 32bit on 64bit long <= The data comes from Xlib > @im=kinput2 is used high 32bit on 64bit long <= The data comes from XIM > protocol > > So following code changes is required on Linux s390x, it was my mistake. > if (w > 0xffffffffUL) w = w >> 32; > > I created another fix, could you review it ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 > Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ > > It changes: > * 0xffffffffL is changed to 0xffffffffUL > * defined(__linux__) is added into defined(_LP64) line > > Thanks, > ------ > Ichiro Takiguchi > IBM Japan Ltd. > > "awt-dev" wrote on 2019/07/26 21:59:59: > >> From: Vladimir Kempik >> To: Ichiroh Takiguchi >> Cc: "awt-dev at openjdk.java.net" , "i18n- >> dev at openjdk.java.net" >> Date: 2019/07/26 22:01 >> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >> crashes on solaris sparc64 >> Sent by: "awt-dev" >> >> Hello >> >> what still bothers me is this: >> >> The first Big Endian block: >> >> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >> 1630 // On 64bit BigEndian, >> 1631 // Window value may be stored on high 32bit by >> XGetICValues via XIM >> 1632 if (w > 0xffffffffL) w = w >> 32; >> 1633 #endif >> >> is inside linux&macos block >> >> 1622 #if defined(__linux__) || defined(MACOSX) > >> >> however the second Big Endian block is for every platform: >> >> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >> 1699 // On 64bit BigEndian, >> 1700 // XIMPreeditState value may be stored on high 32bit by >> XGetICValues via XIM >> 1701 if (state > 0xffffffffL) state = state >> 32; >> 1702 #endif >> I?m not sure if it?s ok or not. >> >> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >> to compare it against 0xffffffffUL instead of 0xffffffffL >> >> typedef unsigned long int XIMPreeditState; > >> >> Thanks, Vladimir >> >> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >> ???????(?): >> >> Hello. >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >> >> It's crash issue for Solaris SPARC platform. >> If possible, please push this fix into 13. >> >> XIMPreditState is changed to unsigned long instead of unsigned int >> on 64bit Big endian. >> It's same as Java8. >> I think Solaris SPARC's issue can be fixed by this fix. >> >> Vladimir, >> I appreciate your great help. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> On 2019-07-23 20:00, Vladimir Kempik wrote: >> Hello >> it still crashes with "Bus Error" >> I guess I may miss something on X server side. >> Thanks, Vladimir. >> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >> ???????(?): >> Hello Vladimir. >> I really appreciate your help. >> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >> One of document said "XMODIFIERS=@im=none" [2] >> Could you try "XMODIFIERS=@im=none" ? >> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < >> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >> [2] https://fedoraproject.org/wiki/I18N/InputMethods > fedoraproject.org/wiki/I18N/InputMethods> >> Thanks, >> Ichiroh Takiguchi >> On 2019-07-22 23:58, Vladimir Kempik wrote: >> Hello >> I?m getting Bus Error on startup with >> XMODIFIERS=@im=local ./xim_root >> nothing yet in log at that moment. >> Thanks, Vladimir >> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >> ???????(?): >> Hello Vladimir. >> I appreciate your reply. >> I did not expect "[1]w=0x0", it means xim_root could not receive >> focus window via XIC. >> I checked ibus XIM server on Linux s390x platform again, it also >> returned "[1]w=0" ... >> I was confused. >> I'd like to add new instruction >> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >> desktop, like >> $ XMODIFIERS=@im=local ./xim_root >> 6. Move input focus to XIM demo window >> 7. Press Ctrl key and Press Right mouse button >> I tested xim_root on Linux s390x platform. >> $ XMODIFIERS=@im=ibus ./xim_root >> fevent = 0x3 >> topwindow = 0x1e00001, window = 0x1e00002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >> XSetInputFocus() is called >> FocusOut: window=0x1e00002(Internal Window) >> XUnsetICFocus >> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x1e00002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x0 >> [2]w=0x0 >> [1]state=0x0 >> [2]state=0x0 >> State: Unknown >> ClientMessage is received >> I tried it with XMODIFIERS=@im=local >> $ XMODIFIERS=@im=local ./xim_root >> fevent = 0 >> topwindow = 0x2000001, window = 0x2000002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >> XSetInputFocus() is called >> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x2000002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x2000002 >> [2]w=0x2000002 >> [1]state=0x2 >> [2]state=0x2 >> State: IM Off >> ClientMessage is received >> I was expected this result. >> $ XMODIFIERS=@im=kinput2 ./xim_root >> fevent = 0x3 >> topwindow = 0x2000001, window = 0x2000002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >> XSetInputFocus() is called >> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x2000002(Internal Window) >> XSetICFocus >> KeyPress: >> ButtonPress: >> [1]w=0x200000200000000 >> [2]w=0x2000002 >> [1]state=0x200000000 >> [2]state=0x2 >> State: IM Off >> ClientMessage is received >> I'm sorry, it seemed current code did not work on even if Linux >> s390x platform. >> Thanks, >> Ichiroh Takiguchi >> On 2019-07-19 23:29, Vladimir Kempik wrote: >> Hello >> I?m probably missing something about XIM on X side here, using ssh >> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >> the output is >> fevent = 0x3 >> topwindow = 0x3800001, window = 0x3800002 >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >> XSetInputFocus() is called >> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x3800002(Internal Window) >> XSetICFocus >> FocusOut: window=0x3800002(Internal Window) >> XUnsetICFocus >> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >> ClientMessage is received >> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >> XSetInputFocus() is called >> ButtonPress: >> [1]w=0x0 >> [2]w=0x0 >> [1]state=0x0 >> [2]state=0x0 >> State: Unknown >> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >> FocusIn: window=0x3800002(Internal Window) >> I also had to press left button, not right one. >> I think when you initialy created 8213232 you were targeting linux >> ppc64 BE system in your patch and simply forgot about another 64-bit >> BE system - solaris sparc64 >> I would propose this fix for 8227919 >> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >> @@ -1671,7 +1671,7 @@ >> { >> X11InputMethodData *pX11IMData = NULL; >> char * ret = NULL; >> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >> // XIMPreeditState value which is used for XGetICValues must be >> 32bit on BigEndian XOrg's xlib >> unsigned int state = XIMPreeditUnKnown; >> #else >> Such change already allowed to pass our internal tests on solaris > sparc64 >> if you think it?s ok then let me take over and finish with 8227919 >> Thanks, Vladimir >> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >> < >> mailto:takiguc at linux.vnet.ibm.com >< >> mailto:takiguc at linux.vnet.ibm.com < >> mailto:takiguc at linux.vnet.ibm.com >>> >> ???????(?): >> Hello. >> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >> Please follow the steps: >> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >> 2. Run xim_root on desktop >> 3. Move input focus to XIM demo window >> 4. Press Ctrl key and Press Right mouse button >> Please put the output into JDK-8227919 [1] or post it into mailing list. >> I really appreciate if you are using XIM like IIIMF. >> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >> Thanks, >> Ichiroh Takiguchi > From philip.race at oracle.com Mon Jul 29 18:48:59 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 29 Jul 2019 11:48:59 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> Message-ID: <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> We seem to have lost all these legal notice lines : * - * This file is available under and governed by the GNU General Public - * License version 2 only, as published by the Free Software Foundation. - * However, the following notice accompanied the original version of this - * file and, per its terms, should not be removed: - * -phil. On 7/25/19 5:55 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 > Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 > > This is an upgrade of the libpng library to the latest version. > Most changes are just "drop and replace". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Jul 29 19:54:03 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Jul 2019 12:54:03 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> Message-ID: <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> Hi, Phil. I can move it back, but do we need this introduction? It seems we do not have such for other libraries like libjpeg. On 29.07.2019 11:48, Phil Race wrote: > We seem to have lost all these legal notice lines : > > * > - * This file is available under and governed by the GNU General Public > - * License version 2 only, as published by the Free Software Foundation. > - * However, the following notice accompanied the original version of this > - * file and, per its terms, should not be removed: > - * -phil. > > > > On 7/25/19 5:55 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for JDK 13. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >> Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 >> >> This is an upgrade of the libpng library to the latest version. >> Most changes are just "drop and replace". >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 29 20:10:44 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 29 Jul 2019 13:10:44 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> Message-ID: <14c28843-0cf8-b9f1-6fdd-c0291242a842@oracle.com> Yes, I believe we should keep it for this case. -phil. On 7/29/19 12:54 PM, Sergey Bylokhov wrote: > Hi, Phil. > I can move it back, but do we need this introduction? It seems we do > not have such for other libraries like libjpeg. > > On 29.07.2019 11:48, Phil Race wrote: >> We seem to have lost all these legal notice lines : >> >> ?? * >> - * This file is available under and governed by the GNU General Public >> - * License version 2 only, as published by the Free Software >> Foundation. >> - * However, the following notice accompanied the original version of >> this >> - * file and, per its terms, should not be removed: >> - * -phil. >> >> >> >> On 7/25/19 5:55 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for JDK 13. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >>> Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 >>> >>> This is an upgrade of the libpng library to the latest version. >>> Most changes are just "drop and replace". >>> >> > > From Sergey.Bylokhov at oracle.com Mon Jul 29 22:51:09 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Jul 2019 15:51:09 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <14c28843-0cf8-b9f1-6fdd-c0291242a842@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> <14c28843-0cf8-b9f1-6fdd-c0291242a842@oracle.com> Message-ID: <3527aebc-3aae-42bc-e263-84fd4388436b@oracle.com> The fix is updated: http://cr.openjdk.java.net/~serb/8217676/webrev.01 On 29.07.2019 13:10, Phil Race wrote: > Yes, I believe we should keep it for this case. > > -phil. > > On 7/29/19 12:54 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> I can move it back, but do we need this introduction? It seems we do not have such for other libraries like libjpeg. >> >> On 29.07.2019 11:48, Phil Race wrote: >>> We seem to have lost all these legal notice lines : >>> >>> ?? * >>> - * This file is available under and governed by the GNU General Public >>> - * License version 2 only, as published by the Free Software Foundation. >>> - * However, the following notice accompanied the original version of this >>> - * file and, per its terms, should not be removed: >>> - * -phil. >>> >>> >>> >>> On 7/25/19 5:55 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for JDK 13. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >>>> Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 >>>> >>>> This is an upgrade of the libpng library to the latest version. >>>> Most changes are just "drop and replace". >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Mon Jul 29 23:56:27 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 29 Jul 2019 16:56:27 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <3527aebc-3aae-42bc-e263-84fd4388436b@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> <14c28843-0cf8-b9f1-6fdd-c0291242a842@oracle.com> <3527aebc-3aae-42bc-e263-84fd4388436b@oracle.com> Message-ID: <5D3F87AB.2080605@oracle.com> OK +1 assuming you ran the small set of PNG SplashScreen tests we have .. -phil. On 7/29/19, 3:51 PM, Sergey Bylokhov wrote: > The fix is updated: > http://cr.openjdk.java.net/~serb/8217676/webrev.01 > > On 29.07.2019 13:10, Phil Race wrote: >> Yes, I believe we should keep it for this case. > > >> >> -phil. >> >> On 7/29/19 12:54 PM, Sergey Bylokhov wrote: >>> Hi, Phil. >>> I can move it back, but do we need this introduction? It seems we do >>> not have such for other libraries like libjpeg. >>> >>> On 29.07.2019 11:48, Phil Race wrote: >>>> We seem to have lost all these legal notice lines : >>>> >>>> * >>>> - * This file is available under and governed by the GNU General >>>> Public >>>> - * License version 2 only, as published by the Free Software >>>> Foundation. >>>> - * However, the following notice accompanied the original version >>>> of this >>>> - * file and, per its terms, should not be removed: >>>> - * -phil. >>>> >>>> >>>> >>>> On 7/25/19 5:55 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for JDK 13. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >>>>> Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 >>>>> >>>>> This is an upgrade of the libpng library to the latest version. >>>>> Most changes are just "drop and replace". >>>>> >>>> >>> >>> >> > > From kevin.rushforth at oracle.com Tue Jul 30 11:59:18 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Jul 2019 04:59:18 -0700 Subject: [13] Review Request: 8217676 Upgrade libpng to 1.6.37 In-Reply-To: <5D3F87AB.2080605@oracle.com> References: <085084e9-98d1-f18a-73a0-2a1965577bdc@oracle.com> <4e4c1e12-9d67-b5ca-10a0-1e9fe19caadf@oracle.com> <403eded1-d55e-fec2-88fa-dd39db3427cf@oracle.com> <14c28843-0cf8-b9f1-6fdd-c0291242a842@oracle.com> <3527aebc-3aae-42bc-e263-84fd4388436b@oracle.com> <5D3F87AB.2080605@oracle.com> Message-ID: <212c8c44-c89c-24ae-4047-e358a3cce88b@oracle.com> Looks fine to me, too. +1 On 7/29/2019 4:56 PM, Philip Race wrote: > OK +1 assuming you ran the small set of PNG SplashScreen tests we have .. > > -phil. > > On 7/29/19, 3:51 PM, Sergey Bylokhov wrote: >> The fix is updated: >> http://cr.openjdk.java.net/~serb/8217676/webrev.01 >> >> On 29.07.2019 13:10, Phil Race wrote: >>> Yes, I believe we should keep it for this case. >> >> >>> >>> -phil. >>> >>> On 7/29/19 12:54 PM, Sergey Bylokhov wrote: >>>> Hi, Phil. >>>> I can move it back, but do we need this introduction? It seems we >>>> do not have such for other libraries like libjpeg. >>>> >>>> On 29.07.2019 11:48, Phil Race wrote: >>>>> We seem to have lost all these legal notice lines : >>>>> >>>>> ?? * >>>>> - * This file is available under and governed by the GNU General >>>>> Public >>>>> - * License version 2 only, as published by the Free Software >>>>> Foundation. >>>>> - * However, the following notice accompanied the original version >>>>> of this >>>>> - * file and, per its terms, should not be removed: >>>>> - * -phil. >>>>> >>>>> >>>>> >>>>> On 7/25/19 5:55 PM, Sergey Bylokhov wrote: >>>>>> Hello. >>>>>> Please review the fix for JDK 13. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217676 >>>>>> Fix: http://cr.openjdk.java.net/~serb/8217676/webrev.00 >>>>>> >>>>>> This is an upgrade of the libpng library to the latest version. >>>>>> Most changes are just "drop and replace". >>>>>> >>>>> >>>> >>>> >>> >> >> From takiguc at linux.vnet.ibm.com Tue Jul 30 17:02:12 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 31 Jul 2019 02:02:12 +0900 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> Message-ID: Thanks, Vladimir. I think it's urgent issue for JDK13. Another reviewer is required. And I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi On 2019-07-29 21:49, Vladimir Kempik wrote: > Looks good to me. > Now need some reviewers to take a look at it. > Thanks, Vladimir. > >> 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi >> ???????(?): >> >> Hello Vladimir. >> I appreciate your suggestion. >> >> And I'm very sorry for bad response. >> Our mail server for external mailing list is downed in these days. >> So I'd like to use another email address. >> >> Please see following 2 outputs. >>> $ XMODIFIERS=@im=local ./xim_root >> ...... >>> ButtonPress: >>> [1]w=0x2000002 >>> [2]w=0x2000002 >>> [1]state=0x2 >>> [2]state=0x2 >> >>> $ XMODIFIERS=@im=kinput2 ./xim_root >> ...... >>> ButtonPress: >>> [1]w=0x200000200000000 >>> [2]w=0x2000002 >>> [1]state=0x200000000 >>> [2]state=0x2 >> >> These mean >> @im=local is used low 32bit on 64bit long <= The data comes from Xlib >> @im=kinput2 is used high 32bit on 64bit long <= The data comes from >> XIM >> protocol >> >> So following code changes is required on Linux s390x, it was my >> mistake. >> if (w > 0xffffffffUL) w = w >> 32; >> >> I created another fix, could you review it ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ >> >> It changes: >> * 0xffffffffL is changed to 0xffffffffUL >> * defined(__linux__) is added into defined(_LP64) line >> >> Thanks, >> ------ >> Ichiro Takiguchi >> IBM Japan Ltd. >> >> "awt-dev" wrote on 2019/07/26 >> 21:59:59: >> >>> From: Vladimir Kempik >>> To: Ichiroh Takiguchi >>> Cc: "awt-dev at openjdk.java.net" , "i18n- >>> dev at openjdk.java.net" >>> Date: 2019/07/26 22:01 >>> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >>> crashes on solaris sparc64 >>> Sent by: "awt-dev" >>> >>> Hello >>> >>> what still bothers me is this: >>> >>> The first Big Endian block: >>> >>> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> 1630 // On 64bit BigEndian, >>> 1631 // Window value may be stored on high 32bit by >>> XGetICValues via XIM >>> 1632 if (w > 0xffffffffL) w = w >> 32; >>> 1633 #endif >>> >>> is inside linux&macos block >>> >>> 1622 #if defined(__linux__) || defined(MACOSX) >> >>> >>> however the second Big Endian block is for every platform: >>> >>> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> 1699 // On 64bit BigEndian, >>> 1700 // XIMPreeditState value may be stored on high 32bit by >>> XGetICValues via XIM >>> 1701 if (state > 0xffffffffL) state = state >> 32; >>> 1702 #endif >>> I?m not sure if it?s ok or not. >>> >>> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >>> to compare it against 0xffffffffUL instead of 0xffffffffL >>> >>> typedef unsigned long int XIMPreeditState; >> >>> >>> Thanks, Vladimir >>> >>> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >>> >>> ???????(?): >>> >>> Hello. >>> >>> Could you review the fix ? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >>> >>> It's crash issue for Solaris SPARC platform. >>> If possible, please push this fix into 13. >>> >>> XIMPreditState is changed to unsigned long instead of unsigned int >>> on 64bit Big endian. >>> It's same as Java8. >>> I think Solaris SPARC's issue can be fixed by this fix. >>> >>> Vladimir, >>> I appreciate your great help. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2019-07-23 20:00, Vladimir Kempik wrote: >>> Hello >>> it still crashes with "Bus Error" >>> I guess I may miss something on X server side. >>> Thanks, Vladimir. >>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >>> >>> ???????(?): >>> Hello Vladimir. >>> I really appreciate your help. >>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>> One of document said "XMODIFIERS=@im=none" [2] >>> Could you try "XMODIFIERS=@im=none" ? >>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < >>> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >> fedoraproject.org/wiki/I18N/InputMethods> >>> Thanks, >>> Ichiroh Takiguchi >>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>> Hello >>> I?m getting Bus Error on startup with >>> XMODIFIERS=@im=local ./xim_root >>> nothing yet in log at that moment. >>> Thanks, Vladimir >>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>> >>> ???????(?): >>> Hello Vladimir. >>> I appreciate your reply. >>> I did not expect "[1]w=0x0", it means xim_root could not receive >>> focus window via XIC. >>> I checked ibus XIM server on Linux s390x platform again, it also >>> returned "[1]w=0" ... >>> I was confused. >>> I'd like to add new instruction >>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>> desktop, like >>> $ XMODIFIERS=@im=local ./xim_root >>> 6. Move input focus to XIM demo window >>> 7. Press Ctrl key and Press Right mouse button >>> I tested xim_root on Linux s390x platform. >>> $ XMODIFIERS=@im=ibus ./xim_root >>> fevent = 0x3 >>> topwindow = 0x1e00001, window = 0x1e00002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>> XSetInputFocus() is called >>> FocusOut: window=0x1e00002(Internal Window) >>> XUnsetICFocus >>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x1e00002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x0 >>> [2]w=0x0 >>> [1]state=0x0 >>> [2]state=0x0 >>> State: Unknown >>> ClientMessage is received >>> I tried it with XMODIFIERS=@im=local >>> $ XMODIFIERS=@im=local ./xim_root >>> fevent = 0 >>> topwindow = 0x2000001, window = 0x2000002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>> XSetInputFocus() is called >>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x2000002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x2000002 >>> [2]w=0x2000002 >>> [1]state=0x2 >>> [2]state=0x2 >>> State: IM Off >>> ClientMessage is received >>> I was expected this result. >>> $ XMODIFIERS=@im=kinput2 ./xim_root >>> fevent = 0x3 >>> topwindow = 0x2000001, window = 0x2000002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>> XSetInputFocus() is called >>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x2000002(Internal Window) >>> XSetICFocus >>> KeyPress: >>> ButtonPress: >>> [1]w=0x200000200000000 >>> [2]w=0x2000002 >>> [1]state=0x200000000 >>> [2]state=0x2 >>> State: IM Off >>> ClientMessage is received >>> I'm sorry, it seemed current code did not work on even if Linux >>> s390x platform. >>> Thanks, >>> Ichiroh Takiguchi >>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>> Hello >>> I?m probably missing something about XIM on X side here, using ssh >>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>> the output is >>> fevent = 0x3 >>> topwindow = 0x3800001, window = 0x3800002 >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>> XSetInputFocus() is called >>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x3800002(Internal Window) >>> XSetICFocus >>> FocusOut: window=0x3800002(Internal Window) >>> XUnsetICFocus >>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>> ClientMessage is received >>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>> XSetInputFocus() is called >>> ButtonPress: >>> [1]w=0x0 >>> [2]w=0x0 >>> [1]state=0x0 >>> [2]state=0x0 >>> State: Unknown >>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>> FocusIn: window=0x3800002(Internal Window) >>> I also had to press left button, not right one. >>> I think when you initialy created 8213232 you were targeting linux >>> ppc64 BE system in your patch and simply forgot about another 64-bit >>> BE system - solaris sparc64 >>> I would propose this fix for 8227919 >>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> @@ -1671,7 +1671,7 @@ >>> { >>> X11InputMethodData *pX11IMData = NULL; >>> char * ret = NULL; >>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>> // XIMPreeditState value which is used for XGetICValues must be >>> 32bit on BigEndian XOrg's xlib >>> unsigned int state = XIMPreeditUnKnown; >>> #else >>> Such change already allowed to pass our internal tests on solaris >> sparc64 >>> if you think it?s ok then let me take over and finish with 8227919 >>> Thanks, Vladimir >>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>> < >>> mailto:takiguc at linux.vnet.ibm.com >>> >< >>> mailto:takiguc at linux.vnet.ibm.com >>> < >>> mailto:takiguc at linux.vnet.ibm.com >>> >>> >>> ???????(?): >>> Hello. >>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>> Please follow the steps: >>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>> 2. Run xim_root on desktop >>> 3. Move input focus to XIM demo window >>> 4. Press Ctrl key and Press Right mouse button >>> Please put the output into JDK-8227919 [1] or post it into mailing >>> list. >>> I really appreciate if you are using XIM like IIIMF. >>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>> Thanks, >>> Ichiroh Takiguchi >> From philip.race at oracle.com Tue Jul 30 20:23:33 2019 From: philip.race at oracle.com (Phil Race) Date: Tue, 30 Jul 2019 13:23:33 -0700 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> Message-ID: Hi, I've stared at this fix and all this bit shifting inside ifdefs is hard to believe this is the way you have to use XIM. Also JDK 13 testing is already well under way and a lot of the testing for Linux has already been finished. So *you* are going to have to run (1) all regression tests on Linux & Solaris and that there are no new failures (2) JCK on Linux and Solaris and certify it all passes else we could have a DOA release or a release stopper. I think given that, and my observations about the fix I think that the safe option for JDK 13 is to completely back out 8213232 and try again for JDK 14. But even then I'm first going to want to see pointers to documentation for XIM which say why what you are doing is correct. -phil. On 7/30/19 10:02 AM, Ichiroh Takiguchi wrote: > Thanks, Vladimir. > > I think it's urgent issue for JDK13. > Another reviewer is required. > > And I'd like to obtain a sponsor for this issue. > > Thanks, > Ichiroh Takiguchi > > On 2019-07-29 21:49, Vladimir Kempik wrote: >> Looks good to me. >> Now need some reviewers to take a look at it. >> Thanks, Vladimir. >> >>> 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi >>> ???????(?): >>> >>> Hello Vladimir. >>> I appreciate your suggestion. >>> >>> And I'm very sorry for bad response. >>> Our mail server for external mailing list is downed in these days. >>> So I'd like to use another email address. >>> >>> Please see following 2 outputs. >>>> $ XMODIFIERS=@im=local ./xim_root >>> ...... >>>> ButtonPress: >>>> [1]w=0x2000002 >>>> [2]w=0x2000002 >>>> [1]state=0x2 >>>> [2]state=0x2 >>> >>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>> ...... >>>> ButtonPress: >>>> [1]w=0x200000200000000 >>>> [2]w=0x2000002 >>>> [1]state=0x200000000 >>>> [2]state=0x2 >>> >>> These mean >>> @im=local is used low 32bit on 64bit long? <= The data comes from Xlib >>> @im=kinput2 is used high 32bit on 64bit long? <= The data comes from >>> XIM >>> protocol >>> >>> So following code changes is required on Linux s390x, it was my >>> mistake. >>> if (w > 0xffffffffUL) w = w >> 32; >>> >>> I created another fix, could you review it ? >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8227919 >>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ >>> >>> It changes: >>> * 0xffffffffL is changed to 0xffffffffUL >>> * defined(__linux__) is added into defined(_LP64) line >>> >>> Thanks, >>> ------ >>> Ichiro Takiguchi >>> ?? IBM Japan Ltd. >>> >>> "awt-dev" wrote on 2019/07/26 >>> 21:59:59: >>> >>>> From: Vladimir Kempik >>>> To: Ichiroh Takiguchi >>>> Cc: "awt-dev at openjdk.java.net" , "i18n- >>>> dev at openjdk.java.net" >>>> Date: 2019/07/26 22:01 >>>> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >>>> crashes on solaris sparc64 >>>> Sent by: "awt-dev" >>>> >>>> Hello >>>> >>>> what still bothers me is this: >>>> >>>> The first Big Endian block: >>>> >>>> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> 1630???????? // On 64bit BigEndian, >>>> 1631???????? // Window value may be stored on high 32bit by >>>> XGetICValues via XIM >>>> 1632???????? if (w > 0xffffffffL) w = w >> 32; >>>> 1633 #endif >>>> >>>> is inside linux&macos block >>>> >>>> 1622 #if defined(__linux__) || defined(MACOSX) >>> >>>> >>>> however the second Big Endian block is for every platform: >>>> >>>> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> 1699???? // On 64bit BigEndian, >>>> 1700???? // XIMPreeditState value may be stored on high 32bit by >>>> XGetICValues via XIM >>>> 1701???? if (state > 0xffffffffL) state = state >> 32; >>>> 1702 #endif >>>> I?m not sure if it?s ok or not. >>>> >>>> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >>>> to compare it against 0xffffffffUL instead of 0xffffffffL >>>> >>>> typedef unsigned long int XIMPreeditState; >>> >>>> >>>> Thanks, Vladimir >>>> >>>> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >>>> >>>> ???????(?): >>>> >>>> Hello. >>>> >>>> Could you review the fix ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8227919 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >>>> >>>> It's crash issue for Solaris SPARC platform. >>>> If possible, please push this fix into 13. >>>> >>>> XIMPreditState is changed to unsigned long instead of unsigned int >>>> on 64bit Big endian. >>>> It's same as Java8. >>>> I think Solaris SPARC's issue can be fixed by this fix. >>>> >>>> Vladimir, >>>> I appreciate your great help. >>>> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> IBM Japan, Ltd. >>>> >>>> On 2019-07-23 20:00, Vladimir Kempik wrote: >>>> Hello >>>> it still crashes with? "Bus Error" >>>> I guess I may miss something on X server side. >>>> Thanks, Vladimir. >>>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >>>> >>>> ???????(?): >>>> Hello Vladimir. >>>> I really appreciate your help. >>>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>>> One of document said "XMODIFIERS=@im=none" [2] >>>> Could you try "XMODIFIERS=@im=none" ? >>>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < >>>> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >>>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >>> fedoraproject.org/wiki/I18N/InputMethods> >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>>> Hello >>>> I?m getting Bus Error on startup with >>>> XMODIFIERS=@im=local ./xim_root >>>> nothing yet in log at that moment. >>>> Thanks, Vladimir >>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>>> >>>> ???????(?): >>>> Hello Vladimir. >>>> I appreciate your reply. >>>> I did not expect "[1]w=0x0", it means xim_root could not receive >>>> focus window via XIC. >>>> I checked ibus XIM server on Linux s390x platform again, it also >>>> returned "[1]w=0" ... >>>> I was confused. >>>> I'd like to add new instruction >>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>>> desktop, like >>>> $ XMODIFIERS=@im=local ./xim_root >>>> 6. Move input focus to XIM demo window >>>> 7. Press Ctrl key and Press Right mouse button >>>> I tested xim_root on Linux s390x platform. >>>> $ XMODIFIERS=@im=ibus ./xim_root >>>> fevent = 0x3 >>>> topwindow = 0x1e00001, window = 0x1e00002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>> XSetInputFocus() is called >>>> FocusOut: window=0x1e00002(Internal Window) >>>> XUnsetICFocus >>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x1e00002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x0 >>>> [2]w=0x0 >>>> [1]state=0x0 >>>> [2]state=0x0 >>>> State: Unknown >>>> ClientMessage is received >>>> I tried it with XMODIFIERS=@im=local >>>> $ XMODIFIERS=@im=local ./xim_root >>>> fevent = 0 >>>> topwindow = 0x2000001, window = 0x2000002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x2000002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x2000002 >>>> [2]w=0x2000002 >>>> [1]state=0x2 >>>> [2]state=0x2 >>>> State: IM Off >>>> ClientMessage is received >>>> I was expected this result. >>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>> fevent = 0x3 >>>> topwindow = 0x2000001, window = 0x2000002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x2000002(Internal Window) >>>> XSetICFocus >>>> KeyPress: >>>> ButtonPress: >>>> [1]w=0x200000200000000 >>>> [2]w=0x2000002 >>>> [1]state=0x200000000 >>>> [2]state=0x2 >>>> State: IM Off >>>> ClientMessage is received >>>> I'm sorry, it seemed current code did not work on even if Linux >>>> s390x platform. >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>> Hello >>>> I?m probably missing something about XIM on X side here, using ssh >>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>> the output is >>>> fevent = 0x3 >>>> topwindow = 0x3800001, window = 0x3800002 >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>> XSetInputFocus() is called >>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x3800002(Internal Window) >>>> XSetICFocus >>>> FocusOut: window=0x3800002(Internal Window) >>>> XUnsetICFocus >>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>> ClientMessage is received >>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>> XSetInputFocus() is called >>>> ButtonPress: >>>> [1]w=0x0 >>>> [2]w=0x0 >>>> [1]state=0x0 >>>> [2]state=0x0 >>>> State: Unknown >>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>> FocusIn: window=0x3800002(Internal Window) >>>> I also had to press left button, not right one. >>>> I think when you initialy created 8213232 you were targeting linux >>>> ppc64 BE system in your patch and simply forgot about another 64-bit >>>> BE system - solaris sparc64 >>>> I would propose this fix for 8227919 >>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>> @@ -1671,7 +1671,7 @@ >>>> { >>>> ?X11InputMethodData *pX11IMData = NULL; >>>> ?char * ret = NULL; >>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>> ?// XIMPreeditState value which is used for XGetICValues must be >>>> 32bit on BigEndian XOrg's xlib >>>> ?unsigned int state = XIMPreeditUnKnown; >>>> #else >>>> Such change already allowed to pass our internal tests on solaris >>> sparc64 >>>> if you think it?s ok then let me take over and finish with 8227919 >>>> Thanks, Vladimir >>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>> < >>>> mailto:takiguc at linux.vnet.ibm.com >>>> >< >>>> mailto:takiguc at linux.vnet.ibm.com < >>>> mailto:takiguc at linux.vnet.ibm.com >>>> >>> >>>> ???????(?): >>>> Hello. >>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>>> Please follow the steps: >>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>> 2. Run xim_root on desktop >>>> 3. Move input focus to XIM demo window >>>> 4. Press Ctrl key and Press Right mouse button >>>> Please put the output into JDK-8227919 [1] or post it into mailing >>>> list. >>>> I really appreciate if you are using XIM like IIIMF. >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>> Thanks, >>>> Ichiroh Takiguchi >>> From takiguc at linux.vnet.ibm.com Wed Jul 31 13:43:22 2019 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Wed, 31 Jul 2019 22:43:22 +0900 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> Message-ID: <842103e858da102d655eeb460fc2a00a@linux.vnet.ibm.com> Hello Phil. I appreciate your comment. Just in case, I created another fix. It's Vladimir's idea. Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.02/ Just added "defined(__linux__)" I think it can minimize the side effect for OpenJDK testing. I'll open another bugid for Linux s390x issue. I'm not sure which is the best or better on this situation... Thanks, Ichiroh Takiguchi On 2019-07-31 05:23, Phil Race wrote: > Hi, > > I've stared at this fix and all this bit shifting inside ifdefs is > hard to believe > this is the way you have to use XIM. > > Also JDK 13 testing is already well under way and a lot of the testing > for Linux > has already been finished. So *you* are going to have to run (1) all > regression > tests on Linux & Solaris and that there are no new failures (2) JCK on > Linux and > Solaris and certify it all passes else we could have a DOA release or > a release stopper. > > I think given that, and my observations about the fix I think that the > safe option for JDK 13 is to completely back out 8213232 and try again > for JDK 14. > > But even then I'm first going to want to see pointers to documentation > for XIM which > say why what you are doing is correct. > > -phil. > > > > On 7/30/19 10:02 AM, Ichiroh Takiguchi wrote: >> Thanks, Vladimir. >> >> I think it's urgent issue for JDK13. >> Another reviewer is required. >> >> And I'd like to obtain a sponsor for this issue. >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-07-29 21:49, Vladimir Kempik wrote: >>> Looks good to me. >>> Now need some reviewers to take a look at it. >>> Thanks, Vladimir. >>> >>>> 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi >>>> ???????(?): >>>> >>>> Hello Vladimir. >>>> I appreciate your suggestion. >>>> >>>> And I'm very sorry for bad response. >>>> Our mail server for external mailing list is downed in these days. >>>> So I'd like to use another email address. >>>> >>>> Please see following 2 outputs. >>>>> $ XMODIFIERS=@im=local ./xim_root >>>> ...... >>>>> ButtonPress: >>>>> [1]w=0x2000002 >>>>> [2]w=0x2000002 >>>>> [1]state=0x2 >>>>> [2]state=0x2 >>>> >>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>> ...... >>>>> ButtonPress: >>>>> [1]w=0x200000200000000 >>>>> [2]w=0x2000002 >>>>> [1]state=0x200000000 >>>>> [2]state=0x2 >>>> >>>> These mean >>>> @im=local is used low 32bit on 64bit long? <= The data comes from >>>> Xlib >>>> @im=kinput2 is used high 32bit on 64bit long? <= The data comes >>>> from XIM >>>> protocol >>>> >>>> So following code changes is required on Linux s390x, it was my >>>> mistake. >>>> if (w > 0xffffffffUL) w = w >> 32; >>>> >>>> I created another fix, could you review it ? >>>> >>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8227919 >>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ >>>> >>>> It changes: >>>> * 0xffffffffL is changed to 0xffffffffUL >>>> * defined(__linux__) is added into defined(_LP64) line >>>> >>>> Thanks, >>>> ------ >>>> Ichiro Takiguchi >>>> ?? IBM Japan Ltd. >>>> >>>> "awt-dev" wrote on 2019/07/26 >>>> 21:59:59: >>>> >>>>> From: Vladimir Kempik >>>>> To: Ichiroh Takiguchi >>>>> Cc: "awt-dev at openjdk.java.net" , "i18n- >>>>> dev at openjdk.java.net" >>>>> Date: 2019/07/26 22:01 >>>>> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >>>>> crashes on solaris sparc64 >>>>> Sent by: "awt-dev" >>>>> >>>>> Hello >>>>> >>>>> what still bothers me is this: >>>>> >>>>> The first Big Endian block: >>>>> >>>>> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>> 1630???????? // On 64bit BigEndian, >>>>> 1631???????? // Window value may be stored on high 32bit by >>>>> XGetICValues via XIM >>>>> 1632???????? if (w > 0xffffffffL) w = w >> 32; >>>>> 1633 #endif >>>>> >>>>> is inside linux&macos block >>>>> >>>>> 1622 #if defined(__linux__) || defined(MACOSX) >>>> >>>>> >>>>> however the second Big Endian block is for every platform: >>>>> >>>>> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>> 1699???? // On 64bit BigEndian, >>>>> 1700???? // XIMPreeditState value may be stored on high 32bit >>>>> by >>>>> XGetICValues via XIM >>>>> 1701???? if (state > 0xffffffffL) state = state >> 32; >>>>> 1702 #endif >>>>> I?m not sure if it?s ok or not. >>>>> >>>>> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >>>>> to compare it against 0xffffffffUL instead of 0xffffffffL >>>>> >>>>> typedef unsigned long int XIMPreeditState; >>>> >>>>> >>>>> Thanks, Vladimir >>>>> >>>>> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >>>>> >>>>> ???????(?): >>>>> >>>>> Hello. >>>>> >>>>> Could you review the fix ? >>>>> >>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >>>>> >>>>> It's crash issue for Solaris SPARC platform. >>>>> If possible, please push this fix into 13. >>>>> >>>>> XIMPreditState is changed to unsigned long instead of unsigned int >>>>> on 64bit Big endian. >>>>> It's same as Java8. >>>>> I think Solaris SPARC's issue can be fixed by this fix. >>>>> >>>>> Vladimir, >>>>> I appreciate your great help. >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> On 2019-07-23 20:00, Vladimir Kempik wrote: >>>>> Hello >>>>> it still crashes with? "Bus Error" >>>>> I guess I may miss something on X server side. >>>>> Thanks, Vladimir. >>>>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >>>>> >>>>> ???????(?): >>>>> Hello Vladimir. >>>>> I really appreciate your help. >>>>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>>>> One of document said "XMODIFIERS=@im=none" [2] >>>>> Could you try "XMODIFIERS=@im=none" ? >>>>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml >>>>> < >>>>> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >>>>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >>>> fedoraproject.org/wiki/I18N/InputMethods> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>>>> Hello >>>>> I?m getting Bus Error on startup with >>>>> XMODIFIERS=@im=local ./xim_root >>>>> nothing yet in log at that moment. >>>>> Thanks, Vladimir >>>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>>>> >>>>> ???????(?): >>>>> Hello Vladimir. >>>>> I appreciate your reply. >>>>> I did not expect "[1]w=0x0", it means xim_root could not receive >>>>> focus window via XIC. >>>>> I checked ibus XIM server on Linux s390x platform again, it also >>>>> returned "[1]w=0" ... >>>>> I was confused. >>>>> I'd like to add new instruction >>>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>>>> desktop, like >>>>> $ XMODIFIERS=@im=local ./xim_root >>>>> 6. Move input focus to XIM demo window >>>>> 7. Press Ctrl key and Press Right mouse button >>>>> I tested xim_root on Linux s390x platform. >>>>> $ XMODIFIERS=@im=ibus ./xim_root >>>>> fevent = 0x3 >>>>> topwindow = 0x1e00001, window = 0x1e00002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>>> XSetInputFocus() is called >>>>> FocusOut: window=0x1e00002(Internal Window) >>>>> XUnsetICFocus >>>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x1e00002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x0 >>>>> [2]w=0x0 >>>>> [1]state=0x0 >>>>> [2]state=0x0 >>>>> State: Unknown >>>>> ClientMessage is received >>>>> I tried it with XMODIFIERS=@im=local >>>>> $ XMODIFIERS=@im=local ./xim_root >>>>> fevent = 0 >>>>> topwindow = 0x2000001, window = 0x2000002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x2000002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x2000002 >>>>> [2]w=0x2000002 >>>>> [1]state=0x2 >>>>> [2]state=0x2 >>>>> State: IM Off >>>>> ClientMessage is received >>>>> I was expected this result. >>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>> fevent = 0x3 >>>>> topwindow = 0x2000001, window = 0x2000002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x2000002(Internal Window) >>>>> XSetICFocus >>>>> KeyPress: >>>>> ButtonPress: >>>>> [1]w=0x200000200000000 >>>>> [2]w=0x2000002 >>>>> [1]state=0x200000000 >>>>> [2]state=0x2 >>>>> State: IM Off >>>>> ClientMessage is received >>>>> I'm sorry, it seemed current code did not work on even if Linux >>>>> s390x platform. >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>>> Hello >>>>> I?m probably missing something about XIM on X side here, using ssh >>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>>> the output is >>>>> fevent = 0x3 >>>>> topwindow = 0x3800001, window = 0x3800002 >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>>> XSetInputFocus() is called >>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x3800002(Internal Window) >>>>> XSetICFocus >>>>> FocusOut: window=0x3800002(Internal Window) >>>>> XUnsetICFocus >>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> ClientMessage is received >>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>>> XSetInputFocus() is called >>>>> ButtonPress: >>>>> [1]w=0x0 >>>>> [2]w=0x0 >>>>> [1]state=0x0 >>>>> [2]state=0x0 >>>>> State: Unknown >>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>> FocusIn: window=0x3800002(Internal Window) >>>>> I also had to press left button, not right one. >>>>> I think when you initialy created 8213232 you were targeting linux >>>>> ppc64 BE system in your patch and simply forgot about another >>>>> 64-bit >>>>> BE system - solaris sparc64 >>>>> I would propose this fix for 8227919 >>>>> --- >>>>> a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> +++ >>>>> b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>> @@ -1671,7 +1671,7 @@ >>>>> { >>>>> ?X11InputMethodData *pX11IMData = NULL; >>>>> ?char * ret = NULL; >>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>> +#if defined(__linux__) && defined(_LP64) && >>>>> !defined(_LITTLE_ENDIAN) >>>>> ?// XIMPreeditState value which is used for XGetICValues must be >>>>> 32bit on BigEndian XOrg's xlib >>>>> ?unsigned int state = XIMPreeditUnKnown; >>>>> #else >>>>> Such change already allowed to pass our internal tests on solaris >>>> sparc64 >>>>> if you think it?s ok then let me take over and finish with 8227919 >>>>> Thanks, Vladimir >>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>>> < >>>>> mailto:takiguc at linux.vnet.ibm.com >>>>> >< >>>>> mailto:takiguc at linux.vnet.ibm.com >>>>> < >>>>> mailto:takiguc at linux.vnet.ibm.com >>>>> >>> >>>>> ???????(?): >>>>> Hello. >>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 >>>>> [1] >>>>> Please follow the steps: >>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>>> 2. Run xim_root on desktop >>>>> 3. Move input focus to XIM demo window >>>>> 4. Press Ctrl key and Press Right mouse button >>>>> Please put the output into JDK-8227919 [1] or post it into mailing >>>>> list. >>>>> I really appreciate if you are using XIM like IIIMF. >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>> From vkempik at azul.com Wed Jul 31 15:40:14 2019 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 31 Jul 2019 15:40:14 +0000 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: <842103e858da102d655eeb460fc2a00a@linux.vnet.ibm.com> References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> <842103e858da102d655eeb460fc2a00a@linux.vnet.ibm.com> Message-ID: <0D098FAF-5180-4308-8C6B-81A1DA35C668@azul.com> Hello In fact such minimalistic change only affects code generation on solaris sparc64 We have tested such fix on openjdk-11.0.4 with solaris sparc64 and it passed tck just fine. Vladimir. > 31 ???? 2019 ?., ? 16:43, Ichiroh Takiguchi ???????(?): > > Hello Phil. > > I appreciate your comment. > > Just in case, I created another fix. > It's Vladimir's idea. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 > Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.02/ > > Just added "defined(__linux__)" > > I think it can minimize the side effect for OpenJDK testing. > I'll open another bugid for Linux s390x issue. > > I'm not sure which is the best or better on this situation... > > Thanks, > Ichiroh Takiguchi > > On 2019-07-31 05:23, Phil Race wrote: >> Hi, >> I've stared at this fix and all this bit shifting inside ifdefs is >> hard to believe >> this is the way you have to use XIM. >> Also JDK 13 testing is already well under way and a lot of the testing for Linux >> has already been finished. So *you* are going to have to run (1) all regression >> tests on Linux & Solaris and that there are no new failures (2) JCK on Linux and >> Solaris and certify it all passes else we could have a DOA release or >> a release stopper. >> I think given that, and my observations about the fix I think that the >> safe option for JDK 13 is to completely back out 8213232 and try again >> for JDK 14. >> But even then I'm first going to want to see pointers to documentation >> for XIM which >> say why what you are doing is correct. >> -phil. >> On 7/30/19 10:02 AM, Ichiroh Takiguchi wrote: >>> Thanks, Vladimir. >>> I think it's urgent issue for JDK13. >>> Another reviewer is required. >>> And I'd like to obtain a sponsor for this issue. >>> Thanks, >>> Ichiroh Takiguchi >>> On 2019-07-29 21:49, Vladimir Kempik wrote: >>>> Looks good to me. >>>> Now need some reviewers to take a look at it. >>>> Thanks, Vladimir. >>>>> 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi ???????(?): >>>>> Hello Vladimir. >>>>> I appreciate your suggestion. >>>>> And I'm very sorry for bad response. >>>>> Our mail server for external mailing list is downed in these days. >>>>> So I'd like to use another email address. >>>>> Please see following 2 outputs. >>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>> ...... >>>>>> ButtonPress: >>>>>> [1]w=0x2000002 >>>>>> [2]w=0x2000002 >>>>>> [1]state=0x2 >>>>>> [2]state=0x2 >>>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>> ...... >>>>>> ButtonPress: >>>>>> [1]w=0x200000200000000 >>>>>> [2]w=0x2000002 >>>>>> [1]state=0x200000000 >>>>>> [2]state=0x2 >>>>> These mean >>>>> @im=local is used low 32bit on 64bit long <= The data comes from Xlib >>>>> @im=kinput2 is used high 32bit on 64bit long <= The data comes from XIM >>>>> protocol >>>>> So following code changes is required on Linux s390x, it was my mistake. >>>>> if (w > 0xffffffffUL) w = w >> 32; >>>>> I created another fix, could you review it ? >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ >>>>> It changes: >>>>> * 0xffffffffL is changed to 0xffffffffUL >>>>> * defined(__linux__) is added into defined(_LP64) line >>>>> Thanks, >>>>> ------ >>>>> Ichiro Takiguchi >>>>> IBM Japan Ltd. >>>>> "awt-dev" wrote on 2019/07/26 21:59:59: >>>>>> From: Vladimir Kempik >>>>>> To: Ichiroh Takiguchi >>>>>> Cc: "awt-dev at openjdk.java.net" , "i18n- >>>>>> dev at openjdk.java.net" >>>>>> Date: 2019/07/26 22:01 >>>>>> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >>>>>> crashes on solaris sparc64 >>>>>> Sent by: "awt-dev" >>>>>> Hello >>>>>> what still bothers me is this: >>>>>> The first Big Endian block: >>>>>> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> 1630 // On 64bit BigEndian, >>>>>> 1631 // Window value may be stored on high 32bit by >>>>>> XGetICValues via XIM >>>>>> 1632 if (w > 0xffffffffL) w = w >> 32; >>>>>> 1633 #endif >>>>>> is inside linux&macos block >>>>>> 1622 #if defined(__linux__) || defined(MACOSX) >>>>>> however the second Big Endian block is for every platform: >>>>>> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> 1699 // On 64bit BigEndian, >>>>>> 1700 // XIMPreeditState value may be stored on high 32bit by >>>>>> XGetICValues via XIM >>>>>> 1701 if (state > 0xffffffffL) state = state >> 32; >>>>>> 1702 #endif >>>>>> I?m not sure if it?s ok or not. >>>>>> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >>>>>> to compare it against 0xffffffffUL instead of 0xffffffffL >>>>>> typedef unsigned long int XIMPreeditState; >>>>>> Thanks, Vladimir >>>>>> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >>>>>> ???????(?): >>>>>> Hello. >>>>>> Could you review the fix ? >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >>>>>> It's crash issue for Solaris SPARC platform. >>>>>> If possible, please push this fix into 13. >>>>>> XIMPreditState is changed to unsigned long instead of unsigned int >>>>>> on 64bit Big endian. >>>>>> It's same as Java8. >>>>>> I think Solaris SPARC's issue can be fixed by this fix. >>>>>> Vladimir, >>>>>> I appreciate your great help. >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> IBM Japan, Ltd. >>>>>> On 2019-07-23 20:00, Vladimir Kempik wrote: >>>>>> Hello >>>>>> it still crashes with "Bus Error" >>>>>> I guess I may miss something on X server side. >>>>>> Thanks, Vladimir. >>>>>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >>>>>> ???????(?): >>>>>> Hello Vladimir. >>>>>> I really appreciate your help. >>>>>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>>>>> One of document said "XMODIFIERS=@im=none" [2] >>>>>> Could you try "XMODIFIERS=@im=none" ? >>>>>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < >>>>>> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >>>>>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >>>>> fedoraproject.org/wiki/I18N/InputMethods> >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>>>>> Hello >>>>>> I?m getting Bus Error on startup with >>>>>> XMODIFIERS=@im=local ./xim_root >>>>>> nothing yet in log at that moment. >>>>>> Thanks, Vladimir >>>>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>>>>> ???????(?): >>>>>> Hello Vladimir. >>>>>> I appreciate your reply. >>>>>> I did not expect "[1]w=0x0", it means xim_root could not receive >>>>>> focus window via XIC. >>>>>> I checked ibus XIM server on Linux s390x platform again, it also >>>>>> returned "[1]w=0" ... >>>>>> I was confused. >>>>>> I'd like to add new instruction >>>>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>>>>> desktop, like >>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>>> 6. Move input focus to XIM demo window >>>>>> 7. Press Ctrl key and Press Right mouse button >>>>>> I tested xim_root on Linux s390x platform. >>>>>> $ XMODIFIERS=@im=ibus ./xim_root >>>>>> fevent = 0x3 >>>>>> topwindow = 0x1e00001, window = 0x1e00002 >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>>>> XSetInputFocus() is called >>>>>> FocusOut: window=0x1e00002(Internal Window) >>>>>> XUnsetICFocus >>>>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x1e00002(Internal Window) >>>>>> XSetICFocus >>>>>> KeyPress: >>>>>> ButtonPress: >>>>>> [1]w=0x0 >>>>>> [2]w=0x0 >>>>>> [1]state=0x0 >>>>>> [2]state=0x0 >>>>>> State: Unknown >>>>>> ClientMessage is received >>>>>> I tried it with XMODIFIERS=@im=local >>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>>> fevent = 0 >>>>>> topwindow = 0x2000001, window = 0x2000002 >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>>>> XSetInputFocus() is called >>>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x2000002(Internal Window) >>>>>> XSetICFocus >>>>>> KeyPress: >>>>>> ButtonPress: >>>>>> [1]w=0x2000002 >>>>>> [2]w=0x2000002 >>>>>> [1]state=0x2 >>>>>> [2]state=0x2 >>>>>> State: IM Off >>>>>> ClientMessage is received >>>>>> I was expected this result. >>>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>>> fevent = 0x3 >>>>>> topwindow = 0x2000001, window = 0x2000002 >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>>>> XSetInputFocus() is called >>>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x2000002(Internal Window) >>>>>> XSetICFocus >>>>>> KeyPress: >>>>>> ButtonPress: >>>>>> [1]w=0x200000200000000 >>>>>> [2]w=0x2000002 >>>>>> [1]state=0x200000000 >>>>>> [2]state=0x2 >>>>>> State: IM Off >>>>>> ClientMessage is received >>>>>> I'm sorry, it seemed current code did not work on even if Linux >>>>>> s390x platform. >>>>>> Thanks, >>>>>> Ichiroh Takiguchi >>>>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>>>> Hello >>>>>> I?m probably missing something about XIM on X side here, using ssh >>>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>>>> the output is >>>>>> fevent = 0x3 >>>>>> topwindow = 0x3800001, window = 0x3800002 >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>>>> XSetInputFocus() is called >>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>> XSetICFocus >>>>>> FocusOut: window=0x3800002(Internal Window) >>>>>> XUnsetICFocus >>>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> ClientMessage is received >>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>>>> XSetInputFocus() is called >>>>>> ButtonPress: >>>>>> [1]w=0x0 >>>>>> [2]w=0x0 >>>>>> [1]state=0x0 >>>>>> [2]state=0x0 >>>>>> State: Unknown >>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>> I also had to press left button, not right one. >>>>>> I think when you initialy created 8213232 you were targeting linux >>>>>> ppc64 BE system in your patch and simply forgot about another 64-bit >>>>>> BE system - solaris sparc64 >>>>>> I would propose this fix for 8227919 >>>>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>> @@ -1671,7 +1671,7 @@ >>>>>> { >>>>>> X11InputMethodData *pX11IMData = NULL; >>>>>> char * ret = NULL; >>>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>> // XIMPreeditState value which is used for XGetICValues must be >>>>>> 32bit on BigEndian XOrg's xlib >>>>>> unsigned int state = XIMPreeditUnKnown; >>>>>> #else >>>>>> Such change already allowed to pass our internal tests on solaris >>>>> sparc64 >>>>>> if you think it?s ok then let me take over and finish with 8227919 >>>>>> Thanks, Vladimir >>>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>>>> < >>>>>> mailto:takiguc at linux.vnet.ibm.com >< >>>>>> mailto:takiguc at linux.vnet.ibm.com < >>>>>> mailto:takiguc at linux.vnet.ibm.com >>> >>>>>> ???????(?): >>>>>> Hello. >>>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>>>>> Please follow the steps: >>>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>>>> 2. Run xim_root on desktop >>>>>> 3. Move input focus to XIM demo window >>>>>> 4. Press Ctrl key and Press Right mouse button >>>>>> Please put the output into JDK-8227919 [1] or post it into mailing list. >>>>>> I really appreciate if you are using XIM like IIIMF. >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>>>> Thanks, >>>>>> Ichiroh Takiguchi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From philip.race at oracle.com Wed Jul 31 17:45:01 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 31 Jul 2019 10:45:01 -0700 Subject: RFR [13] 8227919: 8213232 causes crashes on solaris sparc64 In-Reply-To: <0D098FAF-5180-4308-8C6B-81A1DA35C668@azul.com> References: <5D43C3E4-E797-45C8-83BB-55D8C39D5B7C@azul.com> <56EA449C-BDBD-4D44-9066-6CC4ED135445@azul.com> <1C3AD1B3-58FF-4C37-BDDC-35C97CACC357@azul.com> <842103e858da102d655eeb460fc2a00a@linux.vnet.ibm.com> <0D098FAF-5180-4308-8C6B-81A1DA35C668@azul.com> Message-ID: <9329a57f-d898-f186-fe43-bf1e3d833e05@oracle.com> Ok, that looks a lot more sane. You (Ichiroh) will need to follow the JDK 13 fix request process here : http://openjdk.java.net/jeps/3#Fix-Request-Process An example of a recent case is https://bugs.openjdk.java.net/browse/JDK-8217676 Also remember you fix this ONLY in JDK 13. The fix will be forwarded synced by integrators here into JDK 14. -phil. On 7/31/19 8:40 AM, Vladimir Kempik wrote: > Hello > > In fact such minimalistic change only affects code generation on solaris sparc64 > > We have tested such fix on openjdk-11.0.4 with solaris sparc64 and it passed tck just fine. > > Vladimir. > >> 31 ???? 2019 ?., ? 16:43, Ichiroh Takiguchi ???????(?): >> >> Hello Phil. >> >> I appreciate your comment. >> >> Just in case, I created another fix. >> It's Vladimir's idea. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.02/ >> >> Just added "defined(__linux__)" >> >> I think it can minimize the side effect for OpenJDK testing. >> I'll open another bugid for Linux s390x issue. >> >> I'm not sure which is the best or better on this situation... >> >> Thanks, >> Ichiroh Takiguchi >> >> On 2019-07-31 05:23, Phil Race wrote: >>> Hi, >>> I've stared at this fix and all this bit shifting inside ifdefs is >>> hard to believe >>> this is the way you have to use XIM. >>> Also JDK 13 testing is already well under way and a lot of the testing for Linux >>> has already been finished. So *you* are going to have to run (1) all regression >>> tests on Linux & Solaris and that there are no new failures (2) JCK on Linux and >>> Solaris and certify it all passes else we could have a DOA release or >>> a release stopper. >>> I think given that, and my observations about the fix I think that the >>> safe option for JDK 13 is to completely back out 8213232 and try again >>> for JDK 14. >>> But even then I'm first going to want to see pointers to documentation >>> for XIM which >>> say why what you are doing is correct. >>> -phil. >>> On 7/30/19 10:02 AM, Ichiroh Takiguchi wrote: >>>> Thanks, Vladimir. >>>> I think it's urgent issue for JDK13. >>>> Another reviewer is required. >>>> And I'd like to obtain a sponsor for this issue. >>>> Thanks, >>>> Ichiroh Takiguchi >>>> On 2019-07-29 21:49, Vladimir Kempik wrote: >>>>> Looks good to me. >>>>> Now need some reviewers to take a look at it. >>>>> Thanks, Vladimir. >>>>>> 29 ???? 2019 ?., ? 15:44, Ichiroh Takiguchi ???????(?): >>>>>> Hello Vladimir. >>>>>> I appreciate your suggestion. >>>>>> And I'm very sorry for bad response. >>>>>> Our mail server for external mailing list is downed in these days. >>>>>> So I'd like to use another email address. >>>>>> Please see following 2 outputs. >>>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>>> ...... >>>>>>> ButtonPress: >>>>>>> [1]w=0x2000002 >>>>>>> [2]w=0x2000002 >>>>>>> [1]state=0x2 >>>>>>> [2]state=0x2 >>>>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>>> ...... >>>>>>> ButtonPress: >>>>>>> [1]w=0x200000200000000 >>>>>>> [2]w=0x2000002 >>>>>>> [1]state=0x200000000 >>>>>>> [2]state=0x2 >>>>>> These mean >>>>>> @im=local is used low 32bit on 64bit long <= The data comes from Xlib >>>>>> @im=kinput2 is used high 32bit on 64bit long <= The data comes from XIM >>>>>> protocol >>>>>> So following code changes is required on Linux s390x, it was my mistake. >>>>>> if (w > 0xffffffffUL) w = w >> 32; >>>>>> I created another fix, could you review it ? >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.01/ >>>>>> It changes: >>>>>> * 0xffffffffL is changed to 0xffffffffUL >>>>>> * defined(__linux__) is added into defined(_LP64) line >>>>>> Thanks, >>>>>> ------ >>>>>> Ichiro Takiguchi >>>>>> IBM Japan Ltd. >>>>>> "awt-dev" wrote on 2019/07/26 21:59:59: >>>>>>> From: Vladimir Kempik >>>>>>> To: Ichiroh Takiguchi >>>>>>> Cc: "awt-dev at openjdk.java.net" , "i18n- >>>>>>> dev at openjdk.java.net" >>>>>>> Date: 2019/07/26 22:01 >>>>>>> Subject: [EXTERNAL] Re: RFR [13] 8227919: 8213232 causes >>>>>>> crashes on solaris sparc64 >>>>>>> Sent by: "awt-dev" >>>>>>> Hello >>>>>>> what still bothers me is this: >>>>>>> The first Big Endian block: >>>>>>> 1629 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>>> 1630 // On 64bit BigEndian, >>>>>>> 1631 // Window value may be stored on high 32bit by >>>>>>> XGetICValues via XIM >>>>>>> 1632 if (w > 0xffffffffL) w = w >> 32; >>>>>>> 1633 #endif >>>>>>> is inside linux&macos block >>>>>>> 1622 #if defined(__linux__) || defined(MACOSX) >>>>>>> however the second Big Endian block is for every platform: >>>>>>> 1698 #if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>>> 1699 // On 64bit BigEndian, >>>>>>> 1700 // XIMPreeditState value may be stored on high 32bit by >>>>>>> XGetICValues via XIM >>>>>>> 1701 if (state > 0xffffffffL) state = state >> 32; >>>>>>> 1702 #endif >>>>>>> I?m not sure if it?s ok or not. >>>>>>> Also, since XIMPreeditState is unsigned 64-bit int, I think we need >>>>>>> to compare it against 0xffffffffUL instead of 0xffffffffL >>>>>>> typedef unsigned long int XIMPreeditState; >>>>>>> Thanks, Vladimir >>>>>>> 26 ???? 2019 ?., ? 15:53, Ichiroh Takiguchi >>>>>>> ???????(?): >>>>>>> Hello. >>>>>>> Could you review the fix ? >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8227919/webrev.00/ >>>>>>> It's crash issue for Solaris SPARC platform. >>>>>>> If possible, please push this fix into 13. >>>>>>> XIMPreditState is changed to unsigned long instead of unsigned int >>>>>>> on 64bit Big endian. >>>>>>> It's same as Java8. >>>>>>> I think Solaris SPARC's issue can be fixed by this fix. >>>>>>> Vladimir, >>>>>>> I appreciate your great help. >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> IBM Japan, Ltd. >>>>>>> On 2019-07-23 20:00, Vladimir Kempik wrote: >>>>>>> Hello >>>>>>> it still crashes with "Bus Error" >>>>>>> I guess I may miss something on X server side. >>>>>>> Thanks, Vladimir. >>>>>>> 22 ???? 2019 ?., ? 21:08, Ichiroh Takiguchi >>>>>>> ???????(?): >>>>>>> Hello Vladimir. >>>>>>> I really appreciate your help. >>>>>>> "XMODIFIERS=@im=local" is related Multi key Compose feature [1] >>>>>>> One of document said "XMODIFIERS=@im=none" [2] >>>>>>> Could you try "XMODIFIERS=@im=none" ? >>>>>>> [1] https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml < >>>>>>> https://www.x.org/releases/current/doc/man/man5/Compose.5.xhtml> >>>>>>> [2] https://fedoraproject.org/wiki/I18N/InputMethods >>>>>> fedoraproject.org/wiki/I18N/InputMethods> >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> On 2019-07-22 23:58, Vladimir Kempik wrote: >>>>>>> Hello >>>>>>> I?m getting Bus Error on startup with >>>>>>> XMODIFIERS=@im=local ./xim_root >>>>>>> nothing yet in log at that moment. >>>>>>> Thanks, Vladimir >>>>>>> 22 ???? 2019 ?., ? 15:12, Ichiroh Takiguchi >>>>>>> ???????(?): >>>>>>> Hello Vladimir. >>>>>>> I appreciate your reply. >>>>>>> I did not expect "[1]w=0x0", it means xim_root could not receive >>>>>>> focus window via XIC. >>>>>>> I checked ibus XIM server on Linux s390x platform again, it also >>>>>>> returned "[1]w=0" ... >>>>>>> I was confused. >>>>>>> I'd like to add new instruction >>>>>>> 5. Run xim_root with XMODIFIERS=@im=local environment variable on >>>>>>> desktop, like >>>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>>>> 6. Move input focus to XIM demo window >>>>>>> 7. Press Ctrl key and Press Right mouse button >>>>>>> I tested xim_root on Linux s390x platform. >>>>>>> $ XMODIFIERS=@im=ibus ./xim_root >>>>>>> fevent = 0x3 >>>>>>> topwindow = 0x1e00001, window = 0x1e00002 >>>>>>> ClientMessage is received >>>>>>> WM_TAKE_FOCUS is received, window=0x1e00002, timestamp=1470262945 >>>>>>> XSetInputFocus() is called >>>>>>> FocusOut: window=0x1e00002(Internal Window) >>>>>>> XUnsetICFocus >>>>>>> FocusOut: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x1e00001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x1e00002(Internal Window) >>>>>>> XSetICFocus >>>>>>> KeyPress: >>>>>>> ButtonPress: >>>>>>> [1]w=0x0 >>>>>>> [2]w=0x0 >>>>>>> [1]state=0x0 >>>>>>> [2]state=0x0 >>>>>>> State: Unknown >>>>>>> ClientMessage is received >>>>>>> I tried it with XMODIFIERS=@im=local >>>>>>> $ XMODIFIERS=@im=local ./xim_root >>>>>>> fevent = 0 >>>>>>> topwindow = 0x2000001, window = 0x2000002 >>>>>>> ClientMessage is received >>>>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470356372 >>>>>>> XSetInputFocus() is called >>>>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x2000002(Internal Window) >>>>>>> XSetICFocus >>>>>>> KeyPress: >>>>>>> ButtonPress: >>>>>>> [1]w=0x2000002 >>>>>>> [2]w=0x2000002 >>>>>>> [1]state=0x2 >>>>>>> [2]state=0x2 >>>>>>> State: IM Off >>>>>>> ClientMessage is received >>>>>>> I was expected this result. >>>>>>> $ XMODIFIERS=@im=kinput2 ./xim_root >>>>>>> fevent = 0x3 >>>>>>> topwindow = 0x2000001, window = 0x2000002 >>>>>>> ClientMessage is received >>>>>>> WM_TAKE_FOCUS is received, window=0x2000002, timestamp=1470386128 >>>>>>> XSetInputFocus() is called >>>>>>> FocusIn: window=0x2000001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x2000002(Internal Window) >>>>>>> XSetICFocus >>>>>>> KeyPress: >>>>>>> ButtonPress: >>>>>>> [1]w=0x200000200000000 >>>>>>> [2]w=0x2000002 >>>>>>> [1]state=0x200000000 >>>>>>> [2]state=0x2 >>>>>>> State: IM Off >>>>>>> ClientMessage is received >>>>>>> I'm sorry, it seemed current code did not work on even if Linux >>>>>>> s390x platform. >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi >>>>>>> On 2019-07-19 23:29, Vladimir Kempik wrote: >>>>>>> Hello >>>>>>> I?m probably missing something about XIM on X side here, using ssh >>>>>>> -X from ubuntu(with Xserver) to solaris11 sparc64 machine >>>>>>> the output is >>>>>>> fevent = 0x3 >>>>>>> topwindow = 0x3800001, window = 0x3800002 >>>>>>> ClientMessage is received >>>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3262503 >>>>>>> XSetInputFocus() is called >>>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>>> XSetICFocus >>>>>>> FocusOut: window=0x3800002(Internal Window) >>>>>>> XUnsetICFocus >>>>>>> FocusOut: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>>> ClientMessage is received >>>>>>> WM_TAKE_FOCUS is received, window=0x3800002, timestamp=3267238 >>>>>>> XSetInputFocus() is called >>>>>>> ButtonPress: >>>>>>> [1]w=0x0 >>>>>>> [2]w=0x0 >>>>>>> [1]state=0x0 >>>>>>> [2]state=0x0 >>>>>>> State: Unknown >>>>>>> FocusIn: window=0x3800001(XIM demo - root-im window - 64bit) >>>>>>> FocusIn: window=0x3800002(Internal Window) >>>>>>> I also had to press left button, not right one. >>>>>>> I think when you initialy created 8213232 you were targeting linux >>>>>>> ppc64 BE system in your patch and simply forgot about another 64-bit >>>>>>> BE system - solaris sparc64 >>>>>>> I would propose this fix for 8227919 >>>>>>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>>> @@ -1671,7 +1671,7 @@ >>>>>>> { >>>>>>> X11InputMethodData *pX11IMData = NULL; >>>>>>> char * ret = NULL; >>>>>>> -#if defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>>> +#if defined(__linux__) && defined(_LP64) && !defined(_LITTLE_ENDIAN) >>>>>>> // XIMPreeditState value which is used for XGetICValues must be >>>>>>> 32bit on BigEndian XOrg's xlib >>>>>>> unsigned int state = XIMPreeditUnKnown; >>>>>>> #else >>>>>>> Such change already allowed to pass our internal tests on solaris >>>>>> sparc64 >>>>>>> if you think it?s ok then let me take over and finish with 8227919 >>>>>>> Thanks, Vladimir >>>>>>> 19 ???? 2019 ?., ? 16:57, Ichiroh Takiguchi >>>>>>> < >>>>>>> mailto:takiguc at linux.vnet.ibm.com >< >>>>>>> mailto:takiguc at linux.vnet.ibm.com < >>>>>>> mailto:takiguc at linux.vnet.ibm.com >>> >>>>>>> ???????(?): >>>>>>> Hello. >>>>>>> I need Solaris 64bit SPARC desktop user volunteer for jdk-8227919 [1] >>>>>>> Please follow the steps: >>>>>>> 1. Download xim_root.c [2] and compile it on Solaris 64bit SPARC >>>>>>> 2. Run xim_root on desktop >>>>>>> 3. Move input focus to XIM demo window >>>>>>> 4. Press Ctrl key and Press Right mouse button >>>>>>> Please put the output into JDK-8227919 [1] or post it into mailing list. >>>>>>> I really appreciate if you are using XIM like IIIMF. >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8227919 >>>>>>> [2] https://cr.openjdk.java.net/~itakiguchi/8227919/xim_root.c >>>>>>> Thanks, >>>>>>> Ichiroh Takiguchi