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: [OpenJDK 2D-Dev] [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 alexey.ivanov at oracle.com Tue Jul 2 12:18:58 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Tue, 2 Jul 2019 13:18:58 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> Message-ID: <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> Are there any other comments? Other volunteers for reviewing? Thanks in advance. On 25/06/2019 20:17, Alexey Ivanov wrote: > Please see the updated webrev: > http://cr.openjdk.java.net/~aivanov/8222108/webrev.01/ > > On 25/06/2019 00:01, Sergey Bylokhov wrote: >> On 24/06/2019 14:50, Alexey Ivanov wrote: >>>> I guess that the change in doCompare() passed a review because it >>>> was assumed that the code inside will take care of unordered >>>> arrays. if we will drop the doCompare() then probably we need to >>>> sort the content of the arrays before Arrays.equals()? >>> >>> I can't see where doCompare() handled unordered arrays; quite the >>> opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"}) >>> returns true (that is the arrays are *not equal*) whereas the arrays >>> are *equal*. >> >> That was an assumption on how it should work, but it was implemented >> differently. > > I see. > >>> While I run the test, the list of printers always has the same >>> order. We do not sort the array returned by getAllPrinterNames() in >>> PrintServiceLookupProvider.refreshServices(), so I assume Windows >>> returns the installed printers in the same order. Therefore I think >>> sorting the array is not necessary in this case. >> I do not know, if it is always has the same order then the fix look >> fine, if we unsure then probably we can tweak it and sort. > > The order in which printers are enumerated by EnumPrinters is > unspecified. For level 4, the information is queried from the > registry. The order for registry enum functions is not guaranteed > either. Even though the order of printers has always been the same so > far, we cannot rely on this fact. -- Regards, Alexey From philip.race at oracle.com Tue Jul 2 23:13:33 2019 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Jul 2019 16:13:33 -0700 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> Message-ID: <5D1BE51D.9050202@oracle.com> I thought we had the checks for null in doCompare there for a reason. Arrays.sort won't be very happy with a null element. You said in the first review email of the v0 webrev : > Arrays.equals() accepts null parameters and null elements in the arrays and always returns the correct result. but that webrev didn't use Arrays.sort and that requirement seems to have been forgotten when adding it. public class Sort { public static void main(String[] args) { String[] a1 = { "a", null, "a" }; java.util.Arrays.sort(a1); } } java Sort Exception in thread "main" java.lang.NullPointerException at java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320) at java.util.ComparableTimSort.sort(ComparableTimSort.java:188) at java.util.Arrays.sort(Arrays.java:1246) at Sort.main(Sort.java:4) -phil. On 7/2/19, 5:18 AM, Alexey Ivanov wrote: > Are there any other comments? > Other volunteers for reviewing? > > Thanks in advance. > > On 25/06/2019 20:17, Alexey Ivanov wrote: >> Please see the updated webrev: >> http://cr.openjdk.java.net/~aivanov/8222108/webrev.01/ >> >> On 25/06/2019 00:01, Sergey Bylokhov wrote: >>> On 24/06/2019 14:50, Alexey Ivanov wrote: >>>>> I guess that the change in doCompare() passed a review because it >>>>> was assumed that the code inside will take care of unordered >>>>> arrays. if we will drop the doCompare() then probably we need to >>>>> sort the content of the arrays before Arrays.equals()? >>>> >>>> I can't see where doCompare() handled unordered arrays; quite the >>>> opposite: doCompare(new String[]{"a", "b"}, new String[]{"a", "b"}) >>>> returns true (that is the arrays are *not equal*) whereas the >>>> arrays are *equal*. >>> >>> That was an assumption on how it should work, but it was implemented >>> differently. >> >> I see. >> >>>> While I run the test, the list of printers always has the same >>>> order. We do not sort the array returned by getAllPrinterNames() in >>>> PrintServiceLookupProvider.refreshServices(), so I assume Windows >>>> returns the installed printers in the same order. Therefore I think >>>> sorting the array is not necessary in this case. >>> I do not know, if it is always has the same order then the fix look >>> fine, if we unsure then probably we can tweak it and sort. >> >> The order in which printers are enumerated by EnumPrinters is >> unspecified. For level 4, the information is queried from the >> registry. The order for registry enum functions is not guaranteed >> either. Even though the order of printers has always been the same so >> far, we cannot rely on this fact. From alexey.ushakov at jetbrains.com Wed Jul 3 07:23:49 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Wed, 3 Jul 2019 10:23:49 +0300 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework Message-ID: Hello, Here is a small update for metal-prototype-branch of hg.openjdk.java.net/jdk/sandbox? . The fix adds support of Xcode 10 for build environment. Please, have a look. http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.02/ Actually, I?ve tried to push it by myself. However (despite of the fact that I have ssh access) my push was rejected: #hg push pushing to ssh://avu at hg.openjdk.java.net/jdk/sandbox searching for changes remote: abort: could not lock repository jdk/sandbox: Read-only file system abort: unexpected response: empty string Phil, Jav could you advise what?s the possible reason of this. Do I actually have a write access to sandbox repository? Best Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Jul 3 15:47:52 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 3 Jul 2019 08:47:52 -0700 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework In-Reply-To: References: Message-ID: <6c025ef1-1692-1702-ef32-34866c649cc7@oracle.com> I don't know, since I am assuming you are using the same credentials that you have been using to successfully push to jdk/client. We should contact ops to see if there is a problem on that end. I'd like to make sure you can push here, else I'd offer to try it myself for you. -phil. On 7/3/19 12:23 AM, Alexey Ushakov wrote: > Hello, > > Here is a small update for metal-prototype-branch of > hg.openjdk.java.net/jdk/sandbox > . The fix adds support of > Xcode 10 for build environment. Please, have a look. > > http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.02/ > > > Actually, I?ve tried to push it by myself. However (despite of the > fact that I have ssh access) my push was rejected: > > #hg push > pushing to ssh://avu at hg.openjdk.java.net/jdk/sandbox > searching for changes > remote: abort: could not lock repository jdk/sandbox: Read-only file > system > abort: unexpected response: empty string > > Phil, Jav could you advise what?s the possible reason of this. Do I > actually have a write access to sandbox repository? > > Best Regards, > Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Jul 3 16:46:40 2019 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 3 Jul 2019 17:46:40 +0100 Subject: [OpenJDK 2D-Dev] [13] RFR 8222108: Reduce minRefreshTime for updating remote printer list on Windows In-Reply-To: <5D1BE51D.9050202@oracle.com> References: <9795b707-5a01-b608-1815-a26c0a23ef57@oracle.com> <627c821c-81b6-3843-e2ba-33190c5e5adb@oracle.com> <5D1BE51D.9050202@oracle.com> Message-ID: <178f2ca9-ea7d-b170-da36-e73966400a6a@oracle.com> Hi Phil, Thank you for your review! That's a valid point! Please see the updated webrev: http://cr.openjdk.java.net/~aivanov/8222108/webrev.02/ I implemented a custom comparator which handles null values in the printer list. However, I wonder if the list of printers can ever contain a null value. The method refreshServices() does not check if printers[p] is null. On 03/07/2019 00:13, Philip Race wrote: > I thought we had the checks for null in doCompare there for a reason. > Arrays.sort won't be very happy with a null element. > > You said in the first review email of the v0 webrev : > > > Arrays.equals() accepts null parameters and null elements in the > arrays and always returns the correct result. > > but that webrev didn't use Arrays.sort and that requirement seems to > have been forgotten > when adding it. > > ?public class Sort { > ? public static void main(String[] args) { > ??? String[] a1 = { "a", null, "a" }; > ??? java.util.Arrays.sort(a1); > ? } > } > > java Sort > Exception in thread "main" java.lang.NullPointerException > ??? at > java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:320) > ??? at java.util.ComparableTimSort.sort(ComparableTimSort.java:188) > ??? at java.util.Arrays.sort(Arrays.java:1246) > ??? at Sort.main(Sort.java:4) > > > -phil. > > On 7/2/19, 5:18 AM, Alexey Ivanov wrote: >> Are there any other comments? >> Other volunteers for reviewing? >> >> Thanks in advance. >> >> On 25/06/2019 20:17, Alexey Ivanov wrote: >>> Please see the updated webrev: >>> http://cr.openjdk.java.net/~aivanov/8222108/webrev.01/ >>> >>> -- Regards, Alexey From alexey.ushakov at jetbrains.com Thu Jul 4 13:08:16 2019 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Thu, 4 Jul 2019 16:08:16 +0300 Subject: [OpenJDK 2D-Dev] JDK-8226654 Some swing gtk regression tests fail with "java.lang.InternalError: Unable to load native GTK libraries" Message-ID: 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 prasanta.sadhukhan at oracle.com Fri Jul 5 08:51:50 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Jul 2019 14:21:50 +0530 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: References: Message-ID: <0b47babe-1869-4372-6150-4826230ff566@oracle.com> 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 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 ajit.ghaisas at oracle.com Mon Jul 8 12:25:32 2019 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 8 Jul 2019 17:55:32 +0530 Subject: [OpenJDK 2D-Dev] JDK-8220154 Improve java2d rendering performance on macOS by using Metal framework In-Reply-To: References: <2202E165-D9E9-44EE-9D99-71D81C026857@jetbrains.com> <52CE1C36-3570-40A7-BFA1-BEA884D344A1@oracle.com> <3EE8DC6F-C786-49C9-A57E-0C64C36AA025@jetbrains.com> <04ABBE2F-8243-4EF9-BC91-411483EC86D0@jetbrains.com> <325A8B6D-E370-414C-A9FE-4C06621C3D3B@oracle.com> <199ABAE9-7326-4A45-8384-9B1E5BC1C5D6@jetbrains.com> <7080CC33-FAC8-4CE3-974E-F9654E16FF19@oracle.com> <6D493075-E519-4224-9CBC-F9B795781BF1@oracle.com> Message-ID: <271FA018-CC42-432E-BDA5-B5F1ED816E37@oracle.com> Hi, I have pushed a minor correction to the metal-prototype-branch of jdk-sandbox (http://hg.openjdk.java.net/jdk/sandbox ) Now, we can build and launch J2DDemo, J2DBenchmark and SwingSet2 with Metal pipeline. Of course, rendering performance is slow and still a lot of functionality needs to be implemented. Regards, Ajit > On 20-Jun-2019, at 3:50 AM, Alexey Ushakov wrote: > > Hi Ajit, > >> Thanks for suggesting how to run basic perf test. >> I did run it with and without Metal. The test run with Metal takes ~2X time to run as compared with OpenGL. >> What is your observation? > > Yes, in some cases we have similar performance drop at the moment (testFlatBubbles, testFlatOvalRotBubbles, testWiredBubbles, testFlatQuad, testWiredQuad) > Here is the results from Mac mini 2018, macOS 10.14.4 > > metalEnabled=0 > testFlatBubbles 70 > testFlatBoxBubbles 78 > testImgBubbles 73 > testFlatBoxRotBubbles 78 > testFlatOvalRotBubbles 74 > testLinGradOvalRotBubbles 46 > testWiredBubbles 54 > testWiredBoxBubbles 82 > testLines 84 > testFlatQuad 62 > testWiredQuad 58 > > metalEnabled=1 > testFlatBubbles 31 > testFlatBoxBubbles 91 > testImgBubbles 88 > testFlatBoxRotBubbles 92 > testFlatOvalRotBubbles 36 > testLinGradOvalRotBubbles 37 > testWiredBubbles 17 > testWiredBoxBubbles - > testLines 89 > testFlatQuad 21 > testWiredQuad 19 > >> Although, the java side code changes are good, I see an issue with native Metal renderer implementation. >> For rendering primitives, I see that the metal commands are being encoded for each drawXXX call in MTLRenderer.m >> >> Why is MetalContext.createRenderEncoderForDest is being created for each draw call? I think, it is an overhead. >> Have you considered managing a VertexBuffer and encoding ?N? set of draw calls in a render pass? > > Yes, I thought about such optimizations. They definetely should help with this performance drop. > > Best Regards, > Alexey > > >> On 11 Jun 2019, at 12:01, Ajit Ghaisas > wrote: >> >> Hi Alexey, >> >> Thanks for suggesting how to run basic perf test. >> I did run it with and without Metal. The test run with Metal takes ~2X time to run as compared with OpenGL. >> What is your observation? >> >> Although, the java side code changes are good, I see an issue with native Metal renderer implementation. >> For rendering primitives, I see that the metal commands are being encoded for each drawXXX call in MTLRenderer.m >> >> Why is MetalContext.createRenderEncoderForDest is being created for each draw call? I think, it is an overhead. >> Have you considered managing a VertexBuffer and encoding ?N? set of draw calls in a render pass? >> >> Regards, >> Ajit >> >> >>> On 17-May-2019, at 12:20 PM, Jayathirth Rao > wrote: >>> >>> Hi Alexey, >>> >>> Thanks for the clarifications. >>> Build failures we are getting are mainly because of tighter compiler restrictions, I have attached error log for the same. >>> Basically we have 2 log errors and one conditional error. >>> >>> Yes in the latest build there is refactoring of LWComponentPeer.java but I have taken care of it and build error was not because of that. >>> >>> And thanks for sharing test and Graphics2D supported method details. >>> >>> Regards, >>> Jay >>> >>> >>> >>>> On 16-May-2019, at 10:39 PM, Alexey Ushakov > wrote: >>>> >>>> Hi Jay, >>>> >>>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>>> Jay & myself tried building it separately and we do still see the build failures. >>>> >>>> It?s strange. There wasn?t any copy/paste errors. The only reason that I can imagine that some chunks of the patch were rejected (as I actually experienced recently because of some refactoring of LWComponentPeer.java happened couple of days ago). >>>> Anyway, I regenerated webrev once more (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) and verified it with the openjdk workspace hg.openjdk.java.net/jdk/client . >>>> >>>> >>>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>>> Please provide your inputs. >>>> >>>> I?ve included junit4 performance test that you can try to see what is currently supported. >>>> Here is some steps to run the test provided with the webrev >>>> >>>> #cd openjdk_ws >>>> #mkdir -p test/jdk/jbu/testdata/perf/metal/ >>>> #cp webrev/raw_files/new/test/jdk/jbu/testdata/perf/metal/duke.png test/jdk/jbu/testdata/perf/metal/ >>>> >>>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/javac -cp .:/Users/avu/tools/junit-4.10.jar -d . test/jdk/jbu/perf/metal/MetalPerfTest.java >>>> >>>> #./build/macosx-x86_64-server-release/images/jdk-bundle/jdk-13.jdk/Contents/Home/bin/java -cp .:/Users/avu/tools/junit-4.10.jar -Dtestdata=/Users/avu/ws/openjdk/test/jdk/jbu/testdata -Djb.java2d.metal=true org.junit.runner.JUnitCore perf.metal.MetalPerfTest >>>> >>>> Here is the list of supported methods from Graphics2D: >>>> setColor >>>> fillOval >>>> translate >>>> setTransform >>>> rotate >>>> setPaint(new LinearGradientPaint()) >>>> drawImage >>>> fillRect >>>> draw/fill (Shape) >>>> >>>> Best Regards, >>>> Alexey >>>> >>>>> On 16 May 2019, at 15:08, Jayathirth Rao > wrote: >>>>> >>>>> Hi Alexey, >>>>> >>>>> We are trying to test basic calls of Graphics2D as mentioned in https://docs.oracle.com/javase/tutorial/2d/TOC.html >>>>> >>>>> I see that Graphics2D.drawImage() with BufferedImage as input works. Also I tried other operations like fillRect() and fillOval() and they work. I am testing with simple JFrame and adding draw calls inside overriden paint() method of a panel. >>>>> >>>>> So with current JB changes what parts of primitive and image drawing are expected to work? >>>>> Please provide your inputs. >>>>> >>>>> Thanks, >>>>> Jay >>>>> >>>>>> On 16-May-2019, at 12:47 PM, Ajit Ghaisas > wrote: >>>>>> >>>>>> Thanks Alexey. >>>>>> >>>>>> I can see that now you have added the MTLTexturePool.m file. It only partially solves the build failures. >>>>>> Jay & myself tried building it separately and we do still see the build failures. >>>>>> >>>>>> Some statements need bracketing & some copy-paste errors need correction. >>>>>> We could fix these errors and have got a build. We will continue our test experiments with it. >>>>>> >>>>>> Meanwhile, you may want to update the patch to fix the build errors. >>>>>> >>>>>> Regards, >>>>>> Ajit >>>>>> >>>>>> >>>>>>> On 08-May-2019, at 8:56 PM, Alexey Ushakov > wrote: >>>>>>> >>>>>>> FYI, I?ve rebased our work on top of the latest state of http://hg.openjdk.java.net/jdk/jdk >>>>>>> (http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 ) >>>>>>> >>>>>>> Best Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> On 8 May 2019, at 16:19, Alexey Ushakov > wrote: >>>>>>>> >>>>>>>> Thanks for catching it, Ajit! >>>>>>>> >>>>>>>> Looks like it was a problem with webrev script applied to multiple git commits. I?ve updated the webrev. >>>>>>>> Also, we didn?t rebase yet on the latest state of http://hg.openjdk.java.net/jdk/jdk (this work is in progress). >>>>>>>> I?ll let you know when the rebase is ready. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>>> On 7 May 2019, at 21:02, Ajit Ghaisas > wrote: >>>>>>>>> >>>>>>>>> Hi Alexey, >>>>>>>>> >>>>>>>>> I tried building this patch with latest http://hg.openjdk.java.net/jdk/jdk/ >>>>>>>>> >>>>>>>>> 1. Some basic copy paste errors are resulting in build failures >>>>>>>>> 2. MTLTexturePool.m file is missing from the patch >>>>>>>>> >>>>>>>>> Can you please check & update? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Ajit >>>>>>>>> >>>>>>>>>> On 30-Apr-2019, at 2:52 PM, Alexey Ushakov > wrote: >>>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Here is an update on our effort to use Metal framework for java2d rendering. >>>>>>>>>> >>>>>>>>>> We?ve added image rendering support and some support for LinearGradient. Also, the code has been refactored. >>>>>>>>>> >>>>>>>>>> Please have a look: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.01 >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> Alexey >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> As far as we know Apple has deprecated OpenGL on MacOS platform (https://developer.apple.com/macos/whats-new/ ). >>>>>>>>>>> >>>>>>>>>>> Unfortunately, this decision greatly affects our products that based on Java Client technologies. So, we (here at JetBrains) decided to start a project to replace OpenGL rendering on MacOS platform with a new one based on Metal. This is a huge task, so we decided to leverage current rendering architecture that is used in OpenGL rendering pipeline on Mac. >>>>>>>>>>> >>>>>>>>>>> That?s why we didn?t use MTKView for representing AWT windows (that probably would be a better approach in the long term). Currently we're using CAMetalLayer within AWTView. We?ve implemented flat color shape/curve rendering so far and there is a lot of work to do. So, we?re looking forward to any collaboration. >>>>>>>>>>> >>>>>>>>>>> In the mean time I?d like to share our current work to discuss metal pipeline architecture at the early stage of work. >>>>>>>>>>> >>>>>>>>>>> Here is the webrev with our on going development: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~avu/JDK-8220154/webrev.00 >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> Alexey >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Jul 10 06:50:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 10 Jul 2019 06:50:18 +0000 Subject: [OpenJDK 2D-Dev] FW: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file In-Reply-To: <5D24B1EB.10201@oracle.com> References: <5D24B1EB.10201@oracle.com> Message-ID: >Before I, or anyone else, starts to look at or comment on this, >can you instead post to the correct list : 2d-dev. Sure! Best regards, Matthias From: Philip Race Sent: Dienstag, 9. Juli 2019 17:26 To: Baesken, Matthias Cc: awt-dev at openjdk.java.net Subject: Re: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file 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 anton.litvinov at oracle.com Wed Jul 10 12:00:57 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Wed, 10 Jul 2019 13:00:57 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 Message-ID: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> Hello, Could you please review the following fix for the bug. The fix is backing out of the fix for the bug JDK-8214579 which caused this JCK test failure. If this fix is accepted, then a new separate bug for readdressing the bug reported in JDK-8214579 will be filed. Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 Changeset of JDK-8214579: http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 Thank you, Anton From philip.race at oracle.com Wed Jul 10 18:55:02 2019 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Jul 2019 11:55:02 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> Message-ID: Anton, This looks fine except that it needs to be prepared against 13, and then pushed there, not 14. And it will get forwarded synced from 13 to 14. That is the RDP process .. -phil. On 7/10/19 5:00 AM, Anton Litvinov wrote: > Hello, > > Could you please review the following fix for the bug. The fix is > backing out of the fix for the bug JDK-8214579 which caused this JCK > test failure. If this fix is accepted, then a new separate bug for > readdressing the bug reported in JDK-8214579 will be filed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 > Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 > Changeset of JDK-8214579: > http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 > > Thank you, > Anton From anton.litvinov at oracle.com Thu Jul 11 12:44:18 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 11 Jul 2019 13:44:18 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> Message-ID: Hello Phil, Thank you for review and the important remark about the need to work with "jdk/jdk13" stabilization repository, I forgot about this feature of post RDP 1 phase. Today I checked the fix against "jdk/jdk13" repository and confirm that it resolves this bug for JDK 13. Will wait for feedback or approval from any other second code reviewer. Thank you, Anton On 10/07/2019 19:55, Phil Race wrote: > Anton, > > This looks fine except that it needs to be prepared against 13, and > then pushed there, not 14. > And it will get forwarded synced from 13 to 14. That is the RDP > process .. > > -phil. > > On 7/10/19 5:00 AM, Anton Litvinov wrote: >> Hello, >> >> Could you please review the following fix for the bug. The fix is >> backing out of the fix for the bug JDK-8214579 which caused this JCK >> test failure. If this fix is accepted, then a new separate bug for >> readdressing the bug reported in JDK-8214579 will be filed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >> Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >> Changeset of JDK-8214579: >> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >> >> Thank you, >> Anton > From philip.race at oracle.com Thu Jul 11 14:35:05 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 11 Jul 2019 07:35:05 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> Message-ID: <5D274919.5070702@oracle.com> In such cases I like more than to be told "it would apply cleanly" but also to see that you actually prepared the webrev against 13. This is more certain and ensures that when the fix is approved you don't accidentally push it to the wrong repo. You have to go clone 13 and apply the patch there anyway ... -phil. On 7/11/19, 5:44 AM, Anton Litvinov wrote: > Hello Phil, > > Thank you for review and the important remark about the need to work > with "jdk/jdk13" stabilization repository, I forgot about this feature > of post RDP 1 phase. Today I checked the fix against "jdk/jdk13" > repository and confirm that it resolves this bug for JDK 13. > > Will wait for feedback or approval from any other second code reviewer. > > Thank you, > Anton > > On 10/07/2019 19:55, Phil Race wrote: >> Anton, >> >> This looks fine except that it needs to be prepared against 13, and >> then pushed there, not 14. >> And it will get forwarded synced from 13 to 14. That is the RDP >> process .. >> >> -phil. >> >> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>> Hello, >>> >>> Could you please review the following fix for the bug. The fix is >>> backing out of the fix for the bug JDK-8214579 which caused this JCK >>> test failure. If this fix is accepted, then a new separate bug for >>> readdressing the bug reported in JDK-8214579 will be filed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>> Changeset of JDK-8214579: >>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>> >>> Thank you, >>> Anton >> > From philip.race at oracle.com Thu Jul 11 14:51:33 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 11 Jul 2019 07:51:33 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <5D274919.5070702@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> Message-ID: <5D274CF5.80703@oracle.com> One more thing I just realised you should do here is de-problem list the regression test that fails ... after verifying it now works, updating it with this bug ID. And you can remove that noreg-jck label as a consequence. -phil. On 7/11/19, 7:35 AM, Philip Race wrote: > In such cases I like more than to be told "it would apply cleanly" but > also to see > that you actually prepared the webrev against 13. This is more certain > and ensures that when the fix is approved you don't accidentally push it > to the wrong repo. You have to go clone 13 and apply the patch there > anyway ... > > -phil. > > On 7/11/19, 5:44 AM, Anton Litvinov wrote: >> Hello Phil, >> >> Thank you for review and the important remark about the need to work >> with "jdk/jdk13" stabilization repository, I forgot about this >> feature of post RDP 1 phase. Today I checked the fix against >> "jdk/jdk13" repository and confirm that it resolves this bug for JDK 13. >> >> Will wait for feedback or approval from any other second code reviewer. >> >> Thank you, >> Anton >> >> On 10/07/2019 19:55, Phil Race wrote: >>> Anton, >>> >>> This looks fine except that it needs to be prepared against 13, and >>> then pushed there, not 14. >>> And it will get forwarded synced from 13 to 14. That is the RDP >>> process .. >>> >>> -phil. >>> >>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>> Hello, >>>> >>>> Could you please review the following fix for the bug. The fix is >>>> backing out of the fix for the bug JDK-8214579 which caused this >>>> JCK test failure. If this fix is accepted, then a new separate bug >>>> for readdressing the bug reported in JDK-8214579 will be filed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>> Changeset of JDK-8214579: >>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>> >>>> Thank you, >>>> Anton >>> >> From anton.litvinov at oracle.com Thu Jul 11 16:20:42 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 11 Jul 2019 17:20:42 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <5D274CF5.80703@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> Message-ID: <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> By your request regenerated the webrev specifically against (http://hg.openjdk.java.net/jdk/jdk13) repository. JDK 13 specific webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 I confirm again, that 2 failing manual tests: "ColorTest0003", "ColorTest0004" from the test "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail anymore after this fix is applied to JDK 13 compiled from "jdk/jdk13" repository. "jdk/jdk13" repository does not contain any problem list mentioning "api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I cannot de-problem list it and have no idea, where it is problem-listed. I also doubt that it is problem-listed, since it is manual. I added "noreg-jck" label to the bug in JBS deliberately according to OpenJDK process (Section #6 from the web page (http://openjdk.java.net/guide/changePlanning.html)), because this back out fix does not contain a new separate regression test, while this regression can be checked by running existing mentioned above test from JCK package. If this "noreg-jck" label creates problems, I can remove it at all. Thank you, Anton On 11/07/2019 15:51, Philip Race wrote: > One more thing I just realised you should do here is de-problem list > the regression test that fails ... after verifying it now works, > updating it with this bug ID. > And you can remove that noreg-jck label as a consequence. > > -phil. > > On 7/11/19, 7:35 AM, Philip Race wrote: >> In such cases I like more than to be told "it would apply cleanly" >> but also to see >> that you actually prepared the webrev against 13. This is more certain >> and ensures that when the fix is approved you don't accidentally push it >> to the wrong repo. You have to go clone 13 and apply the patch there >> anyway ... >> >> -phil. >> >> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>> Hello Phil, >>> >>> Thank you for review and the important remark about the need to work >>> with "jdk/jdk13" stabilization repository, I forgot about this >>> feature of post RDP 1 phase. Today I checked the fix against >>> "jdk/jdk13" repository and confirm that it resolves this bug for JDK >>> 13. >>> >>> Will wait for feedback or approval from any other second code reviewer. >>> >>> Thank you, >>> Anton >>> >>> On 10/07/2019 19:55, Phil Race wrote: >>>> Anton, >>>> >>>> This looks fine except that it needs to be prepared against 13, and >>>> then pushed there, not 14. >>>> And it will get forwarded synced from 13 to 14. That is the RDP >>>> process .. >>>> >>>> -phil. >>>> >>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>> Hello, >>>>> >>>>> Could you please review the following fix for the bug. The fix is >>>>> backing out of the fix for the bug JDK-8214579 which caused this >>>>> JCK test failure. If this fix is accepted, then a new separate bug >>>>> for readdressing the bug reported in JDK-8214579 will be filed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>> Changeset of JDK-8214579: >>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>> >>>>> Thank you, >>>>> Anton >>>> >>> From philip.race at oracle.com Thu Jul 11 16:38:07 2019 From: philip.race at oracle.com (Philip Race) Date: Thu, 11 Jul 2019 09:38:07 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> Message-ID: <5D2765EF.7010900@oracle.com> There is a regression test that is supposed to catch this exact problem. So I had looked into how we did not catch this earlier and found that in fact we did. This was originally found and filed as https://bugs.openjdk.java.net/browse/JDK-8224825 The test java/awt/Color/AlphaColorTest.java was then problem listed on Linux. $ grep AlphaColorTest test/jdk/ProblemList.txt java/awt/Color/AlphaColorTest.java 8224825 linux-all So I think we can close JDK-8224825 as a duplicate of this as well as updating the problem list and the test - after confirming that this backout resolves that as I expect it will. -phil. On 7/11/19, 9:20 AM, Anton Litvinov wrote: > By your request regenerated the webrev specifically against > (http://hg.openjdk.java.net/jdk/jdk13) repository. > JDK 13 specific webrev: > http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 > > I confirm again, that 2 failing manual tests: "ColorTest0003", > "ColorTest0004" from the test > "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail > anymore after this fix is applied to JDK 13 compiled from "jdk/jdk13" > repository. > > "jdk/jdk13" repository does not contain any problem list mentioning > "api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I > cannot de-problem list it and have no idea, where it is > problem-listed. I also doubt that it is problem-listed, since it is > manual. I added "noreg-jck" label to the bug in JBS deliberately > according to OpenJDK process (Section #6 from the web page > (http://openjdk.java.net/guide/changePlanning.html)), because this > back out fix does not contain a new separate regression test, while > this regression can be checked by running existing mentioned above > test from JCK package. > > If this "noreg-jck" label creates problems, I can remove it at all. > > Thank you, > Anton > > On 11/07/2019 15:51, Philip Race wrote: >> One more thing I just realised you should do here is de-problem list >> the regression test that fails ... after verifying it now works, >> updating it with this bug ID. >> And you can remove that noreg-jck label as a consequence. >> >> -phil. >> >> On 7/11/19, 7:35 AM, Philip Race wrote: >>> In such cases I like more than to be told "it would apply cleanly" >>> but also to see >>> that you actually prepared the webrev against 13. This is more certain >>> and ensures that when the fix is approved you don't accidentally >>> push it >>> to the wrong repo. You have to go clone 13 and apply the patch there >>> anyway ... >>> >>> -phil. >>> >>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>> Hello Phil, >>>> >>>> Thank you for review and the important remark about the need to >>>> work with "jdk/jdk13" stabilization repository, I forgot about this >>>> feature of post RDP 1 phase. Today I checked the fix against >>>> "jdk/jdk13" repository and confirm that it resolves this bug for >>>> JDK 13. >>>> >>>> Will wait for feedback or approval from any other second code >>>> reviewer. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 10/07/2019 19:55, Phil Race wrote: >>>>> Anton, >>>>> >>>>> This looks fine except that it needs to be prepared against 13, >>>>> and then pushed there, not 14. >>>>> And it will get forwarded synced from 13 to 14. That is the RDP >>>>> process .. >>>>> >>>>> -phil. >>>>> >>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>> Hello, >>>>>> >>>>>> Could you please review the following fix for the bug. The fix is >>>>>> backing out of the fix for the bug JDK-8214579 which caused this >>>>>> JCK test failure. If this fix is accepted, then a new separate >>>>>> bug for readdressing the bug reported in JDK-8214579 will be filed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>> Changeset of JDK-8214579: >>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>> >>>> > From brian.burkhalter at oracle.com Thu Jul 11 17:44:44 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Jul 2019 10:44:44 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause Message-ID: https://bugs.openjdk.java.net/browse/JDK-8187898 http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. A CSR would of course be needed for this. Thanks, Brian From anton.litvinov at oracle.com Thu Jul 11 18:13:43 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Thu, 11 Jul 2019 19:13:43 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <5D2765EF.7010900@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> Message-ID: Hello Phil, Thank you for these additional details. I have tried to run the test "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13 compiled from "jdk/jdk13" with/without this back out fix and the results are not so stable on my VirtualBox host with openSUSE Leap 15.0 OS (GNOME 3.26.2): 1. "AlphaColorTest.java" stably fails with JDK 13 without this back out fix and the test failure message is stably: ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" 2. "AlphaColorTest.java" starts passing with JDK 13 with the back out fix, but continues to intermittently fail with the failure message: ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" It looks that either this regression test had been failing intermittently before the fix 8214579, which we are backing out, was integrated, or some other fix causes this intermittent failure. Maybe in this case it is better not to change this "open/test/jdk/ProblemList.txt" as well as the test itself "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this back out fix for JCK test failure? Thank you, Anton On 11/07/2019 17:38, Philip Race wrote: > There is a regression test that is supposed to catch this exact problem. > > So I had looked into how we did not catch this earlier and found that > in fact we did. > This was originally found and filed as > https://bugs.openjdk.java.net/browse/JDK-8224825 > The test java/awt/Color/AlphaColorTest.java was then problem listed on > Linux. > > $ grep AlphaColorTest test/jdk/ProblemList.txt > java/awt/Color/AlphaColorTest.java 8224825 linux-all > > So I think we can close JDK-8224825 as a duplicate of this as well as > updating the problem list > and the test - after confirming that this backout resolves that as I > expect it will. > > -phil. > > On 7/11/19, 9:20 AM, Anton Litvinov wrote: >> By your request regenerated the webrev specifically against >> (http://hg.openjdk.java.net/jdk/jdk13) repository. >> JDK 13 specific webrev: >> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >> >> I confirm again, that 2 failing manual tests: "ColorTest0003", >> "ColorTest0004" from the test >> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >> anymore after this fix is applied to JDK 13 compiled from "jdk/jdk13" >> repository. >> >> "jdk/jdk13" repository does not contain any problem list mentioning >> "api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I >> cannot de-problem list it and have no idea, where it is >> problem-listed. I also doubt that it is problem-listed, since it is >> manual. I added "noreg-jck" label to the bug in JBS deliberately >> according to OpenJDK process (Section #6 from the web page >> (http://openjdk.java.net/guide/changePlanning.html)), because this >> back out fix does not contain a new separate regression test, while >> this regression can be checked by running existing mentioned above >> test from JCK package. >> >> If this "noreg-jck" label creates problems, I can remove it at all. >> >> Thank you, >> Anton >> >> On 11/07/2019 15:51, Philip Race wrote: >>> One more thing I just realised you should do here is de-problem list >>> the regression test that fails ... after verifying it now works, >>> updating it with this bug ID. >>> And you can remove that noreg-jck label as a consequence. >>> >>> -phil. >>> >>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>> In such cases I like more than to be told "it would apply cleanly" >>>> but also to see >>>> that you actually prepared the webrev against 13. This is more certain >>>> and ensures that when the fix is approved you don't accidentally >>>> push it >>>> to the wrong repo. You have to go clone 13 and apply the patch >>>> there anyway ... >>>> >>>> -phil. >>>> >>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>> Hello Phil, >>>>> >>>>> Thank you for review and the important remark about the need to >>>>> work with "jdk/jdk13" stabilization repository, I forgot about >>>>> this feature of post RDP 1 phase. Today I checked the fix against >>>>> "jdk/jdk13" repository and confirm that it resolves this bug for >>>>> JDK 13. >>>>> >>>>> Will wait for feedback or approval from any other second code >>>>> reviewer. >>>>> >>>>> Thank you, >>>>> Anton >>>>> >>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>> Anton, >>>>>> >>>>>> This looks fine except that it needs to be prepared against 13, >>>>>> and then pushed there, not 14. >>>>>> And it will get forwarded synced from 13 to 14. That is the RDP >>>>>> process .. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you please review the following fix for the bug. The fix >>>>>>> is backing out of the fix for the bug JDK-8214579 which caused >>>>>>> this JCK test failure. If this fix is accepted, then a new >>>>>>> separate bug for readdressing the bug reported in JDK-8214579 >>>>>>> will be filed. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>> Changeset of JDK-8214579: >>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>> >>>>>>> Thank you, >>>>>>> Anton >>>>>> >>>>> >> From philip.race at oracle.com Thu Jul 11 18:48:29 2019 From: philip.race at oracle.com (Phil Race) Date: Thu, 11 Jul 2019 11:48:29 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> Message-ID: <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> I don't think we ever saw it fail until 8214579 was pushed. I don't know the reason for the color you are sporadically getting in VB Maybe it is slow and the paint event is being missed ? But then I'd expect black .. not light grey. Still, it might be informative to put a print statement in here (in the test) ??? public void paint(Graphics g) { ??????? System.out.println("color=" + color + " alpha=" + color.getAlpha());? // << add this ??????? g.setColor(color); ??????? g.fillRect(0, 0, getSize().width, getSize().height); ??? } and compare what is printed for failing and passing runs. If you can't figure it out quickly, then update the test to not exit so quickly and grab a screen shot of the failure and add it to the bug. -phil. On 7/11/19 11:13 AM, Anton Litvinov wrote: > Hello Phil, > > Thank you for these additional details. I have tried to run the test > "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13 > compiled from "jdk/jdk13" with/without this back out fix and the > results are not so stable on my VirtualBox host with openSUSE Leap > 15.0 OS (GNOME 3.26.2): > > 1. "AlphaColorTest.java" stably fails with JDK 13 without this back > out fix and the test failure message is stably: > ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" > > 2. "AlphaColorTest.java" starts passing with JDK 13 with the back out > fix, but continues to intermittently fail with the failure message: > ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" > > It looks that either this regression test had been failing > intermittently before the fix 8214579, which we are backing out, was > integrated, or some other fix causes this intermittent failure. > > Maybe in this case it is better not to change this > "open/test/jdk/ProblemList.txt" as well as the test itself > "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this > back out fix for JCK test failure? > > Thank you, > Anton > > On 11/07/2019 17:38, Philip Race wrote: >> There is a regression test that is supposed to catch this exact problem. >> >> So I had looked into how we did not catch this earlier and found that >> in fact we did. >> This was originally found and filed as >> https://bugs.openjdk.java.net/browse/JDK-8224825 >> The test java/awt/Color/AlphaColorTest.java was then problem listed >> on Linux. >> >> $ grep AlphaColorTest test/jdk/ProblemList.txt >> java/awt/Color/AlphaColorTest.java 8224825 linux-all >> >> So I think we can close JDK-8224825 as a duplicate of this as well as >> updating the problem list >> and the test - after confirming that this backout resolves that as I >> expect it will. >> >> -phil. >> >> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>> By your request regenerated the webrev specifically against >>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>> JDK 13 specific webrev: >>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>> >>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>> "ColorTest0004" from the test >>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >>> anymore after this fix is applied to JDK 13 compiled from >>> "jdk/jdk13" repository. >>> >>> "jdk/jdk13" repository does not contain any problem list mentioning >>> "api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I >>> cannot de-problem list it and have no idea, where it is >>> problem-listed. I also doubt that it is problem-listed, since it is >>> manual. I added "noreg-jck" label to the bug in JBS deliberately >>> according to OpenJDK process (Section #6 from the web page >>> (http://openjdk.java.net/guide/changePlanning.html)), because this >>> back out fix does not contain a new separate regression test, while >>> this regression can be checked by running existing mentioned above >>> test from JCK package. >>> >>> If this "noreg-jck" label creates problems, I can remove it at all. >>> >>> Thank you, >>> Anton >>> >>> On 11/07/2019 15:51, Philip Race wrote: >>>> One more thing I just realised you should do here is de-problem list >>>> the regression test that fails ... after verifying it now works, >>>> updating it with this bug ID. >>>> And you can remove that noreg-jck label as a consequence. >>>> >>>> -phil. >>>> >>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>> In such cases I like more than to be told "it would apply cleanly" >>>>> but also to see >>>>> that you actually prepared the webrev against 13. This is more >>>>> certain >>>>> and ensures that when the fix is approved you don't accidentally >>>>> push it >>>>> to the wrong repo. You have to go clone 13 and apply the patch >>>>> there anyway ... >>>>> >>>>> -phil. >>>>> >>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>> Hello Phil, >>>>>> >>>>>> Thank you for review and the important remark about the need to >>>>>> work with "jdk/jdk13" stabilization repository, I forgot about >>>>>> this feature of post RDP 1 phase. Today I checked the fix against >>>>>> "jdk/jdk13" repository and confirm that it resolves this bug for >>>>>> JDK 13. >>>>>> >>>>>> Will wait for feedback or approval from any other second code >>>>>> reviewer. >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>>> >>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>> Anton, >>>>>>> >>>>>>> This looks fine except that it needs to be prepared against 13, >>>>>>> and then pushed there, not 14. >>>>>>> And it will get forwarded synced from 13 to 14. That is the RDP >>>>>>> process .. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you please review the following fix for the bug. The fix >>>>>>>> is backing out of the fix for the bug JDK-8214579 which caused >>>>>>>> this JCK test failure. If this fix is accepted, then a new >>>>>>>> separate bug for readdressing the bug reported in JDK-8214579 >>>>>>>> will be filed. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>> Changeset of JDK-8214579: >>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Anton >>>>>>> >>>>>> >>> > From brian.burkhalter at oracle.com Thu Jul 11 20:07:33 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 11 Jul 2019 13:07:33 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Testing revealed the need for some changes in test/jdk/java/lang/System/LoggerFinder/internal. Webrev updated in place. Brian > On Jul 11, 2019, at 10:44 AM, Brian Burkhalter wrote: > > https://bugs.openjdk.java.net/browse/JDK-8187898 > http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ > > Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. > > A CSR would of course be needed for this. -------------- 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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: [OpenJDK 2D-Dev] 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 Roger.Riggs at oracle.com Fri Jul 12 18:17:38 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 12 Jul 2019 14:17:38 -0400 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Hi Brian, Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). The proposed change duplicates the code and changes the ways that overridden classes might see the call. What's the benefit of duplicating the code and calling out.write(buf)? Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. (The CSR will need to note the source incompatibility due to the removal of a declared exception) Thanks, Roger On 7/11/19 1:44 PM, Brian Burkhalter wrote: > https://bugs.openjdk.java.net/browse/JDK-8187898 > http://cr.openjdk.java.net/~bpb/8187898/webrev.00/ > > Override FilterOutputStream.write(byte[]) not to throw IOException. Including 2d-dev as this creates a source compatibility issue in PSPrinterJob which I fix in this patch. > > A CSR would of course be needed for this. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Fri Jul 12 18:34:12 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Fri, 12 Jul 2019 19:34:12 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> Message-ID: <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> Hello Phil, I tried to apply your code and can confirm that value of "color" is always the same for the case, when the test passes and fails. For each test run the "paint(Graphics)" method is called either 2 or 3 times and this tracing output is always the same and following: "color=java.awt.Color[r=255,g=255,b=255] alpha=127" My today's experiments show that this intermittent failure is reproducible with builds prior to the builds with the fix for 8214579 and this is also reproducible on Oracle Linux 7.4 x64. I was able to reproduce in the following environment configurations: 1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix 8214579 which was integrated in JDK 13+24) 2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the test itself was introduced), JDK 11+28 (GA build). I attached a screenshot with the test failure and wrote a comment in the bug (https://bugs.openjdk.java.net/browse/JDK-8224825). MY OBSERVATION: Although I have not been able to identify the root cause of the intermittent test failure, I think that the wrong color is got, when the black color, which is set as the background for the frame, is not participating in color blending. THE DISCOVERED WORKAROUND: I discovered that if the following workaround is applied to the regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then the intermittent test failure disappears (is not reproducible, when test is run 20 times in a row). Also I verified with the workaround the test fails as it should with JDK 11+24 (the build without the fix 8204931 which was integrated in JDK 11+25 and introduced the test). The workaround is following. Substitute the next 2 code lines: 77 ?????? frame = new Frame("Alpha Color Test"); 78 ?????? frame.setBackground(Color.black); for the next 8 code lines: ??????? frame = new Frame("Alpha Color Test") { ??????????? @Override ??????????? public void paint(Graphics g) { ??????????????? g.setColor(Color.black); ??????????????? g.fillRect(0, 0, getWidth(), getHeight()); ??????????????? super.paint(g); ??????????? } ??????? }; Would such a workaround be acceptable as part of this back out fix? Thank you, Anton On 11/07/2019 19:48, Phil Race wrote: > I don't think we ever saw it fail until 8214579 was pushed. > I don't know the reason for the color you are sporadically getting in VB > Maybe it is slow and the paint event is being missed ? > But then I'd expect black .. not light grey. > > Still, it might be informative to put a print statement in here (in > the test) > ??? public void paint(Graphics g) { > ??????? System.out.println("color=" + color + " alpha=" + > color.getAlpha());? // << add this > ??????? g.setColor(color); > ??????? g.fillRect(0, 0, getSize().width, getSize().height); > ??? } > > and compare what is printed for failing and passing runs. > If you can't figure it out quickly, then update the test to not exit > so quickly and grab a screen > shot of the failure and add it to the bug. > > > -phil. > > On 7/11/19 11:13 AM, Anton Litvinov wrote: >> Hello Phil, >> >> Thank you for these additional details. I have tried to run the test >> "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13 >> compiled from "jdk/jdk13" with/without this back out fix and the >> results are not so stable on my VirtualBox host with openSUSE Leap >> 15.0 OS (GNOME 3.26.2): >> >> 1. "AlphaColorTest.java" stably fails with JDK 13 without this back >> out fix and the test failure message is stably: >> ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" >> >> 2. "AlphaColorTest.java" starts passing with JDK 13 with the back out >> fix, but continues to intermittently fail with the failure message: >> ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" >> >> It looks that either this regression test had been failing >> intermittently before the fix 8214579, which we are backing out, was >> integrated, or some other fix causes this intermittent failure. >> >> Maybe in this case it is better not to change this >> "open/test/jdk/ProblemList.txt" as well as the test itself >> "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this >> back out fix for JCK test failure? >> >> Thank you, >> Anton >> >> On 11/07/2019 17:38, Philip Race wrote: >>> There is a regression test that is supposed to catch this exact >>> problem. >>> >>> So I had looked into how we did not catch this earlier and found >>> that in fact we did. >>> This was originally found and filed as >>> https://bugs.openjdk.java.net/browse/JDK-8224825 >>> The test java/awt/Color/AlphaColorTest.java was then problem listed >>> on Linux. >>> >>> $ grep AlphaColorTest test/jdk/ProblemList.txt >>> java/awt/Color/AlphaColorTest.java 8224825 linux-all >>> >>> So I think we can close JDK-8224825 as a duplicate of this as well >>> as updating the problem list >>> and the test - after confirming that this backout resolves that as I >>> expect it will. >>> >>> -phil. >>> >>> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>>> By your request regenerated the webrev specifically against >>>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>>> JDK 13 specific webrev: >>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>>> >>>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>>> "ColorTest0004" from the test >>>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >>>> anymore after this fix is applied to JDK 13 compiled from >>>> "jdk/jdk13" repository. >>>> >>>> "jdk/jdk13" repository does not contain any problem list mentioning >>>> "api/java_awt/interactive/ColorTests.html" test from JCK 13, thus I >>>> cannot de-problem list it and have no idea, where it is >>>> problem-listed. I also doubt that it is problem-listed, since it is >>>> manual. I added "noreg-jck" label to the bug in JBS deliberately >>>> according to OpenJDK process (Section #6 from the web page >>>> (http://openjdk.java.net/guide/changePlanning.html)), because this >>>> back out fix does not contain a new separate regression test, while >>>> this regression can be checked by running existing mentioned above >>>> test from JCK package. >>>> >>>> If this "noreg-jck" label creates problems, I can remove it at all. >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 11/07/2019 15:51, Philip Race wrote: >>>>> One more thing I just realised you should do here is de-problem list >>>>> the regression test that fails ... after verifying it now works, >>>>> updating it with this bug ID. >>>>> And you can remove that noreg-jck label as a consequence. >>>>> >>>>> -phil. >>>>> >>>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>>> In such cases I like more than to be told "it would apply >>>>>> cleanly" but also to see >>>>>> that you actually prepared the webrev against 13. This is more >>>>>> certain >>>>>> and ensures that when the fix is approved you don't accidentally >>>>>> push it >>>>>> to the wrong repo. You have to go clone 13 and apply the patch >>>>>> there anyway ... >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>>> Hello Phil, >>>>>>> >>>>>>> Thank you for review and the important remark about the need to >>>>>>> work with "jdk/jdk13" stabilization repository, I forgot about >>>>>>> this feature of post RDP 1 phase. Today I checked the fix >>>>>>> against "jdk/jdk13" repository and confirm that it resolves this >>>>>>> bug for JDK 13. >>>>>>> >>>>>>> Will wait for feedback or approval from any other second code >>>>>>> reviewer. >>>>>>> >>>>>>> Thank you, >>>>>>> Anton >>>>>>> >>>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>>> Anton, >>>>>>>> >>>>>>>> This looks fine except that it needs to be prepared against 13, >>>>>>>> and then pushed there, not 14. >>>>>>>> And it will get forwarded synced from 13 to 14. That is the RDP >>>>>>>> process .. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you please review the following fix for the bug. The fix >>>>>>>>> is backing out of the fix for the bug JDK-8214579 which caused >>>>>>>>> this JCK test failure. If this fix is accepted, then a new >>>>>>>>> separate bug for readdressing the bug reported in JDK-8214579 >>>>>>>>> will be filed. >>>>>>>>> >>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>>> Changeset of JDK-8214579: >>>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Anton >>>>>>>> >>>>>>> >>>> >> > From philip.race at oracle.com Fri Jul 12 18:42:27 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jul 2019 11:42:27 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> Message-ID: > Would such a workaround be acceptable as part of this back out fix? Yes, very much so ! -phil. On 7/12/19 11:34 AM, Anton Litvinov wrote: > Hello Phil, > > I tried to apply your code and can confirm that value of "color" is > always the same for the case, when the test passes and fails. For each > test run the "paint(Graphics)" method is called either 2 or 3 times > and this tracing output is always the same and following: > "color=java.awt.Color[r=255,g=255,b=255] alpha=127" > > My today's experiments show that this intermittent failure is > reproducible with builds prior to the builds with the fix for 8214579 > and this is also reproducible on Oracle Linux 7.4 x64. I was able to > reproduce in the following environment configurations: > > 1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix > 8214579 which was integrated in JDK 13+24) > 2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the > test itself was introduced), JDK 11+28 (GA build). > > I attached a screenshot with the test failure and wrote a comment in > the bug (https://bugs.openjdk.java.net/browse/JDK-8224825). > > MY OBSERVATION: > > Although I have not been able to identify the root cause of the > intermittent test failure, I think that the wrong color is got, when > the black color, which is set as the background for the frame, is not > participating in color blending. > > THE DISCOVERED WORKAROUND: > > I discovered that if the following workaround is applied to the > regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then > the intermittent test failure disappears (is not reproducible, when > test is run 20 times in a row). Also I verified with the workaround > the test fails as it should with JDK 11+24 (the build without the fix > 8204931 which was integrated in JDK 11+25 and introduced the test). > The workaround is following. > > Substitute the next 2 code lines: > > 77 ?????? frame = new Frame("Alpha Color Test"); > 78 ?????? frame.setBackground(Color.black); > > for the next 8 code lines: > > ??????? frame = new Frame("Alpha Color Test") { > ??????????? @Override > ??????????? public void paint(Graphics g) { > ??????????????? g.setColor(Color.black); > ??????????????? g.fillRect(0, 0, getWidth(), getHeight()); > ??????????????? super.paint(g); > ??????????? } > ??????? }; > > Would such a workaround be acceptable as part of this back out fix? > > Thank you, > Anton > > On 11/07/2019 19:48, Phil Race wrote: >> I don't think we ever saw it fail until 8214579 was pushed. >> I don't know the reason for the color you are sporadically getting in VB >> Maybe it is slow and the paint event is being missed ? >> But then I'd expect black .. not light grey. >> >> Still, it might be informative to put a print statement in here (in >> the test) >> ??? public void paint(Graphics g) { >> ??????? System.out.println("color=" + color + " alpha=" + >> color.getAlpha());? // << add this >> ??????? g.setColor(color); >> ??????? g.fillRect(0, 0, getSize().width, getSize().height); >> ??? } >> >> and compare what is printed for failing and passing runs. >> If you can't figure it out quickly, then update the test to not exit >> so quickly and grab a screen >> shot of the failure and add it to the bug. >> >> >> -phil. >> >> On 7/11/19 11:13 AM, Anton Litvinov wrote: >>> Hello Phil, >>> >>> Thank you for these additional details. I have tried to run the test >>> "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13 >>> compiled from "jdk/jdk13" with/without this back out fix and the >>> results are not so stable on my VirtualBox host with openSUSE Leap >>> 15.0 OS (GNOME 3.26.2): >>> >>> 1. "AlphaColorTest.java" stably fails with JDK 13 without this back >>> out fix and the test failure message is stably: >>> ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" >>> >>> 2. "AlphaColorTest.java" starts passing with JDK 13 with the back >>> out fix, but continues to intermittently fail with the failure message: >>> ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" >>> >>> It looks that either this regression test had been failing >>> intermittently before the fix 8214579, which we are backing out, was >>> integrated, or some other fix causes this intermittent failure. >>> >>> Maybe in this case it is better not to change this >>> "open/test/jdk/ProblemList.txt" as well as the test itself >>> "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this >>> back out fix for JCK test failure? >>> >>> Thank you, >>> Anton >>> >>> On 11/07/2019 17:38, Philip Race wrote: >>>> There is a regression test that is supposed to catch this exact >>>> problem. >>>> >>>> So I had looked into how we did not catch this earlier and found >>>> that in fact we did. >>>> This was originally found and filed as >>>> https://bugs.openjdk.java.net/browse/JDK-8224825 >>>> The test java/awt/Color/AlphaColorTest.java was then problem listed >>>> on Linux. >>>> >>>> $ grep AlphaColorTest test/jdk/ProblemList.txt >>>> java/awt/Color/AlphaColorTest.java 8224825 linux-all >>>> >>>> So I think we can close JDK-8224825 as a duplicate of this as well >>>> as updating the problem list >>>> and the test - after confirming that this backout resolves that as >>>> I expect it will. >>>> >>>> -phil. >>>> >>>> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>>>> By your request regenerated the webrev specifically against >>>>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>>>> JDK 13 specific webrev: >>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>>>> >>>>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>>>> "ColorTest0004" from the test >>>>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >>>>> anymore after this fix is applied to JDK 13 compiled from >>>>> "jdk/jdk13" repository. >>>>> >>>>> "jdk/jdk13" repository does not contain any problem list >>>>> mentioning "api/java_awt/interactive/ColorTests.html" test from >>>>> JCK 13, thus I cannot de-problem list it and have no idea, where >>>>> it is problem-listed. I also doubt that it is problem-listed, >>>>> since it is manual. I added "noreg-jck" label to the bug in JBS >>>>> deliberately according to OpenJDK process (Section #6 from the web >>>>> page (http://openjdk.java.net/guide/changePlanning.html)), because >>>>> this back out fix does not contain a new separate regression test, >>>>> while this regression can be checked by running existing mentioned >>>>> above test from JCK package. >>>>> >>>>> If this "noreg-jck" label creates problems, I can remove it at all. >>>>> >>>>> Thank you, >>>>> Anton >>>>> >>>>> On 11/07/2019 15:51, Philip Race wrote: >>>>>> One more thing I just realised you should do here is de-problem list >>>>>> the regression test that fails ... after verifying it now works, >>>>>> updating it with this bug ID. >>>>>> And you can remove that noreg-jck label as a consequence. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>>>> In such cases I like more than to be told "it would apply >>>>>>> cleanly" but also to see >>>>>>> that you actually prepared the webrev against 13. This is more >>>>>>> certain >>>>>>> and ensures that when the fix is approved you don't accidentally >>>>>>> push it >>>>>>> to the wrong repo. You have to go clone 13 and apply the patch >>>>>>> there anyway ... >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>>>> Hello Phil, >>>>>>>> >>>>>>>> Thank you for review and the important remark about the need to >>>>>>>> work with "jdk/jdk13" stabilization repository, I forgot about >>>>>>>> this feature of post RDP 1 phase. Today I checked the fix >>>>>>>> against "jdk/jdk13" repository and confirm that it resolves >>>>>>>> this bug for JDK 13. >>>>>>>> >>>>>>>> Will wait for feedback or approval from any other second code >>>>>>>> reviewer. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Anton >>>>>>>> >>>>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>>>> Anton, >>>>>>>>> >>>>>>>>> This looks fine except that it needs to be prepared against >>>>>>>>> 13, and then pushed there, not 14. >>>>>>>>> And it will get forwarded synced from 13 to 14. That is the >>>>>>>>> RDP process .. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you please review the following fix for the bug. The >>>>>>>>>> fix is backing out of the fix for the bug JDK-8214579 which >>>>>>>>>> caused this JCK test failure. If this fix is accepted, then a >>>>>>>>>> new separate bug for readdressing the bug reported in >>>>>>>>>> JDK-8214579 will be filed. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>>>> Changeset of JDK-8214579: >>>>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Anton >>>>>>>>> >>>>>>>> >>>>> >>> >> > From brian.burkhalter at oracle.com Fri Jul 12 19:01:46 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 12:01:46 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: Hi Roger, > On Jul 12, 2019, at 11:17 AM, Roger Riggs wrote: > > Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). Yes, I think so. > Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). > The proposed change duplicates the code and changes the ways that overridden classes might see the call. > What's the benefit of duplicating the code and calling out.write(buf)? Probably nothing. Probably better to call write(b,0,b.length) directly. > Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. I agree but I was waiting for a suggestion from a 2D reviewer. > (The CSR will need to note the source incompatibility due to the removal of a declared exception) Right. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jul 12 19:54:30 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 12:54:30 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: Message-ID: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> Here is new webrev incorporating the two changes below. http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ Thanks, Brian > On Jul 12, 2019, at 12:01 PM, Brian Burkhalter wrote: > >> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: >> >> Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). > > Yes, I think so. > >> Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). >> The proposed change duplicates the code and changes the ways that overridden classes might see the call. >> What's the benefit of duplicating the code and calling out.write(buf)? > > Probably nothing. Probably better to call write(b,0,b.length) directly. > >> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. > > I agree but I was waiting for a suggestion from a 2D reviewer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 12 20:02:08 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jul 2019 13:02:08 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> Message-ID: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> > Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. Dilemma - since at 1036 we are throwing an Exception and the comment at 970-ish suggests the author was intending to do what s/he did at 1036 but never got around to it. I think I'd be more inclined to make the code at 970 like that at 1036. But (1) then the comment surely can go (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. And whilst great you are fixing up this code, we are but a small fraction of the world's code that use java.io and I wonder if this is worth the compatibility risk ? -phil On 7/12/19 12:54 PM, Brian Burkhalter wrote: > Here is new webrev incorporating the two changes below. > > http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ > > Thanks, > > Brian > >> On Jul 12, 2019, at 12:01 PM, Brian Burkhalter wrote: >> >>> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: >>> >>> Would it be appropriate to add @Override to the new method (and perhaps existing overridden methods). >> Yes, I think so. >> >>> Previously, calling FilterOutputStream.write(byte[]) would delegate to write(byte[], 0, length). >>> The proposed change duplicates the code and changes the ways that overridden classes might see the call. >>> What's the benefit of duplicating the code and calling out.write(buf)? >> Probably nothing. Probably better to call write(b,0,b.length) directly. >> >>> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. >> I agree but I was waiting for a suggestion from a 2D reviewer. From brian.burkhalter at oracle.com Fri Jul 12 20:10:18 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 13:10:18 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> > On Jul 12, 2019, at 1:02 PM, Phil Race wrote: > >> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to just delete the unused code and comment. > > Dilemma - since at 1036 we are throwing an Exception and the comment at 970-ish suggests > the author was intending to do what s/he did at 1036 but never got around to it. > > I think I'd be more inclined to make the code at 970 like that at 1036. > But > (1) then the comment surely can go OK > (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. > And whilst great you are fixing up this code, we are but a small fraction of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? I?m not sure either. I was leaving that decision to the CSR process. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 12 20:39:13 2019 From: philip.race at oracle.com (Phil Race) Date: Fri, 12 Jul 2019 13:39:13 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> Message-ID: oh well ... in which I suppose this is the best you can do here. -phil. On 7/12/19 1:10 PM, Brian Burkhalter wrote: > >> (2) I don't know why at 1034 you changed from PrinterIOException to >> PrinterException. > > There is no PrinterIOException constructor which accepts a String as > its only parameter and there is no IOException to pass to a > PrinterIOException constructor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Fri Jul 12 22:12:55 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 12 Jul 2019 15:12:55 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> Message-ID: <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> > I think I'd be more inclined to make the code at 970 like that at 1036. Can?t do this exactly as drawImageBGR at 903 does not throw a PrinterException. Have to use RuntimeException. Brian > On Jul 12, 2019, at 1:39 PM, Phil Race wrote: > > oh well ... in which I suppose this is the best you can do here. > > -phil. > > On 7/12/19 1:10 PM, Brian Burkhalter wrote: >> >>> (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. >> >> There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Jul 12 23:15:36 2019 From: philip.race at oracle.com (Philip Race) Date: Fri, 12 Jul 2019 16:15:36 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> Message-ID: <5D291498.8070605@oracle.com> In that case just delete the comments and the commented out code ... -phil. On 7/12/19, 3:12 PM, Brian Burkhalter wrote: >> I think I'd be more inclined to make the code at 970 like that at 1036. > > Can?t do this exactly as drawImageBGR at 903 does not throw a > PrinterException. Have to use RuntimeException. > > Brian > >> On Jul 12, 2019, at 1:39 PM, Phil Race > > wrote: >> >> oh well ... in which I suppose this is the best you can do here. >> >> -phil. >> >> On 7/12/19 1:10 PM, Brian Burkhalter wrote: >>> >>>> (2) I don't know why at 1034 you changed from PrinterIOException to >>>> PrinterException. >>> >>> There is no PrinterIOException constructor which accepts a String as >>> its only parameter and there is no IOException to pass to a >>> PrinterIOException constructor. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jul 15 15:58:32 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 08:58:32 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <5D291498.8070605@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <2FB76DCE-B516-4520-84CA-09188CDE0C86@oracle.com> <6C003DDC-E1CE-437D-A7B6-EF47B19D12C3@oracle.com> <5D291498.8070605@oracle.com> Message-ID: <8F1E9E38-D6F9-4DC0-BBAB-EC644E4628E3@oracle.com> So updated: http://cr.openjdk.java.net/~bpb/8187898/webrev.02/ Thanks, Brian > On Jul 12, 2019, at 4:15 PM, Philip Race wrote: > > In that case just delete the comments and the commented out code ... > > -phil. > > On 7/12/19, 3:12 PM, Brian Burkhalter wrote: >> >>> I think I'd be more inclined to make the code at 970 like that at 1036. >> >> Can?t do this exactly as drawImageBGR at 903 does not throw a PrinterException. Have to use RuntimeException. >> >> Brian >> >>> On Jul 12, 2019, at 1:39 PM, Phil Race > wrote: >>> >>> oh well ... in which I suppose this is the best you can do here. >>> >>> -phil. >>> >>> On 7/12/19 1:10 PM, Brian Burkhalter wrote: >>>> >>>>> (2) I don't know why at 1034 you changed from PrinterIOException to PrinterException. >>>> >>>> There is no PrinterIOException constructor which accepts a String as its only parameter and there is no IOException to pass to a PrinterIOException constructor. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jul 15 16:00:45 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 09:00:45 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> Hello, > On Jul 13, 2019, at 12:00 PM, Tagir Valeev wrote: > > And whilst great you are fixing up this code, we are but a small fraction of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? > > Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? Actually that seems like a better idea: accomplishes the objective while not introducing a compatibility issue. Note: JDK 8199713 reference above is the CSR of the actual issue [1]. Thanks, [1] https://bugs.openjdk.java.net/browse/JDK-8180410 -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Mon Jul 15 17:14:35 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 10:14:35 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> Message-ID: <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. Thanks, Brian > On Jul 15, 2019, at 9:00 AM, Brian Burkhalter wrote: > >> On Jul 13, 2019, at 12:00 PM, Tagir Valeev > wrote: >> >> And whilst great you are fixing up this code, we are but a small fraction of the world's code >> that use java.io and I wonder if this is worth the compatibility risk ? >> >> Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? > > Actually that seems like a better idea: accomplishes the objective while not introducing a compatibility issue. Note: JDK 8199713 reference above is the CSR of the actual issue [1]. > > Thanks, > > [1] https://bugs.openjdk.java.net/browse/JDK-8180410 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anton.litvinov at oracle.com Mon Jul 15 17:26:00 2019 From: anton.litvinov at oracle.com (Anton Litvinov) Date: Mon, 15 Jul 2019 18:26:00 +0100 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> Message-ID: Hello Phil, Thank you for the reply. The second version of the fix with the described in the previous e-mail workaround for the regression test is created. Could you please look at the second version of the fix. The 2nd version of the fix: http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.01 Thank you, Anton On 12/07/2019 19:42, Phil Race wrote: > > Would such a workaround be acceptable as part of this back out fix? > > Yes, very much so ! > > -phil. > > On 7/12/19 11:34 AM, Anton Litvinov wrote: >> Hello Phil, >> >> I tried to apply your code and can confirm that value of "color" is >> always the same for the case, when the test passes and fails. For >> each test run the "paint(Graphics)" method is called either 2 or 3 >> times and this tracing output is always the same and following: >> "color=java.awt.Color[r=255,g=255,b=255] alpha=127" >> >> My today's experiments show that this intermittent failure is >> reproducible with builds prior to the builds with the fix for 8214579 >> and this is also reproducible on Oracle Linux 7.4 x64. I was able to >> reproduce in the following environment configurations: >> >> 1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix >> 8214579 which was integrated in JDK 13+24) >> 2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the >> test itself was introduced), JDK 11+28 (GA build). >> >> I attached a screenshot with the test failure and wrote a comment in >> the bug (https://bugs.openjdk.java.net/browse/JDK-8224825). >> >> MY OBSERVATION: >> >> Although I have not been able to identify the root cause of the >> intermittent test failure, I think that the wrong color is got, when >> the black color, which is set as the background for the frame, is not >> participating in color blending. >> >> THE DISCOVERED WORKAROUND: >> >> I discovered that if the following workaround is applied to the >> regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then >> the intermittent test failure disappears (is not reproducible, when >> test is run 20 times in a row). Also I verified with the workaround >> the test fails as it should with JDK 11+24 (the build without the fix >> 8204931 which was integrated in JDK 11+25 and introduced the test). >> The workaround is following. >> >> Substitute the next 2 code lines: >> >> 77 ?????? frame = new Frame("Alpha Color Test"); >> 78 ?????? frame.setBackground(Color.black); >> >> for the next 8 code lines: >> >> ??????? frame = new Frame("Alpha Color Test") { >> ??????????? @Override >> ??????????? public void paint(Graphics g) { >> ??????????????? g.setColor(Color.black); >> ??????????????? g.fillRect(0, 0, getWidth(), getHeight()); >> ??????????????? super.paint(g); >> ??????????? } >> ??????? }; >> >> Would such a workaround be acceptable as part of this back out fix? >> >> Thank you, >> Anton >> >> On 11/07/2019 19:48, Phil Race wrote: >>> I don't think we ever saw it fail until 8214579 was pushed. >>> I don't know the reason for the color you are sporadically getting >>> in VB >>> Maybe it is slow and the paint event is being missed ? >>> But then I'd expect black .. not light grey. >>> >>> Still, it might be informative to put a print statement in here (in >>> the test) >>> ??? public void paint(Graphics g) { >>> ??????? System.out.println("color=" + color + " alpha=" + >>> color.getAlpha());? // << add this >>> ??????? g.setColor(color); >>> ??????? g.fillRect(0, 0, getSize().width, getSize().height); >>> ??? } >>> >>> and compare what is printed for failing and passing runs. >>> If you can't figure it out quickly, then update the test to not exit >>> so quickly and grab a screen >>> shot of the failure and add it to the bug. >>> >>> >>> -phil. >>> >>> On 7/11/19 11:13 AM, Anton Litvinov wrote: >>>> Hello Phil, >>>> >>>> Thank you for these additional details. I have tried to run the >>>> test "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK 13 >>>> compiled from "jdk/jdk13" with/without this back out fix and the >>>> results are not so stable on my VirtualBox host with openSUSE Leap >>>> 15.0 OS (GNOME 3.26.2): >>>> >>>> 1. "AlphaColorTest.java" stably fails with JDK 13 without this back >>>> out fix and the test failure message is stably: >>>> ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" >>>> >>>> 2. "AlphaColorTest.java" starts passing with JDK 13 with the back >>>> out fix, but continues to intermittently fail with the failure >>>> message: >>>> ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" >>>> >>>> It looks that either this regression test had been failing >>>> intermittently before the fix 8214579, which we are backing out, >>>> was integrated, or some other fix causes this intermittent failure. >>>> >>>> Maybe in this case it is better not to change this >>>> "open/test/jdk/ProblemList.txt" as well as the test itself >>>> "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this >>>> back out fix for JCK test failure? >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 11/07/2019 17:38, Philip Race wrote: >>>>> There is a regression test that is supposed to catch this exact >>>>> problem. >>>>> >>>>> So I had looked into how we did not catch this earlier and found >>>>> that in fact we did. >>>>> This was originally found and filed as >>>>> https://bugs.openjdk.java.net/browse/JDK-8224825 >>>>> The test java/awt/Color/AlphaColorTest.java was then problem >>>>> listed on Linux. >>>>> >>>>> $ grep AlphaColorTest test/jdk/ProblemList.txt >>>>> java/awt/Color/AlphaColorTest.java 8224825 linux-all >>>>> >>>>> So I think we can close JDK-8224825 as a duplicate of this as well >>>>> as updating the problem list >>>>> and the test - after confirming that this backout resolves that as >>>>> I expect it will. >>>>> >>>>> -phil. >>>>> >>>>> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>>>>> By your request regenerated the webrev specifically against >>>>>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>>>>> JDK 13 specific webrev: >>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>>>>> >>>>>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>>>>> "ColorTest0004" from the test >>>>>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >>>>>> anymore after this fix is applied to JDK 13 compiled from >>>>>> "jdk/jdk13" repository. >>>>>> >>>>>> "jdk/jdk13" repository does not contain any problem list >>>>>> mentioning "api/java_awt/interactive/ColorTests.html" test from >>>>>> JCK 13, thus I cannot de-problem list it and have no idea, where >>>>>> it is problem-listed. I also doubt that it is problem-listed, >>>>>> since it is manual. I added "noreg-jck" label to the bug in JBS >>>>>> deliberately according to OpenJDK process (Section #6 from the >>>>>> web page (http://openjdk.java.net/guide/changePlanning.html)), >>>>>> because this back out fix does not contain a new separate >>>>>> regression test, while this regression can be checked by running >>>>>> existing mentioned above test from JCK package. >>>>>> >>>>>> If this "noreg-jck" label creates problems, I can remove it at all. >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>>> >>>>>> On 11/07/2019 15:51, Philip Race wrote: >>>>>>> One more thing I just realised you should do here is de-problem >>>>>>> list >>>>>>> the regression test that fails ... after verifying it now works, >>>>>>> updating it with this bug ID. >>>>>>> And you can remove that noreg-jck label as a consequence. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>>>>> In such cases I like more than to be told "it would apply >>>>>>>> cleanly" but also to see >>>>>>>> that you actually prepared the webrev against 13. This is more >>>>>>>> certain >>>>>>>> and ensures that when the fix is approved you don't >>>>>>>> accidentally push it >>>>>>>> to the wrong repo. You have to go clone 13 and apply the patch >>>>>>>> there anyway ... >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>>>>> Hello Phil, >>>>>>>>> >>>>>>>>> Thank you for review and the important remark about the need >>>>>>>>> to work with "jdk/jdk13" stabilization repository, I forgot >>>>>>>>> about this feature of post RDP 1 phase. Today I checked the >>>>>>>>> fix against "jdk/jdk13" repository and confirm that it >>>>>>>>> resolves this bug for JDK 13. >>>>>>>>> >>>>>>>>> Will wait for feedback or approval from any other second code >>>>>>>>> reviewer. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Anton >>>>>>>>> >>>>>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>>>>> Anton, >>>>>>>>>> >>>>>>>>>> This looks fine except that it needs to be prepared against >>>>>>>>>> 13, and then pushed there, not 14. >>>>>>>>>> And it will get forwarded synced from 13 to 14. That is the >>>>>>>>>> RDP process .. >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you please review the following fix for the bug. The >>>>>>>>>>> fix is backing out of the fix for the bug JDK-8214579 which >>>>>>>>>>> caused this JCK test failure. If this fix is accepted, then >>>>>>>>>>> a new separate bug for readdressing the bug reported in >>>>>>>>>>> JDK-8214579 will be filed. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>>>>> Changeset of JDK-8214579: >>>>>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Anton >>>>>>>>>> >>>>>>>>> >>>>>> >>>> >>> >> > From philip.race at oracle.com Mon Jul 15 19:31:30 2019 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Jul 2019 12:31:30 -0700 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> Message-ID: Looks good! -phil. On 7/15/19 10:26 AM, Anton Litvinov wrote: > Hello Phil, > > Thank you for the reply. The second version of the fix with the > described in the previous e-mail workaround for the regression test is > created. Could you please look at the second version of the fix. > > The 2nd version of the fix: > http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.01 > > Thank you, > Anton > > On 12/07/2019 19:42, Phil Race wrote: >> > Would such a workaround be acceptable as part of this back out fix? >> >> Yes, very much so ! >> >> -phil. >> >> On 7/12/19 11:34 AM, Anton Litvinov wrote: >>> Hello Phil, >>> >>> I tried to apply your code and can confirm that value of "color" is >>> always the same for the case, when the test passes and fails. For >>> each test run the "paint(Graphics)" method is called either 2 or 3 >>> times and this tracing output is always the same and following: >>> "color=java.awt.Color[r=255,g=255,b=255] alpha=127" >>> >>> My today's experiments show that this intermittent failure is >>> reproducible with builds prior to the builds with the fix for >>> 8214579 and this is also reproducible on Oracle Linux 7.4 x64. I was >>> able to reproduce in the following environment configurations: >>> >>> 1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix >>> 8214579 which was integrated in JDK 13+24) >>> 2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the >>> test itself was introduced), JDK 11+28 (GA build). >>> >>> I attached a screenshot with the test failure and wrote a comment in >>> the bug (https://bugs.openjdk.java.net/browse/JDK-8224825). >>> >>> MY OBSERVATION: >>> >>> Although I have not been able to identify the root cause of the >>> intermittent test failure, I think that the wrong color is got, when >>> the black color, which is set as the background for the frame, is >>> not participating in color blending. >>> >>> THE DISCOVERED WORKAROUND: >>> >>> I discovered that if the following workaround is applied to the >>> regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then >>> the intermittent test failure disappears (is not reproducible, when >>> test is run 20 times in a row). Also I verified with the workaround >>> the test fails as it should with JDK 11+24 (the build without the >>> fix 8204931 which was integrated in JDK 11+25 and introduced the >>> test). The workaround is following. >>> >>> Substitute the next 2 code lines: >>> >>> 77 ?????? frame = new Frame("Alpha Color Test"); >>> 78 ?????? frame.setBackground(Color.black); >>> >>> for the next 8 code lines: >>> >>> ??????? frame = new Frame("Alpha Color Test") { >>> ??????????? @Override >>> ??????????? public void paint(Graphics g) { >>> ??????????????? g.setColor(Color.black); >>> ??????????????? g.fillRect(0, 0, getWidth(), getHeight()); >>> ??????????????? super.paint(g); >>> ??????????? } >>> ??????? }; >>> >>> Would such a workaround be acceptable as part of this back out fix? >>> >>> Thank you, >>> Anton >>> >>> On 11/07/2019 19:48, Phil Race wrote: >>>> I don't think we ever saw it fail until 8214579 was pushed. >>>> I don't know the reason for the color you are sporadically getting >>>> in VB >>>> Maybe it is slow and the paint event is being missed ? >>>> But then I'd expect black .. not light grey. >>>> >>>> Still, it might be informative to put a print statement in here (in >>>> the test) >>>> ??? public void paint(Graphics g) { >>>> ??????? System.out.println("color=" + color + " alpha=" + >>>> color.getAlpha());? // << add this >>>> ??????? g.setColor(color); >>>> ??????? g.fillRect(0, 0, getSize().width, getSize().height); >>>> ??? } >>>> >>>> and compare what is printed for failing and passing runs. >>>> If you can't figure it out quickly, then update the test to not >>>> exit so quickly and grab a screen >>>> shot of the failure and add it to the bug. >>>> >>>> >>>> -phil. >>>> >>>> On 7/11/19 11:13 AM, Anton Litvinov wrote: >>>>> Hello Phil, >>>>> >>>>> Thank you for these additional details. I have tried to run the >>>>> test "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK >>>>> 13 compiled from "jdk/jdk13" with/without this back out fix and >>>>> the results are not so stable on my VirtualBox host with openSUSE >>>>> Leap 15.0 OS (GNOME 3.26.2): >>>>> >>>>> 1. "AlphaColorTest.java" stably fails with JDK 13 without this >>>>> back out fix and the test failure message is stably: >>>>> ??? "Color is not as expected. Got java.awt.Color[r=255,g=255,b=255]" >>>>> >>>>> 2. "AlphaColorTest.java" starts passing with JDK 13 with the back >>>>> out fix, but continues to intermittently fail with the failure >>>>> message: >>>>> ??? "Color is not as expected. Got java.awt.Color[r=189,g=189,b=189]" >>>>> >>>>> It looks that either this regression test had been failing >>>>> intermittently before the fix 8214579, which we are backing out, >>>>> was integrated, or some other fix causes this intermittent failure. >>>>> >>>>> Maybe in this case it is better not to change this >>>>> "open/test/jdk/ProblemList.txt" as well as the test itself >>>>> "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of this >>>>> back out fix for JCK test failure? >>>>> >>>>> Thank you, >>>>> Anton >>>>> >>>>> On 11/07/2019 17:38, Philip Race wrote: >>>>>> There is a regression test that is supposed to catch this exact >>>>>> problem. >>>>>> >>>>>> So I had looked into how we did not catch this earlier and found >>>>>> that in fact we did. >>>>>> This was originally found and filed as >>>>>> https://bugs.openjdk.java.net/browse/JDK-8224825 >>>>>> The test java/awt/Color/AlphaColorTest.java was then problem >>>>>> listed on Linux. >>>>>> >>>>>> $ grep AlphaColorTest test/jdk/ProblemList.txt >>>>>> java/awt/Color/AlphaColorTest.java 8224825 linux-all >>>>>> >>>>>> So I think we can close JDK-8224825 as a duplicate of this as >>>>>> well as updating the problem list >>>>>> and the test - after confirming that this backout resolves that >>>>>> as I expect it will. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>>>>>> By your request regenerated the webrev specifically against >>>>>>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>>>>>> JDK 13 specific webrev: >>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>>>>>> >>>>>>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>>>>>> "ColorTest0004" from the test >>>>>>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not fail >>>>>>> anymore after this fix is applied to JDK 13 compiled from >>>>>>> "jdk/jdk13" repository. >>>>>>> >>>>>>> "jdk/jdk13" repository does not contain any problem list >>>>>>> mentioning "api/java_awt/interactive/ColorTests.html" test from >>>>>>> JCK 13, thus I cannot de-problem list it and have no idea, where >>>>>>> it is problem-listed. I also doubt that it is problem-listed, >>>>>>> since it is manual. I added "noreg-jck" label to the bug in JBS >>>>>>> deliberately according to OpenJDK process (Section #6 from the >>>>>>> web page (http://openjdk.java.net/guide/changePlanning.html)), >>>>>>> because this back out fix does not contain a new separate >>>>>>> regression test, while this regression can be checked by running >>>>>>> existing mentioned above test from JCK package. >>>>>>> >>>>>>> If this "noreg-jck" label creates problems, I can remove it at all. >>>>>>> >>>>>>> Thank you, >>>>>>> Anton >>>>>>> >>>>>>> On 11/07/2019 15:51, Philip Race wrote: >>>>>>>> One more thing I just realised you should do here is de-problem >>>>>>>> list >>>>>>>> the regression test that fails ... after verifying it now works, >>>>>>>> updating it with this bug ID. >>>>>>>> And you can remove that noreg-jck label as a consequence. >>>>>>>> >>>>>>>> -phil. >>>>>>>> >>>>>>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>>>>>> In such cases I like more than to be told "it would apply >>>>>>>>> cleanly" but also to see >>>>>>>>> that you actually prepared the webrev against 13. This is more >>>>>>>>> certain >>>>>>>>> and ensures that when the fix is approved you don't >>>>>>>>> accidentally push it >>>>>>>>> to the wrong repo. You have to go clone 13 and apply the patch >>>>>>>>> there anyway ... >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>>>>>> Hello Phil, >>>>>>>>>> >>>>>>>>>> Thank you for review and the important remark about the need >>>>>>>>>> to work with "jdk/jdk13" stabilization repository, I forgot >>>>>>>>>> about this feature of post RDP 1 phase. Today I checked the >>>>>>>>>> fix against "jdk/jdk13" repository and confirm that it >>>>>>>>>> resolves this bug for JDK 13. >>>>>>>>>> >>>>>>>>>> Will wait for feedback or approval from any other second code >>>>>>>>>> reviewer. >>>>>>>>>> >>>>>>>>>> Thank you, >>>>>>>>>> Anton >>>>>>>>>> >>>>>>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>>>>>> Anton, >>>>>>>>>>> >>>>>>>>>>> This looks fine except that it needs to be prepared against >>>>>>>>>>> 13, and then pushed there, not 14. >>>>>>>>>>> And it will get forwarded synced from 13 to 14. That is the >>>>>>>>>>> RDP process .. >>>>>>>>>>> >>>>>>>>>>> -phil. >>>>>>>>>>> >>>>>>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you please review the following fix for the bug. The >>>>>>>>>>>> fix is backing out of the fix for the bug JDK-8214579 which >>>>>>>>>>>> caused this JCK test failure. If this fix is accepted, then >>>>>>>>>>>> a new separate bug for readdressing the bug reported in >>>>>>>>>>>> JDK-8214579 will be filed. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>>>>>> Changeset of JDK-8214579: >>>>>>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>>>>>> >>>>>>>>>>>> Thank you, >>>>>>>>>>>> Anton >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From brian.burkhalter at oracle.com Mon Jul 15 20:07:22 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 15 Jul 2019 13:07:22 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> Message-ID: <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> There is however this problematic statement in the PrintStream class doc that neither of the two alternative versions of the fix addresses: "Two other features are provided as well. Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method.? In both cases this would need to be changed as it is incorrect. Brian > On Jul 15, 2019, at 10:14 AM, Brian Burkhalter wrote: > > Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): > > http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ > > > This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Jul 16 09:10:55 2019 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 16 Jul 2019 14:40:55 +0530 Subject: [OpenJDK 2D-Dev] [14] Review request for 8227392: Colors with alpha are painted incorrectly on Linux, after JDK-8214579 In-Reply-To: References: <32e40cfc-8992-0bd4-daf7-c9f593cb007e@oracle.com> <5D274919.5070702@oracle.com> <5D274CF5.80703@oracle.com> <38652391-4aa2-b499-d5db-08131dfe87ed@oracle.com> <5D2765EF.7010900@oracle.com> <32c994f3-71a9-23a2-11a0-f39eaafaa34b@oracle.com> <3a9e27a4-1c19-6104-7cae-87f0366ec659@oracle.com> Message-ID: <2417ec24-a530-af57-929d-6bcc48c89c4d@oracle.com> +1 Regards Prasanta On 16-Jul-19 1:01 AM, Phil Race wrote: > > Looks good! > > -phil. > > On 7/15/19 10:26 AM, Anton Litvinov wrote: >> Hello Phil, >> >> Thank you for the reply. The second version of the fix with the >> described in the previous e-mail workaround for the regression test >> is created. Could you please look at the second version of the fix. >> >> The 2nd version of the fix: >> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.01 >> >> Thank you, >> Anton >> >> On 12/07/2019 19:42, Phil Race wrote: >>> > Would such a workaround be acceptable as part of this back out fix? >>> >>> Yes, very much so ! >>> >>> -phil. >>> >>> On 7/12/19 11:34 AM, Anton Litvinov wrote: >>>> Hello Phil, >>>> >>>> I tried to apply your code and can confirm that value of "color" is >>>> always the same for the case, when the test passes and fails. For >>>> each test run the "paint(Graphics)" method is called either 2 or 3 >>>> times and this tracing output is always the same and following: >>>> "color=java.awt.Color[r=255,g=255,b=255] alpha=127" >>>> >>>> My today's experiments show that this intermittent failure is >>>> reproducible with builds prior to the builds with the fix for >>>> 8214579 and this is also reproducible on Oracle Linux 7.4 x64. I >>>> was able to reproduce in the following environment configurations: >>>> >>>> 1. Oracle Linux 7.4 x64 with JDK 13+23 (the build without the fix >>>> 8214579 which was integrated in JDK 13+24) >>>> 2. openSUSE Leap 15.0 with JDK 13+23, JDK 11+25 (build in which the >>>> test itself was introduced), JDK 11+28 (GA build). >>>> >>>> I attached a screenshot with the test failure and wrote a comment >>>> in the bug (https://bugs.openjdk.java.net/browse/JDK-8224825). >>>> >>>> MY OBSERVATION: >>>> >>>> Although I have not been able to identify the root cause of the >>>> intermittent test failure, I think that the wrong color is got, >>>> when the black color, which is set as the background for the frame, >>>> is not participating in color blending. >>>> >>>> THE DISCOVERED WORKAROUND: >>>> >>>> I discovered that if the following workaround is applied to the >>>> regression test "test/jdk/java/awt/Color/AlphaColorTest.java", then >>>> the intermittent test failure disappears (is not reproducible, when >>>> test is run 20 times in a row). Also I verified with the workaround >>>> the test fails as it should with JDK 11+24 (the build without the >>>> fix 8204931 which was integrated in JDK 11+25 and introduced the >>>> test). The workaround is following. >>>> >>>> Substitute the next 2 code lines: >>>> >>>> 77 ?????? frame = new Frame("Alpha Color Test"); >>>> 78 ?????? frame.setBackground(Color.black); >>>> >>>> for the next 8 code lines: >>>> >>>> ??????? frame = new Frame("Alpha Color Test") { >>>> ??????????? @Override >>>> ??????????? public void paint(Graphics g) { >>>> ??????????????? g.setColor(Color.black); >>>> ??????????????? g.fillRect(0, 0, getWidth(), getHeight()); >>>> ??????????????? super.paint(g); >>>> ??????????? } >>>> ??????? }; >>>> >>>> Would such a workaround be acceptable as part of this back out fix? >>>> >>>> Thank you, >>>> Anton >>>> >>>> On 11/07/2019 19:48, Phil Race wrote: >>>>> I don't think we ever saw it fail until 8214579 was pushed. >>>>> I don't know the reason for the color you are sporadically getting >>>>> in VB >>>>> Maybe it is slow and the paint event is being missed ? >>>>> But then I'd expect black .. not light grey. >>>>> >>>>> Still, it might be informative to put a print statement in here >>>>> (in the test) >>>>> ??? public void paint(Graphics g) { >>>>> ??????? System.out.println("color=" + color + " alpha=" + >>>>> color.getAlpha());? // << add this >>>>> ??????? g.setColor(color); >>>>> ??????? g.fillRect(0, 0, getSize().width, getSize().height); >>>>> ??? } >>>>> >>>>> and compare what is printed for failing and passing runs. >>>>> If you can't figure it out quickly, then update the test to not >>>>> exit so quickly and grab a screen >>>>> shot of the failure and add it to the bug. >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 7/11/19 11:13 AM, Anton Litvinov wrote: >>>>>> Hello Phil, >>>>>> >>>>>> Thank you for these additional details. I have tried to run the >>>>>> test "open/test/jdk/java/awt/Color/AlphaColorTest.java" with JDK >>>>>> 13 compiled from "jdk/jdk13" with/without this back out fix and >>>>>> the results are not so stable on my VirtualBox host with openSUSE >>>>>> Leap 15.0 OS (GNOME 3.26.2): >>>>>> >>>>>> 1. "AlphaColorTest.java" stably fails with JDK 13 without this >>>>>> back out fix and the test failure message is stably: >>>>>> ??? "Color is not as expected. Got >>>>>> java.awt.Color[r=255,g=255,b=255]" >>>>>> >>>>>> 2. "AlphaColorTest.java" starts passing with JDK 13 with the back >>>>>> out fix, but continues to intermittently fail with the failure >>>>>> message: >>>>>> ??? "Color is not as expected. Got >>>>>> java.awt.Color[r=189,g=189,b=189]" >>>>>> >>>>>> It looks that either this regression test had been failing >>>>>> intermittently before the fix 8214579, which we are backing out, >>>>>> was integrated, or some other fix causes this intermittent failure. >>>>>> >>>>>> Maybe in this case it is better not to change this >>>>>> "open/test/jdk/ProblemList.txt" as well as the test itself >>>>>> "open/test/jdk/java/awt/Color/AlphaColorTest.java" as part of >>>>>> this back out fix for JCK test failure? >>>>>> >>>>>> Thank you, >>>>>> Anton >>>>>> >>>>>> On 11/07/2019 17:38, Philip Race wrote: >>>>>>> There is a regression test that is supposed to catch this exact >>>>>>> problem. >>>>>>> >>>>>>> So I had looked into how we did not catch this earlier and found >>>>>>> that in fact we did. >>>>>>> This was originally found and filed as >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8224825 >>>>>>> The test java/awt/Color/AlphaColorTest.java was then problem >>>>>>> listed on Linux. >>>>>>> >>>>>>> $ grep AlphaColorTest test/jdk/ProblemList.txt >>>>>>> java/awt/Color/AlphaColorTest.java 8224825 linux-all >>>>>>> >>>>>>> So I think we can close JDK-8224825 as a duplicate of this as >>>>>>> well as updating the problem list >>>>>>> and the test - after confirming that this backout resolves that >>>>>>> as I expect it will. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>>> On 7/11/19, 9:20 AM, Anton Litvinov wrote: >>>>>>>> By your request regenerated the webrev specifically against >>>>>>>> (http://hg.openjdk.java.net/jdk/jdk13) repository. >>>>>>>> JDK 13 specific webrev: >>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk13/webrev.00 >>>>>>>> >>>>>>>> I confirm again, that 2 failing manual tests: "ColorTest0003", >>>>>>>> "ColorTest0004" from the test >>>>>>>> "api/java_awt/interactive/ColorTests.html" in JCK 13 do not >>>>>>>> fail anymore after this fix is applied to JDK 13 compiled from >>>>>>>> "jdk/jdk13" repository. >>>>>>>> >>>>>>>> "jdk/jdk13" repository does not contain any problem list >>>>>>>> mentioning "api/java_awt/interactive/ColorTests.html" test from >>>>>>>> JCK 13, thus I cannot de-problem list it and have no idea, >>>>>>>> where it is problem-listed. I also doubt that it is >>>>>>>> problem-listed, since it is manual. I added "noreg-jck" label >>>>>>>> to the bug in JBS deliberately according to OpenJDK process >>>>>>>> (Section #6 from the web page >>>>>>>> (http://openjdk.java.net/guide/changePlanning.html)), because >>>>>>>> this back out fix does not contain a new separate regression >>>>>>>> test, while this regression can be checked by running existing >>>>>>>> mentioned above test from JCK package. >>>>>>>> >>>>>>>> If this "noreg-jck" label creates problems, I can remove it at >>>>>>>> all. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Anton >>>>>>>> >>>>>>>> On 11/07/2019 15:51, Philip Race wrote: >>>>>>>>> One more thing I just realised you should do here is >>>>>>>>> de-problem list >>>>>>>>> the regression test that fails ... after verifying it now works, >>>>>>>>> updating it with this bug ID. >>>>>>>>> And you can remove that noreg-jck label as a consequence. >>>>>>>>> >>>>>>>>> -phil. >>>>>>>>> >>>>>>>>> On 7/11/19, 7:35 AM, Philip Race wrote: >>>>>>>>>> In such cases I like more than to be told "it would apply >>>>>>>>>> cleanly" but also to see >>>>>>>>>> that you actually prepared the webrev against 13. This is >>>>>>>>>> more certain >>>>>>>>>> and ensures that when the fix is approved you don't >>>>>>>>>> accidentally push it >>>>>>>>>> to the wrong repo. You have to go clone 13 and apply the >>>>>>>>>> patch there anyway ... >>>>>>>>>> >>>>>>>>>> -phil. >>>>>>>>>> >>>>>>>>>> On 7/11/19, 5:44 AM, Anton Litvinov wrote: >>>>>>>>>>> Hello Phil, >>>>>>>>>>> >>>>>>>>>>> Thank you for review and the important remark about the need >>>>>>>>>>> to work with "jdk/jdk13" stabilization repository, I forgot >>>>>>>>>>> about this feature of post RDP 1 phase. Today I checked the >>>>>>>>>>> fix against "jdk/jdk13" repository and confirm that it >>>>>>>>>>> resolves this bug for JDK 13. >>>>>>>>>>> >>>>>>>>>>> Will wait for feedback or approval from any other second >>>>>>>>>>> code reviewer. >>>>>>>>>>> >>>>>>>>>>> Thank you, >>>>>>>>>>> Anton >>>>>>>>>>> >>>>>>>>>>> On 10/07/2019 19:55, Phil Race wrote: >>>>>>>>>>>> Anton, >>>>>>>>>>>> >>>>>>>>>>>> This looks fine except that it needs to be prepared against >>>>>>>>>>>> 13, and then pushed there, not 14. >>>>>>>>>>>> And it will get forwarded synced from 13 to 14. That is the >>>>>>>>>>>> RDP process .. >>>>>>>>>>>> >>>>>>>>>>>> -phil. >>>>>>>>>>>> >>>>>>>>>>>> On 7/10/19 5:00 AM, Anton Litvinov wrote: >>>>>>>>>>>>> Hello, >>>>>>>>>>>>> >>>>>>>>>>>>> Could you please review the following fix for the bug. The >>>>>>>>>>>>> fix is backing out of the fix for the bug JDK-8214579 >>>>>>>>>>>>> which caused this JCK test failure. If this fix is >>>>>>>>>>>>> accepted, then a new separate bug for readdressing the bug >>>>>>>>>>>>> reported in JDK-8214579 will be filed. >>>>>>>>>>>>> >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8227392 >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~alitvinov/8227392/jdk14/webrev.00 >>>>>>>>>>>>> Changeset of JDK-8214579: >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk/client/rev/c53905e7dc57 >>>>>>>>>>>>> >>>>>>>>>>>>> Thank you, >>>>>>>>>>>>> Anton >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > From matthias.baesken at sap.com Tue Jul 16 15:08:59 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 16 Jul 2019 15:08:59 +0000 Subject: [OpenJDK 2D-Dev] RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file References: <5D24B1EB.10201@oracle.com> Message-ID: Ping , any comments on this one ? Thanks, Matthias From: Baesken, Matthias Sent: Mittwoch, 10. Juli 2019 08:49 To: 2d-dev at openjdk.java.net Cc: Phil Race (philip.race at oracle.com) Subject: FW: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file >Before I, or anyone else, starts to look at or comment on this, >can you instead post to the correct list : 2d-dev. Sure! Best regards, Matthias From: Philip Race > Sent: Dienstag, 9. Juli 2019 17:26 To: Baesken, Matthias > Cc: awt-dev at openjdk.java.net Subject: Re: RFR [XS] : 8227441: Enhance logging when reading the fontconfig info file 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 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: [OpenJDK 2D-Dev] 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 brian.burkhalter at oracle.com Thu Jul 18 15:32:36 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 18 Jul 2019 08:32:36 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> Message-ID: <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> Resuming this topic, what is the general view on the three possible paths: 1. Override write(byte[]) at the risk of incompatibility. 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. 3. Resolve as Won?t Fix. For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. Thanks, Brian > On Jul 15, 2019, at 1:07 PM, Brian Burkhalter wrote: > > There is however this problematic statement in the PrintStream class doc that neither of the two alternative versions of the fix addresses: > > "Two other features are provided as well. Unlike other output streams, a PrintStream never throws an IOException; instead, exceptional situations merely set an internal flag that can be tested via the checkError method.? > > In both cases this would need to be changed as it is incorrect. > > Brian > >> On Jul 15, 2019, at 10:14 AM, Brian Burkhalter > wrote: >> >> Here is an alternative version which adds a writeBytes(byte[]) method instead of overriding write(byte[]): >> >> http://cr.openjdk.java.net/~bpb/8187898/webrev-alt.00/ > >> >> This has the advantage of allowing new code to call writeBytes() without a try-catch block without introducing a compatibility issue for code which is already calling write(byte[]) in a try-catch block. -------------- 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: [OpenJDK 2D-Dev] 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 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: [OpenJDK 2D-Dev] 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 Alan.Bateman at oracle.com Sat Jul 20 16:15:10 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 20 Jul 2019 17:15:10 +0100 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> Message-ID: On 18/07/2019 16:32, Brian Burkhalter wrote: > Resuming this topic, what is the general view on the three possible paths: > > 1. Override write(byte[]) at the risk of incompatibility. > 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. > 3. Resolve as Won?t Fix. > > For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. > PrintStream dates from JDK 1.0 so I don't think it's feasible to add an override now that doesn't throw IOE. Tagir's suggestion to add a writeBytes(byte[]) seem fine, assuming there is a great need. Alternatively you can add an override (that throws IOE) so that you have somewhere for an @apiNote that suggests using write(b,0,b.len) as "exception-less" write. -Alan From christoph.langer at sap.com Mon Jul 22 06:28:57 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 22 Jul 2019 06:28:57 +0000 Subject: [OpenJDK 2D-Dev] [12u] RFR (S): 8228466: Fix build on AIX and with Solaris Studio 12u4 in 12u after HarfBuzz 2.3.1 upgrade Message-ID: Hi, please review and approve this patch for fixing the AIX and the Solaris/SS12u4 build of JDK12u. Bug: https://bugs.openjdk.java.net/browse/JDK-8228466 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8228466.0/ The build issues were only discovered after the final OpenJDK 12.0.2 source was published. Initially I only reported AIX but we also see the build broken on Solaris with the older Sun Studio level 12u4. As per [0], Oracle builds 12u with SS12u6 but we at SAP still used 12u4 and found it working until then. The fix for Solaris seems to be small and harmless, so I request to integrate it as well. The changes prove to work in JDK 11.0.4 [1]. As per prior discussion [2], I request review and approval for pushing this to 12u. Thanks Christoph [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms [1] http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a267d045754a [2] https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-July/001441.html -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [OpenJDK 2D-Dev] 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 brian.burkhalter at oracle.com Mon Jul 22 15:15:26 2019 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 22 Jul 2019 08:15:26 -0700 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> <71C745EA-D0C0-44FE-BBF8-0F9119078AD5@oracle.com> <714892D5-194F-4856-95F1-E38C6D7FF714@oracle.com> <91BF9F6F-5969-40AF-8E51-92D5E045F6D9@oracle.com> <532398EA-B7F8-4803-A038-A0F54DCD460F@oracle.com> Message-ID: <426428C0-F710-4262-9E5A-247D0D267059@oracle.com> > On Jul 20, 2019, at 9:15 AM, Alan Bateman wrote: > > On 18/07/2019 16:32, Brian Burkhalter wrote: >> Resuming this topic, what is the general view on the three possible paths: >> >> 1. Override write(byte[]) at the risk of incompatibility. >> 2. Instead add writeBytes(byte[]) as in ByteArrayOutputStream. >> 3. Resolve as Won?t Fix. >> >> For 2 or 3 the incorrect class level statement about overriding all methods not to throw IOE would need to be dealt with. >> > PrintStream dates from JDK 1.0 so I don't think it's feasible to add an override now that doesn't throw IOE. Agreed. > Tagir's suggestion to add a writeBytes(byte[]) seem fine, assuming there is a great need. Not sure of the need but there is the precedent of BAIS. > Alternatively you can add an override (that throws IOE) so that you have somewhere for an @apiNote that suggests using write(b,0,b.len) as "exception-less" write. That?s a good idea. Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [OpenJDK 2D-Dev] 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 Fri Jul 26 21:48:27 2019 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 26 Jul 2019 14:48:27 -0700 Subject: [OpenJDK 2D-Dev] [14] Review Request: 8228676 Cleanup the native code related to fonts on Unix Message-ID: Hello. Please review the fix for JDK 14. Bug: https://bugs.openjdk.java.net/browse/JDK-8228676 Fix: http://cr.openjdk.java.net/~serb/8228676/webrev.00 There is some amount of code which is unused since MToolkit was removed. In the fix, unused code was removed, note that some stubs like xx_initIDs still present in the code, because they are still called from the java side. Mach5 is green. The fix itself is similar to the previous fixes: https://bugs.openjdk.java.net/browse/JDK-8223766 https://bugs.openjdk.java.net/browse/JDK-8224171 -- Best regards, Sergey. From bourges.laurent at gmail.com Mon Jul 29 07:56:16 2019 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 29 Jul 2019 09:56:16 +0200 Subject: [OpenJDK 2D-Dev] RFR [14]: JDK-8228711: Path rendered incorrectly when it goes outside the clipping region Message-ID: Hi, Please review this bug fix for the Marlin renderer (introduced in JDK11.0.2): JBS: https://bugs.openjdk.java.net/browse/JDK-8228711 webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8228711.0/ This patch is very close to MarlinFX patch integrated last week in OpenJFX 14, see https://bugs.openjdk.java.net/browse/JDK-8226789 Changes: - Stroker: fixed closePath() to preserve last position and its outcode - TransformingPathConsumer2D: fixed PathClipFilter.closePath() to preserve last position and its outcode - Dasher: better precision handling (comparison float value with epsilon) - ClipShapeTest: use preliminary curve subdivision (length > 50px) to avoid false positives on long stroked curves (quad / cubic) + lowered thresholds Cheers, Laurent -------------- next part -------------- An HTML attachment was scrubbed... URL: From amaembo at gmail.com Sat Jul 13 19:00:43 2019 From: amaembo at gmail.com (Tagir Valeev) Date: Sat, 13 Jul 2019 19:00:43 -0000 Subject: [OpenJDK 2D-Dev] 8187898: PrintStream should override FilterOutputStream#write(byte[]) with a method that has no throws clause In-Reply-To: <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> References: <86A0C35F-93C1-4F45-8723-72B723024B39@oracle.com> <2d6a465b-8f1d-6365-42f7-446381197474@oracle.com> Message-ID: Hello! > And whilst great you are fixing up this code, we are but a small fraction > of the world's code > that use java.io and I wonder if this is worth the compatibility risk ? > Why not introducing a separate writeBytes method like it was done for ByteArrayOutputStream (JDK-8199713)? With best regards, Tagir Valeev > -phil > > > > On 7/12/19 12:54 PM, Brian Burkhalter wrote: > > Here is new webrev incorporating the two changes below. > > > > http://cr.openjdk.java.net/~bpb/8187898/webrev.01/ > > > > Thanks, > > > > Brian > > > >> On Jul 12, 2019, at 12:01 PM, Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> > >>> On Jul 12, 2019, at 11:17 AM, Roger Riggs > wrote: > >>> > >>> Would it be appropriate to add @Override to the new method (and > perhaps existing overridden methods). > >> Yes, I think so. > >> > >>> Previously, calling FilterOutputStream.write(byte[]) would delegate to > write(byte[], 0, length). > >>> The proposed change duplicates the code and changes the ways that > overridden classes might see the call. > >>> What's the benefit of duplicating the code and calling out.write(buf)? > >> Probably nothing. Probably better to call write(b,0,b.length) directly. > >> > >>> Not my call, but in PSPrinterJob.java (970-977) it might be cleaner to > just delete the unused code and comment. > >> I agree but I was waiting for a suggestion from a 2D reviewer. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: