Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v4]
> 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 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:
- Merge branch 'master' into 8276447
- Merge branch 'master' into 8276447
- Merge branch 'master' into 8276447
- merge
- @SuppressWarnings(removal) in Windows CKey.java
- Add jls tag to runFinalization methods
- Update wording of Object.finalize, new paragraph is now bold
- update Object.finalize javadoc
- update Object.finalize JavaDoc and @deprecated tag
- Update Object.finalize deprecation message
- ... and 24 more: https://git.openjdk.java.net/jdk/compare/ea8d3c92...0a983d51
-
Changes: https://git.openjdk.java.net/jdk/pull/6465/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=03
Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465
PR: https://git.openjdk.java.net/jdk/pull/6465
Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v3]
> 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 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:
- Merge branch 'master' into 8276447
- Merge branch 'master' into 8276447
- merge
- @SuppressWarnings(removal) in Windows CKey.java
- Add jls tag to runFinalization methods
- Update wording of Object.finalize, new paragraph is now bold
- update Object.finalize javadoc
- update Object.finalize JavaDoc and @deprecated tag
- Update Object.finalize deprecation message
- Indicate that runFinalizers does nothing if finalization is disabled or
removed
- ... and 23 more: https://git.openjdk.java.net/jdk/compare/0dfb3a70...8cde0674
-
Changes: https://git.openjdk.java.net/jdk/pull/6465/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=02
Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465
PR: https://git.openjdk.java.net/jdk/pull/6465
Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal [v2]
> 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 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:
- Merge branch 'master' into 8276447
- merge
- @SuppressWarnings(removal) in Windows CKey.java
- Add jls tag to runFinalization methods
- Update wording of Object.finalize, new paragraph is now bold
- update Object.finalize javadoc
- update Object.finalize JavaDoc and @deprecated tag
- Update Object.finalize deprecation message
- Indicate that runFinalizers does nothing if finalization is disabled or
removed
- Fix @since on @Deprecated for java.lang.Enum
- ... and 22 more: https://git.openjdk.java.net/jdk/compare/a363b7b9...e4986a48
-
Changes: https://git.openjdk.java.net/jdk/pull/6465/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=01
Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465
PR: https://git.openjdk.java.net/jdk/pull/6465
Re: RFR: JDK-8276447 Deprecate finalization-related methods for removal
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 spec for
>> JEP 421. It also updates the relevant @SuppressWarning annotations.
>>
>> The CSR has been approved.
>> An automated test build+test run passes cleanly (FWIW :D ).
>
> src/java.base/share/classes/java/lang/Object.java line 481:
>
>> 479: * system resources or to perform other cleanup.
>> 480: *
>> 481: * When running in a Java virtual machine in which finalization
>> has been
>
> Disabling finalization is not part of the Java SE spec. This paragraph
> describes the implementation of HotSpot VM and I think it does not belong to
> this javadoc.
The coupling between this change and
[8276422](https://bugs.openjdk.java.net/browse/JDK-8276422) ("Add command-line
option to disable finalization") is probably tighter than would be ideal. That
[CSR](https://bugs.openjdk.java.net/browse/JDK-8276773) allows for finalization
to be disabled in the SE Platform Spec and the JLS.
-
PR: https://git.openjdk.java.net/jdk/pull/6465
RFR: JDK-8276447 Deprecate finalization-related methods for removal
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 annotations.
The CSR has been approved.
An automated test build+test run passes cleanly (FWIW :D ).
-
Commit messages:
- merge
- @SuppressWarnings(removal) in Windows CKey.java
- Add jls tag to runFinalization methods
- Update wording of Object.finalize, new paragraph is now bold
- update Object.finalize javadoc
- update Object.finalize JavaDoc and @deprecated tag
- Update Object.finalize deprecation message
- Indicate that runFinalizers does nothing if finalization is disabled or
removed
- Fix @since on @Deprecated for java.lang.Enum
- Clarify conditions for removal of Object.finalize method
- ... and 21 more: https://git.openjdk.java.net/jdk/compare/89b125f4...eca95cb2
Changes: https://git.openjdk.java.net/jdk/pull/6465/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6465&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8276447
Stats: 194 lines in 62 files changed: 54 ins; 38 del; 102 mod
Patch: https://git.openjdk.java.net/jdk/pull/6465.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/6465/head:pull/6465
PR: https://git.openjdk.java.net/jdk/pull/6465
Integrated: 8253497: Core Libs Terminology Refresh
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 > changed as follows: > 1. grandfathered -> legacy > 2. 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. This pull request has now been integrated. Changeset: b2f03554 Author:Brent Christian URL: https://git.openjdk.java.net/jdk/commit/b2f03554 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod 8253497: Core Libs Terminology Refresh Reviewed-by: naoto, kcr, rriggs, joehw, bpb, smarks, alanb - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v5]
> 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 -> 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 Christian has updated the pull request incrementally with one additional commit since the last revision: Use quotes instead of @code in Locale - Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/ba586413..03264330 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v4]
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/Locale.java line 1649:
>
>> 1647: * This implements the 'Language-Tag' production of BCP47, and
>> 1648: * so supports legacy (regular and irregular, referred to as
>> 1649: * {@code Type: grandfathered} in BCP47) as well as
>
> You might consider putting quotes around "Type; grandfathered" here,
> otherwise looks good.
Yes, having that in quotes instead of in {@code} would be consistent with the
rest of Locale.java. I will change that.
-
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v4]
> 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 -> 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 Christian has updated the pull request incrementally with one additional commit since the last revision: improve SERIAL_FILTER_PATTERN comment - Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/b8cd8b6d..ba586413 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v3]
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-list'. My non-native English vibes would still prefer the former. > > I'd suggest `... as defining an allow-list that is too narrow or a > reject-list that is too wide may prevent ...`. > > (edited to remove hyphen from "too-wide") Even better! - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v3]
> 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 -> 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 Christian has updated the pull request incrementally with three additional commits since the last revision: - This is the controller - use 'controller' in Assert.java - use 'peer' in CloseRegisteredChannel.java - Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/29525f05..b8cd8b6d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01-02 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
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 it to:
>
> // This is the controller
Will do.
-
PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
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/CloseRegisteredChannel.java line 45: > >> 43: SocketChannel client = SocketChannel.open (); >> 44: client.connect (new InetSocketAddress >> (InetAddress.getLoopbackAddress(), port)); >> 45: SocketChannel channel = server.accept (); > > Can you rename this to "peer" instead? (we can remove the spurious space > after accept while we are there). Yes, I will name it, "peer", and remove the extra space on the affected lines. - PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh [v2]
> 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 -> 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 Christian has updated the pull request incrementally with one additional commit since the last revision: updates, per code review - Changes: - all: https://git.openjdk.java.net/jdk/pull/1771/files - new: https://git.openjdk.java.net/jdk/pull/1771/files/4efa5d43..29525f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8253497: Core Libs Terminology Refresh
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. grandfathered -> legacy >> 2. 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. > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectorServer.java > line 152: > >> 150: * >> 151: * Care must be taken when defining such a filter, as defining >> 152: * an accept-list too restrictive or a too-wide reject-list may > > would "an allow-list too restrictive or a reject-list too wide" read better? I agree that there is room for improvement here. How about: "...an allow-list too restrictively, or a reject-list too broadly, may..." ? - PR: https://git.openjdk.java.net/jdk/pull/1771
RFR: 8253497: Core Libs Terminology Refresh
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 -> 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. - Commit messages: - Terminology Cleanup - corelibs terminology refresh - bchristi Changes: https://git.openjdk.java.net/jdk/pull/1771/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1771&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253497 Stats: 82 lines in 15 files changed: 1 ins; 0 del; 81 mod Patch: https://git.openjdk.java.net/jdk/pull/1771.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1771/head:pull/1771 PR: https://git.openjdk.java.net/jdk/pull/1771
Re: RFR: 8221503: vmTestbase/nsk/jdb/eval/eval001/eval001.java failes with: com.sun.jdi.InvalidTypeException: Can't assign double[][][] to double[][][]
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 of the linked issues. As it's changing long standing behavior in a sublte way then it will likely need a compatibility knob, the details of which need to be worked out before the CSR can be submitted. Myself (and others) have been looking into this as time has allowed. Some additional inconsistencies have been uncovered that should also be investigated. However, I think in the near term, we can proceed with a more focused fix to address 8212117 in particular. -Brent
Re: RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
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: https://bugs.openjdk.java.net/browse/JDK-8072130 Some background: Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1]. (This allowed apps launched via double-clicked jar to display files correctly for non-ASCII languages). A similar encoding tweak was not made in the code path used for loading agents. This can come into play when an agent jar includes a Boot-Class-Path entry containing non-ASCII characters. iconv() gets setup to convert UTF-8 to US-ASCII[2], but will fail when encountering extended characters in the entry, so the path in question is not added to the bootclasspath[3]. This will likely lead to a ClassNotFoundException. When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default encoding of UTF-8 (per 8011194) and creates Agent.jar with a Boot-Class-Path that includes non-ASCII characters. But the Boot-Class-Path entry gets skipped when loading Agent.jar, so the AgentSupport class can't be found. I propose this be fixed by adding the same UTF-8 encoding adjustment on MacOS from 8011194 to the agent loading code path. An additional note: This bug was challenging to reproduce, in large part because the 8011194 code checks for an absent env var (getenv() == null), but not for env vars with a blank/empty string value (getenv() == ""), so the test environment had to be setup in a specific way (e.g. 'unset LANG' vs 'export LANG=') to reproduce this bug. So I'd like to update the code to also check for empty string. I also added a couple small improvements to the test. Thanks! -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8011194 2. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 3. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873
Re: RFR(XS) : 8210779 : 8182404 and 8210732 haven't updated copyright years
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 8210732? I have forgot to update copyright years as a part of these two changesets, this patch fixes that. webrev: http://cr.openjdk.java.net/~iignatyev//8210779/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210779 Thanks, -- Igor
RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
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, if MacOS reports an encoding of US-ASCII, but no encoding hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1]. (This allowed apps launched via double-clicked jar to display files correctly for non-ASCII languages). A similar encoding tweak was not made in the code path used for loading agents. This can come into play when an agent jar includes a Boot-Class-Path entry containing non-ASCII characters. iconv() gets setup to convert UTF-8 to US-ASCII[2], but will fail when encountering extended characters in the entry, so the path in question is not added to the bootclasspath[3]. This will likely lead to a ClassNotFoundException. When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default encoding of UTF-8 (per 8011194) and creates Agent.jar with a Boot-Class-Path that includes non-ASCII characters. But the Boot-Class-Path entry gets skipped when loading Agent.jar, so the AgentSupport class can't be found. I propose this be fixed by adding the same UTF-8 encoding adjustment on MacOS from 8011194 to the agent loading code path. An additional note: This bug was challenging to reproduce, in large part because the 8011194 code checks for an absent env var (getenv() == null), but not for env vars with a blank/empty string value (getenv() == ""), so the test environment had to be setup in a specific way (e.g. 'unset LANG' vs 'export LANG=') to reproduce this bug. So I'd like to update the code to also check for empty string. I also added a couple small improvements to the test. Thanks! -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8011194 2. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/unix/native/libinstrument/EncodingSupport_md.c#l87 3. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/share/native/libinstrument/InvocationAdapter.c#l873
RFR (8u40) 8064288 : sun.management.Flag should loadLibrary()
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
RFR (8u40) 8044473 : Allow for extended set of platform MXBeans
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/8044473/webrev.00/ Thanks, -Brent
Re: RFR 6835233 : Fedora 9 jdk regression test failed: java/lang/instrument/ParallelTransformerLoader.sh
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 the review, guys. -Brent
RFR 6835233 : Fedora 9 jdk regression test failed: java/lang/instrument/ParallelTransformerLoader.sh
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 7u60b07). I have not been able to reproduce the failure on 8 or 9, running 1000 iterations each on 8b115, 8b129, and 9b02. I would like to resolve this bug by removing the "@ignore" tag for JDK 9, and bring the test back into rotation. If the failure comes back, I'll submit a new issue for further investigation. The change is: # @bug 5088398 -# @ignore until bug 6835233 dealt with # @summary Test parallel class loading by parallel transformers. Thanks, -Brent
