JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 34 commits:
JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 33 commits:
JEP 421. It also updates the relevant @SuppressWarning annotations.
>
> The CSR has been approved.
> An automated test build+test run passes cleanly (FWIW :D ).
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 32 commits:
On Fri, 19 Nov 2021 18:06:39 GMT, Mandy Chung 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 spe
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 spec for JEP
421. It also updates the relevant @SuppressWarning annotatio
On Mon, 14 Dec 2020 19:36:48 GMT, Brent Christian wrote:
> This is part of an effort in the JDK to replace archaic/non-inclusive words
> with more neutral terms (see JDK-8253315 for details).
>
> Here are the changes covering core libraries code and tests. Terms were
> cha
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Wed, 16 Dec 2020 07:10:41 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> improve SERIAL_FILTER_PATTERN comment
>
> src/java.base/share/classes/java/util/Loc
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Tue, 15 Dec 2020 22:13:58 GMT, Stuart Marks wrote:
>> It's an adverb, since it's the act of 'defining' that is being done too
>> restrictively or broadly. If you want to have an adjective you would need to
>> rephrase it so it applies to the noun, like 'defining a too restrictive
>> accept-
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Tue, 15 Dec 2020 22:02:00 GMT, Lance Andersen wrote:
>> test/jdk/java/lang/ClassLoader/Assert.java line 65:
>>
>>> 63:
>>> 64: int switchSource = 0;
>>> 65: if (args.length == 0) { // This is the coordinator version
>>
>> Perhaps s/coordinator/controller/?
>
> Let's change i
On Tue, 15 Dec 2020 07:32:12 GMT, Alan Bateman wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> updates, per code review
>
> test/jdk/java/nio/channels/SocketChannel/CloseRegistered
. blacklist -> filter or reject
> 3. whitelist -> allow or accept
> 4. master -> coordinator
> 5. slave -> worker
>
> Addressing similar issues in upstream 3rd party code is out of scope of this
> PR. Such changes will be picked up from their upstream sources.
Brent Chr
On Mon, 14 Dec 2020 21:08:35 GMT, Joe Wang wrote:
>> This is part of an effort in the JDK to replace archaic/non-inclusive words
>> with more neutral terms (see JDK-8253315 for details).
>>
>> Here are the changes covering core libraries code and tests. Terms were
>> changed as follows:
>> 1.
This is part of an effort in the JDK to replace archaic/non-inclusive words
with more neutral terms (see JDK-8253315 for details).
Here are the changes covering core libraries code and tests. Terms were
changed as follows:
1. grandfathered -> legacy
2. blacklist -> filter or reject
3. whitelist
Hi, Egor
On 6/20/19 8:49 AM, Alan Bateman wrote:
On 20/06/2019 15:49, Egor Ushakov wrote:
any news on https://bugs.openjdk.java.net/browse/JDK-8212117?
I do not see any activity on this :(
>
cc'ing Brent as he has picked up this issue. I think we want to fix this
and David has a patch in one
Any thoughts on this change? -B
On 9/11/18 3:41 PM, Brent Christian wrote:
Hi,
Please review this change to how the platform encoding is determined on
Mac when loading agents.
Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
Additional details in the bug report
Looks like you got them all - reviewed.
-Brent
On 09/14/2018 04:09 PM, Igor Ignatyev wrote:
http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html
36 lines changed: 0 ins; 0 del; 36 mod;
Hi all,
could you please review this small and trivial follow-up fix for 8182404 and
821073
Hi,
Please review this change to how the platform encoding is determined on
Mac when loading agents.
Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/
Additional details in the bug report:
https://bugs.openjdk.java.net/browse/JDK-8072130
Some background:
Since JDK 8, i
Please review my change for:
8064288 - sun.management.Flag should loadLibrary()
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8064288
Webrev:
http://cr.openjdk.java.net/~bchristi/8064288/webrev.0/
Thanks,
-Brent
Please review my change for:
8044473 - Allow for extended set of platform MXBeans
which adds an internal ExtendedPlatformComponent mechanism.
There are no new public APIs or MXBeans.
JBS Issue:
https://bugs.openjdk.java.net/browse/JDK-8044473
Webrev:
http://cr.openjdk.java.net/~bchristi/804
On 2/28/14 9:27 AM, Stuart Marks wrote:
I guess there is some risk of adding new intermittent failures, but
tackling @ignore'd tests is important too.
Right - the main risk is that we will see this test fail again at some
point in the future. I'll be keeping an eye out for that.
Thanks for
File under "chipping away at test stabilization issues."
https://bugs.openjdk.java.net/browse/JDK-6835233
I've done some repeated runs of this test on my Linux machine. The test
fails every time with 6u3. It fails intermittently on 7 (after 145
iterations for 7u45, and 62 iterations for 7u60
24 matches
Mail list logo
