Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Alexander Scherbatiy
> FontManagerFactory class uses reflection to load platform specific > FontManager classes from "sun.font.fontmanager" property. > > Fix proposes creating FontManager platform specific classes directly in the > similar way as it has been already done for GraphicsEnvironment and AWT > Toolkit ([

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v5]

2021-09-20 Thread Alexander Scherbatiy
On Sat, 18 Sep 2021 22:51:34 GMT, Sergey Bylokhov wrote: >> Alexander Scherbatiy has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Change Solaris default implementation to Mac OS in FontManagerFactory >> comment > > src/java.desktop/share

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Alexander Scherbatiy
On Sat, 18 Sep 2021 23:08:21 GMT, Sergey Bylokhov wrote: >> The method `FontManagerFactory.getInstance()` is updated to use DLC. >> >> I used synchronization on FontManagerFactory.class in the first check to be >> consistent with the previous behavior where synchronization was on the >> `FontM

Re: RFR: 8272756: Remove unnecessary explicit initialization of volatile variables in java.desktop

2021-09-20 Thread Andrey Turbanov
On Fri, 20 Aug 2021 09:41:15 GMT, Сергей Цыпанов wrote: > This is a continuation of > > - https://bugs.openjdk.java.net/browse/JDK-6736490 > - https://bugs.openjdk.java.net/browse/JDK-8035284 > - https://bugs.openjdk.java.net/browse/JDK-8145680 > - https://bugs.openjdk.java.net/browse/JDK-82515

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Brett Okken
On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy wrote: >> FontManagerFactory class uses reflection to load platform specific >> FontManager classes from "sun.font.fontmanager" property. >> >> Fix proposes creating FontManager platform specific classes directly in the >> similar way as

Re: RFR: 8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

2021-09-20 Thread Alexey Ivanov
On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov wrote: > This calls are redundant, because order of `p0` and `p1` is checked in method > pre-conditions. > Checks were added under > [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - > https://github.com/openjdk/jdk/commit/79ed

Integrated: 8270609: [TESTBUG] java/awt/print/Dialog/DialogCopies.java does not show instruction

2021-09-20 Thread lawrence . andrews
On Tue, 20 Jul 2021 23:54:20 GMT, lawrence.andrews wrote: > 1) When the test is executed via jtreg user can see only print dialog with no > instruction to the user. User has to see the test case to see the instruction > and perform the test . > 2) With this fix User is instructed what he/she

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Phil Race
On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy wrote: >> FontManagerFactory class uses reflection to load platform specific >> FontManager classes from "sun.font.fontmanager" property. >> >> Fix proposes creating FontManager platform specific classes directly in the >> similar way as

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Brett Okken
On Mon, 20 Sep 2021 11:27:32 GMT, Alexander Scherbatiy wrote: >> The SunFontManager constructor and its subclasses seem too big, and >> potentially throw some exceptions and this will ruin the holder idiom since >> all subsequent calls to this method will fail. > > I wrote a simple example whi

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Sergey Bylokhov
On Mon, 20 Sep 2021 16:55:49 GMT, Brett Okken wrote: >> I wrote a simple example which uses DLC and lazy initialization holder class >> idioms. The FontManager is only created when it is accessed the first time >> via the getInstance() method in both cases and they both fail if an >> exceptio

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Alexander Zvegintsev
On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy wrote: >> FontManagerFactory class uses reflection to load platform specific >> FontManager classes from "sun.font.fontmanager" property. >> >> Fix proposes creating FontManager platform specific classes directly in the >> similar way as

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Brett Okken
On Mon, 20 Sep 2021 16:58:49 GMT, Sergey Bylokhov wrote: >> Does that stack trace difference really matter? >> if so, you could wrap the `return FontManagerHolder.instance;` in a >> try/catch that throws that caused by: >> >> >> try { >> return FontManagerHolder.instance; >> } catch (java.la

Re: RFR: 8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

2021-09-20 Thread Alexander Zvegintsev
On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov wrote: > This calls are redundant, because order of `p0` and `p1` is checked in method > pre-conditions. > Checks were added under > [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - > https://github.com/openjdk/jdk/commit/79ed

Integrated: 8273907: Cleanup redundant Math.max/min calls in DefaultHighlighter

2021-09-20 Thread Andrey Turbanov
On Thu, 16 Sep 2021 08:08:07 GMT, Andrey Turbanov wrote: > This calls are redundant, because order of `p0` and `p1` is checked in method > pre-conditions. > Checks were added under > [JDK-6771184](https://bugs.openjdk.java.net/browse/JDK-6771184) - > https://github.com/openjdk/jdk/commit/79ed

RFR: 8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop

2021-09-20 Thread Andrey Turbanov
There are few places in code where manual `for` loop is used with Iterator to iterate over Collection. Instead of manual `for` cycles it's preferred to use enhanced-for cycle instead: it's less verbose, makes code easier to read and it's less error-prone. It doesn't have any performance impact: j

Re: RFR: 8274016: Replace 'for' cycles with iterator with enhanced-for in java.desktop

2021-09-20 Thread Aleksey Shipilev
On Sun, 19 Sep 2021 10:13:49 GMT, Andrey Turbanov wrote: > There are few places in code where manual `for` loop is used with Iterator to > iterate over Collection. > Instead of manual `for` cycles it's preferred to use enhanced-for cycle > instead: it's less verbose, makes code easier to read

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Alexey Ivanov
On Mon, 20 Sep 2021 17:15:48 GMT, Brett Okken wrote: >> The difference is that Holder will fail that way forever, while the DLC have >> a chance to resurrect on next call. > > So I guess the question is whether there is a valid transitory failure use > case? > The difference is that Holder wi

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Alexey Ivanov
On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy wrote: >> FontManagerFactory class uses reflection to load platform specific >> FontManager classes from "sun.font.fontmanager" property. >> >> Fix proposes creating FontManager platform specific classes directly in the >> similar way as

RFR: 8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

2021-09-20 Thread Sergey Bylokhov
This testcase creates two threads for each tag, one thread continuously change the profiles, the second thread use that profiles for color conversion. The first thread executed no more than 15 seconds, and the second thread should be stopped when the first thread end. Unfortunately on the slow

Re: RFR: 8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

2021-09-20 Thread lawrence . andrews
On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov wrote: > This testcase creates two threads for each tag, one thread continuously > change the profiles, the second thread use that profiles for color > conversion. The first thread executed no more than 15 seconds, and the second > thread shoul

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v3]

2021-09-20 Thread Sergey Bylokhov
On Mon, 20 Sep 2021 17:47:18 GMT, Alexey Ivanov wrote: >> So I guess the question is whether there is a valid transitory failure use >> case? > >> The difference is that Holder will fail that way forever, while the DLC have >> a chance to resurrect on next call. > > Is it really possible that

Re: RFR: 8273581: Change the mechanism by which JDK loads the platform-specific FontManager class [v6]

2021-09-20 Thread Sergey Bylokhov
On Mon, 20 Sep 2021 11:26:13 GMT, Alexander Scherbatiy wrote: >> FontManagerFactory class uses reflection to load platform specific >> FontManager classes from "sun.font.fontmanager" property. >> >> Fix proposes creating FontManager platform specific classes directly in the >> similar way as

Re: RFR: 8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

2021-09-20 Thread Alexey Ivanov
On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov wrote: > This testcase creates two threads for each tag, one thread continuously > change the profiles, the second thread use that profiles for color > conversion. The first thread executed no more than 15 seconds, and the second > thread shoul

Integrated: 8273887: [macos] java/awt/color/ICC_ColorSpace/MTTransformReplacedProfile.java timed out

2021-09-20 Thread Sergey Bylokhov
On Mon, 20 Sep 2021 19:29:10 GMT, Sergey Bylokhov wrote: > This testcase creates two threads for each tag, one thread continuously > change the profiles, the second thread use that profiles for color > conversion. The first thread executed no more than 15 seconds, and the second > thread shoul

RFR: 8274029 : Remove jtreg tag manual=yesno for java/awt/print/Dialog/DialogOrient.java

2021-09-20 Thread lawrence . andrews
Problem : Testcase was failing with parser exception test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno Fix : Removed =yesno and run the testcase and Test UI ( instruction and print dialog ) is visible @shurymury - Commit messages: - 8274029 :

Re: RFR: 8271071 accessibility of a table on macOS lacks cell navigation [v3]

2021-09-20 Thread Alexander Zuev
On Tue, 14 Sep 2021 15:50:34 GMT, Artem Semenov wrote: >> We've extended the current implementation of TableAccessibility to make sure >> that individual cells are voiced when navigating with the keyboard. > > Artem Semenov has updated the pull request incrementally with one additional > commi

RFR: 8274032 : Remove jtreg tag manual=yesno for java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java & show test UI

2021-09-20 Thread lawrence . andrews
Problem : 1) Testcase was failing due to parse exception yesno 2) After removing yesno tag test frame and immediately get disposed Fix : 1) Removed yesno tag 2) Show the test frame with pass, fail button. Now user can click on the `print' button to show the print dialog and take the print out