On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typos
>
> This doesn't seem right to me to put x11wrappergen into share.
&
On Thu, 21 Apr 2022 08:35:36 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 fanfare,
Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
[macosx] surrogate pairs do not render properly (show up as boxes or
incorrect glyphs)
But that was fixed in 7u40. What JDK 7 update is in use here ?
-phil.
On 4/9/14 9:17 AM, Naoto Sato wrote:
Hi Mark,
On 4/9/14, 3:11 AM, Mark Da
glio è l’inimico del bene —/
//
On 9 April 2014 18:31, Phil Race <mailto:philip.r...@oracle.com>> wrote:
Sounds like https://bugs.openjdk.java.net/browse/JDK-8015556
[macosx] surrogate pairs do not render properly (show up as boxes
or incorrect glyphs)
But that was fixed in 7
Sorry .. I have been out on vacation .. and before that over-looked this
email anyway.
I do not have a workaround here.
I had supposed the emoji fonts provide the colour image as an
alternative that some
APIs understand and that any code asking directly for a normal glyph
image would get it
b
This took some getting my head around.
First I had to find the first set of changes that broke the static
dependency :-
This in JDK 7 :-
http://mail.openjdk.java.net/pipermail/i18n-dev/2009-November/000154.html
changeset: 1869:eb8b08775b82
user:alanb
date:Thu Nov 12 11:20:51
use its glyphs.
Fix:
Remove the following set of characters u2018 - u201F from the
exclusion ranges.
Thank you in advance,
Dmitry
On 10/02/2016 23:25, Phil Race wrote:
I expect the exclusion range is there for a reason.
I think (guess) that the intent was that where there is a sequence
like th
nd personally I am fine with the fix), but
should we consult with the globalization team?
Naoto
On 3/17/16 12:54 PM, Phil Race wrote:
I think you are still waiting on i18n to reply here since the exclusion
ranges
are mainly used for ensuring that the glyphs come from the right font
which
is ma
Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
Webrev : http://cr.openjdk.java.net/~prr/8039273/
A CCC request and documentation are being prepared.
-phil
is non null. Otherwise it looks good to me.
Naoto
On 12/8/16 12:01 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
Webrev : http://cr.openjdk.java.net/~prr/8039273/
A CCC request and documentation are being prepared.
-phil
, as
fontConfigFile is guaranteed to be non-null if userConfigFile is non null.
Otherwise it looks good to me.
Naoto
On 12/8/16 12:01 PM, Phil Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8039273
Webrev : http://cr.openjdk.java.net/~prr/8039273/
A CCC request and documentation are
It is in a platform dependent directory .. and I gather this allows the
build to pick up the right one
without any work here.
-phil
On 5/30/2018 2:08 PM, Naoto Sato wrote:
Hi,
I see that the change introduced the base abstraction class,
X11InputMethodBase. Back in the days I worked on it, X1
I can only guess why this range was excluded.
My guess is that it was something to do with an attempt at
allowing as many of these glyphs as possible to come from
(for example) a Chinese font in a chinese locale even though we
always put the latin font first ..
The interesting reason why adding a
ase use that in the commit - when you get to it.
-phil.
On 06/12/2018 01:46 PM, Phil Race wrote:
I can only guess why this range was excluded.
My guess is that it was something to do with an attempt at
allowing as many of these glyphs as possible to come from
(for example) a Chinese font in a chin
This should go to i18n-dev as well.
-phil.
On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote:
Hello,
IBM would like to contribute Windows IME related Java Input Method
Framework patch to OpenJDK project.
Issue:
This patch can fix following issues.
A: Cannot display surrogate pair character on
be displayed or not using function "canDisplayUpTo()").
Please find the updated webrev at
http://cr.openjdk.java.net/~dkumar/8202696/webrev.01/ .
Request you to have a look into this again and let me know your inputs.
Many thanks,
Dipak
-Original Message-
From: Phil Race
Se
Where's the bug ID ?
The review should have a bug ID in the subject line so we can all find
it later !
Is this changing the default visual for all WIndows, not just the IM
status window?
I think we need to understand the implications before this can be accepted.
Similarly for the fontset c
expected values for logical fonts.
Thanks for your guidance.
Please find the updated webrev at
http://cr.openjdk.java.net/~dkumar/8202696/webrev.02/ .
Request you to review it again and let me know your comments.
Thanks,
Dipak
-Original Message-
From: Phil Race
Sent: 16 June 2018 0
On 06/27/2018 06:45 AM, Ichiroh Takiguchi wrote:
Hello,
I should post this mail before starting JDK11 RDP1.
Already too too late for that, but although this looks like a bug - and
the correct fix -
the bug has been there forever .. since JDK 1.2 in 1998 !
That makes it a 20 year old bug,
ick on focus"
feature.
But input focus is moved to "Non-Focusable" window.
On 2018-05-18 01:00, Phil Race wrote:
I think we'd need to see the actual proposed changes and understand
the implications
for ongoing support as we no longer support any platform which has a
CDE desk
Any takers ? Jay ? Also adding i18n-dev.
-phil.
On 4/20/19 4:29 PM, Philip Race wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8208179
Webrev: http://cr.openjdk.java.net/~prr/8208179/index.html
The original complaint is missing devanagari in logical fonts in
Oracle JDK 11.
I realised
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
1) This is un-necessary churn.
2) I can't
https://bugs.openjdk.java.net/browse/JDK-8252195
is another one of the issues adding missing explicit no-args constructors in
the desktop module.
As well as being nested, these are all concrete, but protected, classes and so
the constructors
are protected.
CSR here https://bugs.openjdk.java.net
On Mon, 21 Sep 2020 20:17:36 GMT, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8252195
> is another one of the issues adding missing explicit no-args constructors in
> the desktop module.
>
> As well as being nested, these are all concrete, but protected, classe
.
>
> CSR here https://bugs.openjdk.java.net/browse/JDK-8253450 needs a reviewer
> too.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8252195: AWT Accessibility API nested classes rely on default constructors
On Mon, 21 Sep 2020 20:17:36 GMT, Phil Race wrote:
> https://bugs.openjdk.java.net/browse/JDK-8252195
> is another one of the issues adding missing explicit no-args constructors in
> the desktop module.
>
> As well as being nested, these are all concrete, but protected, classe
On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote:
> Looks like different people use a different style for the new constructors,
> it will be good to unify them.
> I have started from https://bugs.openjdk.java.net/browse/JDK-8252721
> See
> https://bugs.openjdk.java.net/browse/JDK-8252908?
On Wed, 23 Sep 2020 07:03:59 GMT, Sergey Bylokhov wrote:
> Looks like different people use a different style for the new constructors,
> it will be good to unify them.
>
> The text "Constructor for subclasses to call." should be used in the
> protected constructors in the abstract classes
> In
On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote:
> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
>
> The fix:
> - Adds missing comments to the non-static/non-transient fields(even
> priva
On Fri, 25 Sep 2020 21:45:39 GMT, Sergey Bylokhov wrote:
> We have a number of missing javadoc tags and comments in the desktop module.
> Most of the missing comments are related to the serialized form.
>
> The fix:
> - Adds missing comments to the non-static/non-transient fields(even
> priva
On Fri, 2 Oct 2020 18:35:25 GMT, Phil Race wrote:
>> We have a number of missing javadoc tags and comments in the desktop module.
>> Most of the missing comments are related to the serialized form.
>>
>> The fix:
>> - Adds missing comments to the non-st
On Sat, 3 Oct 2020 00:31:48 GMT, Sergey Bylokhov wrote:
>> We have a number of missing javadoc tags and comments in the desktop module.
>> Most of the missing comments are related to the serialized form.
>>
>> The fix:
>> - Adds missing comments to the non-static/non-transient fields(even
>>
On Tue, 15 Dec 2020 22:56:15 GMT, Magnus Ihse Bursie wrote:
>> A lot (but not all) of the data in make/data is tied to a specific module.
>> For instance, the publicsuffixlist is used by java.base, and fontconfig by
>> java.desktop. (A few directories, like mainmanifest, is *actually* used by
On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick wrote:
>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a
> merge or a rebase. The incremental webrev excludes the unrelated changes
> bro
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Wed, 19 May 2021 18:38:39 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 217:
>>
>>> 215: * @author Sami Shaio
>>> 216: */
>>> 217: @SuppressWarnings("removal")
>>
>> Why is this placed on the *entire class* ??
>> This class is 10535 lines long
On Wed, 19 May 2021 21:53:35 GMT, Weijun Wang wrote:
>> That's a sad limitation of the annotation stuff then, but I don't think that
>> it is insurmountable.
>> You can define a static private method to contain this and call it from the
>> static initializer block.
>> Much better than applying
On Wed, 19 May 2021 22:14:20 GMT, Weijun Wang wrote:
>> I don't think it is a separate P4 enhancement (?) that someone will (maybe)
>> do next release.
>> I think it should all be taken care of as part of this proposed change.
>
> I just made it P3 (P4 was the default value), and I will target i
On Thu, 20 May 2021 02:09:57 GMT, Weijun Wang wrote:
>> I can make it a bug.
>>
>> I don't want to do it here is because it involves indefinite amount of
>> manual work and we will see everyone having their preferences. The more time
>> we spend on this PR the more likely there will be merge c
On Thu, 20 May 2021 04:05:23 GMT, Phil Race wrote:
>> By converting JDK-8267432 to a bug, there is an extra benefit that we can
>> fix it after RDP. So I'll convert it now.
>
> That is unfortunate, but nonetheless I think required to be done.
> We have acknowledege
On Thu, 20 May 2021 07:06:00 GMT, Alan Bateman wrote:
>> The JEP isn't PTT for 17 so there's plenty of time isn't there ?
>
> There are 827 files in this patch. Phil is right that adding SW at the class
> level is introducing technical debt but if addressing that requires
> refactoring and re-t
On Tue, 18 May 2021 21:44:43 GMT, Weijun Wang wrote:
>> Please review the test changes for [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> With JEP 411 and the default value of `-Djava.security.manager` becoming
>> `disallow`, tests calling `System.setSecurityManager()` need
>> `-Djav
On Wed, 19 May 2021 13:47:53 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Mon, 24 May 2021 13:53:34 GMT, Weijun Wang wrote:
>> Please review this implementation of [JEP
>> 411](https://openjdk.java.net/jeps/411).
>>
>> The code change is divided into 3 commits. Please review them one by one.
>>
>> 1.
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e38
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>> with
On Fri, 28 May 2021 02:50:55 GMT, Weijun Wang wrote:
>> src/java.desktop/share/classes/java/awt/Component.java line 630:
>>
>>> 628: }
>>> 629:
>>> 630: @SuppressWarnings("removal")
>>
>> I'm confused. I thought the reason this wasn't done in the JEP
>> implementation PR is be
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>> with
On Tue, 6 Jul 2021 11:32:18 GMT, Сергей Цыпанов
wrote:
>> It's not a public API. As I see from other PR/commits changing
>> package-private methods shouldn't be a problem.
>
> Even non-public method can be called via reflection, so I'd be cautios about
> changing return type
Apps should not b
On Sun, 4 Jul 2021 20:42:41 GMT, Andrey Turbanov
wrote:
> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
> use `ArrayList` if a thread-safe implementation is not needed. In
> post-BiasedLocking times, this is gets worse, as every access is synchronized.
> I checke
On Tue, 24 Aug 2021 21:13:57 GMT, Andrey Turbanov
wrote:
>> Usage of thread-safe collection `Vector` is unnecessary. It's recommended to
>> use `ArrayList` if a thread-safe implementation is not needed. In
>> post-BiasedLocking times, this is gets worse, as every access is
>> synchronized.
>>
The code this test exercises is very obsolete. So this removes the test that
triggers it along with that code.
-
Commit messages:
- 8198336: java/awt/FontMetrics/FontCrash.java
Changes: https://git.openjdk.java.net/jdk/pull/6027/files
Webrev: https://webrevs.openjdk.java.net/?repo
On Wed, 20 Oct 2021 06:58:41 GMT, Sergey Bylokhov wrote:
>> Phil Race has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8198336: java/awt/FontMetrics/FontCrash.java fails in headless mode
>
> src/java.d
> The code this test exercises is very obsolete. So this removes the test that
> triggers it along with that code.
Phil Race has updated the pull request incrementally with one additional commit
since the last revision:
8198336: java/awt/FontMetrics/FontCrash.java fails in headles
On Wed, 20 Oct 2021 04:12:46 GMT, Phil Race wrote:
> The code this test exercises is very obsolete. So this removes the test that
> triggers it along with that code.
This pull request has now been integrated.
Changeset: 6523c558
Author: Phil Race
URL:
https://git.openjdk.ja
On Tue, 2 Nov 2021 16:30:56 GMT, Pavel Rappo wrote:
> This PR follows up one of the recent PRs, where I used a non-canonical
> modifier order. Since the problem was noticed [^1], why not to address it at
> mass?
>
> As far as I remember, the first mass-canonicalization of modifiers took place
On Fri, 3 Dec 2021 01:18:20 GMT, Joe Darcy wrote:
> In JDK 18, JDK-8189591 added the ability to suppress doclint warnings.
> Therefore, it is now possible to enable the full doclint checks for the
> java.desktop module if the instances of warnings are suppressed. This patch
> does this; it wou
On Mon, 29 Nov 2021 08:18:47 GMT, Сергей Цыпанов wrote:
>> Instead of something like
>>
>> long x;
>> long y;
>> return (x < y) ? -1 : ((x == y) ? 0 : 1);
>>
>> we can use `return Long.compare(x, y);`
>>
>> All replacements are done with IDE.
>
> Сергей Цыпанов has updated the pull request inc
On Wed, 1 Dec 2021 19:23:59 GMT, Brent Christian wrote:
>> Here are the code changes for the "Deprecate finalizers in the standard Java
>> API" portion of JEP 421 ("Deprecate Finalization for Removal") for code
>> review.
>>
>> This change makes the indicated deprecations, and updates the API
On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote:
> Hi
>
> I have reviewed the code for removing double semicolons at the end of lines
>
> all the best
> matteo
Marked as reviewed by prr (Reviewer).
Looks like there's only one client source code file touched
Most of the client changes a
64 matches
Mail list logo
