Integrated: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

On Fri, 23 Sep 2022 01:11:14 GMT, SWinxy wrote: > I also took the opportunity to link to `realSync(long)`. > > /** > * Parameterless version of realsync which uses default timout (see > DEFAUL_WAIT_TIME). > */ > > > /** > * Parameterless version of {@li

Re: RFR: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor

On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy wrote: > Appends: `, copying the array contents of {@code xpoints} and {@code > ypoints}` to specify that the arrays in the constructor are explicitly copied. The projects page on openjdk.org says that two integrated PRs are required, but I onl

Re: RFR: 4668290: unclear spec for Polygon.bounds field [v2]

make the field private in > the future. SWinxy has updated the pull request incrementally with one additional commit since the last revision: Reword change based off of Phil's suggestion Thanks, Phil. - Changes: - all: https://git.openjdk.org/jdk/pull/10417/files - n

Re: RFR: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor

On Fri, 30 Sep 2022 21:00:30 GMT, Phil Race wrote: > So OK, let's add the new text but the reason we need it is because of > questionable design. Mhmm. OK. Unfortunately I do not have a JBS account so I'm unable to add the issue to the CSR board. - PR:

Re: RFR: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor

On Mon, 26 Sep 2022 02:49:36 GMT, SWinxy wrote: > Appends: `, copying the array contents of {@code xpoints} and {@code > ypoints}` to specify that the arrays in the constructor are explicitly copied. Alright then. Just an old issue that wasn't really an issue. - PR:

Re: RFR: JDK-8292276 : Missing color names in CSS [v6]

On Mon, 22 Aug 2022 00:57:28 GMT, SWinxy wrote: >> ScientificWare has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Removes whitespace. >> >> Remove a whitespace at the end of the file > >

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Thu, 22 Sep 2022 20:19:12 GMT, Alexey Ivanov wrote: >> I unfortunately don't have a JBS (yet..), so if you could, that would be >> amazing. > > I think the text is correct here: …that _**a** Theme_ can support > > `MetalTheme` is a superclass for classes which implement Themes. Thus the >

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.desktop` directory, and accepted those >> changes where it indeed discovered real typos. >> >> I ignored typos in public methods and variables. Maybe they can be fixed >> later on without much

RFR: 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor

Appends: `, copying the array contents of {@code xpoints} and {@code ypoints}` to specify that the arrays in the constructor are explicitly copied. - Commit messages: - 4756278: RFE: Insufficient API documentation for java.awt.Polygon constructor Changes:

RFR: 4668290: unclear spec for Polygon.bounds field

New documentation replaces the `This value can be null.`: When created, {@link #invalidate() invalidated}, or {@link #reset() reset}, this becomes {@code null}. To get out of the null state, {@link #getBounds()} called with {@link #npoints} being greater than {@code 0} will transfer into a

Re: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m [v3]

. > > return renderType; > > > > // ... > > return fill ? SD_Fill : SD_Stroke; SWinxy has updated the pull request incrementally with one additional commit since the last revision: Update copyright year - Changes: - all: https://git.openjdk.org/jdk/pull/

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni I'm not a committer (yet) so I can't [sponsor](https://openjdk.org/sponsor/) this PR, even though I would. - PR:

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

On Thu, 25 Aug 2022 15:35:53 GMT, Michael Ernst wrote: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Oh no what happened 

Re: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni

On Mon, 5 Sep 2022 14:54:50 GMT, Michael Ernst wrote: > Can you be specific about the exact problems that you noticed that prevented > you from saying "these changes are fine"? These changes are fine. I don't see an instance where the duplicated words would mean a change in the specification.

RFR: 8294255: Add link to DEFAULT_WAIT_TIME in javadoc for SunToolKit.realsSync

I also took the opportunity to link to `realSync(long)`. /** * Parameterless version of realsync which uses default timout (see DEFAUL_WAIT_TIME). */ /** * Parameterless version of {@link #realSync(long)} which uses * the default timeout of {@link #DEFAULT_WAIT_TIME}. */

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Thu, 22 Sep 2022 16:54:39 GMT, Alexey Ivanov wrote: >> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java line >> 68: >> >>> 66: public abstract class MetalTheme { >>> 67: >>> 68: // Constants identifying the various Fonts that a Theme can support >> >> I think this

Re: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m [v2]

On Thu, 8 Sep 2022 05:23:40 GMT, SWinxy wrote: >> The `SDRenderType` enum is often returned using a variable declared at the >> start of functions. These can be inlined in the `return` itself. Using a >> ternary operator condenses what may be 12 lines into one, in the most

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.desktop` directory, and accepted those >> changes where it indeed discovered real typos. >> >> I ignored typos in public methods and variables. Maybe they can be fixed >> later on without much

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.desktop` directory, and accepted those >> changes where it indeed discovered real typos. >> >> I ignored typos in public methods and variables. Maybe they can be fixed >> later on without much

Re: RFR: 8285306: Fix typos in java.desktop [v10]

On Wed, 21 Sep 2022 11:52:57 GMT, Magnus Ihse Bursie wrote: >> I ran `codespell` on the `src/java.desktop` directory, and accepted those >> changes where it indeed discovered real typos. >> >> I ignored typos in public methods and variables. Maybe they can be fixed >> later on without much

Re: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m [v2]

t; return renderType; > > > > // ... > > return fill ? SD_Fill : SD_Stroke; SWinxy has updated the pull request incrementally with one additional commit since the last revision: We can do this here, too - Changes: - all: https://git.openjdk.org/jdk/pull/

Re: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m

On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy wrote: > The `SDRenderType` enum is often returned using a variable declared at the > start of functions. These can be inlined in the `return` itself. Using a > ternary operator condenses what may be 12 lines into one, in the most extreme

Re: RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m

On Mon, 5 Sep 2022 23:41:40 GMT, SWinxy wrote: > The `SDRenderType` enum is often returned using a variable declared at the > start of functions. These can be inlined in the `return` itself. Using a > ternary operator condenses what may be 12 lines into one, in the most extreme

RFR: 8293478: [java.desktop/macOS] Condense SDRenderType usages in QuartzRenderer.m

The `SDRenderType` enum is often returned using a variable declared at the start of functions. These can be inlined in the `return` itself. Using a ternary operator condenses what may be 12 lines into one, in the most extreme cases. `doRectUsingCG` and `doPolyUsingCG` were both modified more

Inlining SDRenderType returns in QuartzRenderer.m

Hey y'all, I was looking at QuartzRenderer.m , and noticed that a bunch of functions could directly return an SDRenderType enum at the end, rather than returning a local variable set at the

Re: RFR: JDK-8292276 : Missing color names in CSS. [v10]

On Sat, 3 Sep 2022 03:26:05 GMT, ScientificWare wrote: >> I think Phil is talking about just `return`ing the result, which doesn't >> change behavior. `""` can still `return Color.BLACK;` with the others >> creating a new object, ditching the oddly-placed temporary

Re: RFR: JDK-8292276 : Missing color names in CSS. [v10]

On Fri, 2 Sep 2022 11:38:27 GMT, ScientificWare wrote: >> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1411: >> >>> 1409: Color color = colorNamed.get(strlc); >>> 1410: if (color != null) { >>> 1411: return new Color(color.getRGB(),

Re: RFR: JDK-8292276 : Missing color names in CSS. [v6]

On Tue, 16 Aug 2022 21:37:30 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Missing color names in >> CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Missing color names in >>

Re: RFR: JDK-8292276 : Missing color names in CSS. [v6]

On Tue, 16 Aug 2022 21:37:30 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Missing color names in >> CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Missing color names in >>

Re: RFR: JDK-8292276 : Missing color names in CSS. [v3]

On Mon, 15 Aug 2022 23:42:35 GMT, ScientificWare wrote: >> This is referenced in Java Bug Database as >> - [JDK-8292276 : Missing color names in >> CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276) >> >> This is tracked in JBS as >> - [JDK-8292276 : Missing color names in >>

Migrating show/hide code to setVisible

. The deprecated show(), hide(), and show(boolean) would call setVisible(boolean) with the corresponding value. They won't be deprecated for removal. >From what I can tell, a migration can be done pretty easily. The headache I imagine can result is with mixing inheritances/overrides. Thoughts? -SWinxy

Re: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v4]

On Mon, 18 Jul 2022 17:18:21 GMT, Phil Race wrote: >> SWinxy has updated the pull request incrementally with one additional commit >> since the last revision: >> >> Alter XColor documentation >> >> Let's see if this passes the checks > > 1) The

Integrated: 8286270: [java.desktop] Replace color search in XColors with a switch statement

On Sat, 15 Jan 2022 03:44:17 GMT, SWinxy wrote: > The current implementation creates ~750 new objects on load, and uses a > binary array search with a Comparable implementation. This implementation is > probably bad. Instead, we can use the enhanced switch feature to possibly &g

Re: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v4]

On Sat, 16 Jul 2022 16:31:31 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a >> binary array search with a Comparable implementation. This implementation is >> probably bad. Instead, we can use the enhanced switch feature to poss

Re: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v4]

plementation means that the > array doesn't have to be sorted alphanumerically necessarily, and it creates > the colors on demand. SWinxy has updated the pull request incrementally with one additional commit since the last revision: Alter XColor documentation Let's see if this

Re: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3]

On Fri, 20 May 2022 00:53:27 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a >> binary array search with a Comparable implementation. This implementation is >> probably bad. Instead, we can use the enhanced switch feature to poss

Re: RFR: 8286270: [java.desktop] Replace color search in XColors with a switch statement [v3]

On Fri, 20 May 2022 00:53:27 GMT, SWinxy wrote: >> The current implementation creates ~750 new objects on load, and uses a >> binary array search with a Comparable implementation. This implementation is >> probably bad. Instead, we can use the enhanced switch feature to poss

<    1   2