tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull r
On Tue, 7 Jun 2022 18:45:17 GMT, Roger Riggs wrote:
> The commented out printf/println's should be removed before committing.
Do you mean the pre-existing `println`s in LdapSearchEnumeration.java?
-
PR: https://git.openjdk.java.net/jdk/pull/8311
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit since the last revisi
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with two additional
commits since the last revision:
On Fri, 3 Jun 2022 18:05:52 GMT, Mandy Chung wrote:
> This reapplies JDK-8287384 and adjust the number of GCs for negative case,
> i.e. the condition is never met that is used to verify a reference is not
> GC'ed.
Marked as reviewed by bchristi (Reviewer).
-
PR:
On Wed, 1 Jun 2022 21:25:25 GMT, Roger Riggs wrote:
>> Brent Christian has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 14 commits:
>>
>> - Merge branch 'master' into remove-finalizers
>> - Thr
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with two additional
commits since the last revision:
On Fri, 27 May 2022 22:09:22 GMT, Brent Christian wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with a Cleaner.
>>
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult
>> res`, and `L
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with two additional
commits since the last revisi
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull r
On Fri, 27 May 2022 22:00:24 GMT, Brent Christian wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with a Cleaner.
>>
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult
>> res`, and `L
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit since the last revisio
On Thu, 26 May 2022 18:50:07 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this test update reviewed?
>
> The ForceGC could be enhanced by using smaller wait/sleep time, and shared
> cleaner.
>
> Thanks,
> Xuelei
Marked as reviewed by bchristi (Reviewer).
-
PR:
On Sat, 23 Apr 2022 00:09:48 GMT, Brent Christian wrote:
>> src/java.naming/share/classes/com/sun/jndi/ldap/AbstractLdapNamingEnumeration.java
>> line 73:
>>
>>> 71: public void run() {
>>> 72: if (enumClnt != null) {
>>> 73:
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit since the la
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit since the last r
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit since th
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request with a new target base due to a
merge or a rebase. The pull request
tests `LdapSearchEnumeration` (not `LdapNamingEnumeration`
> or `LdapBindingEnumeration`, though all are subclasses of
> `AbstractLdapNamingEnumeration`).
>
> Thanks.
Brent Christian has updated the pull request incrementally with one additional
commit si
On Wed, 20 Apr 2022 13:48:21 GMT, Daniel Fuchs wrote:
>> Please review this change to replace the finalizer in
>> `AbstractLdapNamingEnumeration` with a Cleaner.
>>
>> The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult
>> res`, and `LdapClient enumClnt`) are moved to a
Please review this change to replace the finalizer in
`AbstractLdapNamingEnumeration` with a Cleaner.
The pieces of state required for cleanup (`LdapCtx homeCtx`, `LdapResult res`,
and `LdapClient enumClnt`) are moved to a static inner class . From there, the
change is fairly mechanical.
On Tue, 22 Mar 2022 17:59:15 GMT, Brent Christian wrote:
> Please review this change to the java/util/prefs/AddNodeChangeListener.jar
> test.
>
> Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh
> Preferences on each test run, Mac
On Wed, 23 Mar 2022 17:29:04 GMT, Naoto Sato wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add test failure message to 'couldn't remove' RuntimeException
>
gt; continue to fail without removing the node, etc. This matches observations on
> some CI machines.
>
> This change ensures that:
> * the test node is not present before the test
> * the test runs to completion, including removing the test node
> * the test node is not le
Please review this change to the java/util/prefs/AddNodeChangeListener.jar test.
Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh
Preferences on each test run, MacOS does not seem to honor this, and still
stores prefs in Library/.
This test has long suffered
On Fri, 25 Feb 2022 11:08:49 GMT, Claes Redestad wrote:
>> Splitting out these micro changes from #7231
>>
>> - Clean up and simplify setup and code
>> - Add variants with different inputs with varying lengths and encoding
>> weights, but also relevant mixes of each so that we both cover
On Thu, 17 Feb 2022 15:11:11 GMT, Claes Redestad wrote:
> Splitting out these micro changes from #7231
>
> - Clean up and simplify setup and code
> - Add variants with different inputs with varying lengths and encoding
> weights, but also relevant mixes of each so that we both cover
On Wed, 16 Feb 2022 21:39:20 GMT, Tim Prinzing wrote:
>> JDK-8281000 ClassLoader::registerAsParallelCapable throws NPE if caller is
>> null
>
> Tim Prinzing has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains 10 commits:
>
> - Merge
On Fri, 11 Feb 2022 22:37:57 GMT, Mandy Chung wrote:
> Thanks for taking on these null caller issue.
>
> To give more context to this issue, the spec of
> `ClassLoader::isRegisteredAsParallelCapable` returns true if this class
> loader is registered as parallel capable, otherwise false. The
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:
On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review for this change which proposes to fix the issue
> reported in https://bugs.openjdk.java.net/browse/JDK-8003417?
>
> The issue notes that this is applicable for `WeakHashMap` which have `null`
> keys. However,
On Thu, 2 Dec 2021 02:36:47 GMT, Tim Prinzing wrote:
>> JDK-8276674 : Malformed Javadoc inline tags in JDK source
>
> Tim Prinzing has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contains two commits:
>
> - Merge branch 'master' into
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:
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:
On Fri, 19 Nov 2021 00:14:18 GMT, Stuart Marks wrote:
>> Pretty much what it says. The new option controls a static member in
>> InstanceKlass that's consulted to determine whether the finalization
>> machinery is activated for instances when a class is loaded. A new native
>> method is added
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
On Thu, 18 Nov 2021 21:15:11 GMT, Mandy Chung wrote:
> When the finalization is disabled, perhaps jcmd GC.finalizer_info should just
> be made as a nop in the VM.
Would it be interesting (perhaps in a follow-up) for GC.finalizer_info to
report that the given VM had finalization disabled?
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
On Mon, 8 Nov 2021 20:18:17 GMT, Roger Riggs wrote:
>> You have a point.
>>
>> BUT, at least it's a working example and not some pseudo code. We do want to
>> move to working example code long term, don't we?
>>
>> When I see , I'm just wondering what those <> type operators are
>> good for
On Mon, 8 Nov 2021 17:15:12 GMT, Mandy Chung wrote:
>> I don't believe so. `no reference to the instance being cleaned` is the
>> essential part (to me).
>
> This is what I suggested and makes it clear that *must hold no reference to
> the instance being cleaned*. Maybe you didn't notice it's
On Wed, 18 Aug 2021 18:35:53 GMT, Ian Graves wrote:
>> 8271302: Regex Test Refresh
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Couple of fixes
Marked as reviewed by bchristi (Reviewer).
-
PR:
On Wed, 11 Aug 2021 18:22:42 GMT, Ian Graves wrote:
> 8271302: Regex Test Refresh
Changes requested by bchristi (Reviewer).
In the JBS issue, it looks like the Description was put in the Environment. :)
test/jdk/java/util/regex/RegExTest.java line 291:
> 289:
> 290: int
On Tue, 27 Jul 2021 15:14:29 GMT, Markus Grönlund wrote:
>> Greetings,
>>
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
>> replace and mitigate Object.finalize() uses in the JDK libraries; please see
>> https://bugs.openjdk.java.net/browse/JDK-8253568 for more
On Thu, 8 Jul 2021 19:47:26 GMT, Markus Grönlund wrote:
> Greetings,
>
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to
> replace and mitigate Object.finalize() uses in the JDK libraries; please see
> https://bugs.openjdk.java.net/browse/JDK-8253568 for more
On Wed, 7 Jul 2021 14:55:18 GMT, Roger Riggs wrote:
>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory
>> property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger Riggs
On Fri, 25 Jun 2021 14:54:45 GMT, Roger Riggs wrote:
>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory
>> property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger
On Wed, 23 Jun 2021 19:12:06 GMT, Roger Riggs wrote:
>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory
>> property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger
On Mon, 21 Jun 2021 17:15:03 GMT, Roger Riggs wrote:
>> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory
>> property.
>> Fix description in the example of a filter allowing platform classes.
>> Suppress some warnings about use of SecurityManager in tests.
>
> Roger
On Wed, 16 Jun 2021 20:22:17 GMT, Roger Riggs wrote:
> Remove the unnecessary special case "OVERRIDE" in jdk.serialFilterFactory
> property.
> Fix description in the example of a filter allowing platform classes.
> Suppress some warnings about use of SecurityManager in tests.
OVERRIDE is also
On Tue, 8 Jun 2021 14:26:43 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Tue, 1 Jun 2021 17:43:42 GMT, Brian Burkhalter wrote:
>> Modify the specification of `java.io.File.equals` to clarify that equality
>> is based only on a comparison of abstract pathnames as opposed to the file
>> system objects that the `File`s represent.
>
> Brian Burkhalter has updated
On Wed, 26 May 2021 22:11:54 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Wed, 26 May 2021 16:48:53 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Tue, 25 May 2021 21:45:33 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Tue, 25 May 2021 15:46:37 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Mon, 24 May 2021 21:57:50 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Mon, 24 May 2021 17:24:22 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Fri, 21 May 2021 17:47:53 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
On Thu, 20 May 2021 16:10:11 GMT, Roger Riggs wrote:
>> JEP 415: Context-specific Deserialization Filters extends the
>> deserialization filtering mechanisms with more flexible and customizable
>> protections against malicious deserialization. See JEP 415:
>>
ong with the new regtest, I added a run mode to the basic finalizer test to
> enable jfr.
> Automated testing looks good so far.
>
> Thanks,
> -Brent
Brent Christian has updated the pull request incrementally with one additional
commit since the last revision:
Test flag should be vola
On Tue, 18 May 2021 21:40:57 GMT, Istvan Neuwirth
wrote:
>> Please review this enhancement to add a new JFR event, generated whenever a
>> finalizer is run.
>> (The makeup is similar to the Deserialization event,
>> [JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
>>
>> The
Please review this enhancement to add a new JFR event, generated whenever a
finalizer is run.
(The makeup is similar to the Deserialization event,
[JDK-8261160](https://bugs.openjdk.java.net/browse/JDK-8261160).)
The event's only datum (beyond those common to all jfr events) is the class of
On Wed, 31 Mar 2021 12:47:50 GMT, Aleksei Efimov wrote:
>> Current fix tries to tackle an issue with URL connection referencing
>> non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the
>> underlying Jar file is still cached even if an exception
On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution of the the no
>> longer
On Mon, 22 Mar 2021 07:19:28 GMT, Kim Barrett wrote:
>> Please review this change to java.util.Timer, replacing the use of
>> deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>>
>> In addition, Timer.cancel now cancels any later execution of the the no
>> longer
On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves wrote:
>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Updating Formatter copyright date
Marked as
On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves wrote:
> This fixes a zero-adding issue observed in the hex float conversion.
This all looks fine - just update the copyright year in Formatter.java, please.
In my personal opinion, this behavior change does not rise to the level of
needing a CSR,
On Sat, 6 Mar 2021 01:35:28 GMT, Craig Andrews
wrote:
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for the `getResource` and `findResource` methods,
>> neither should be throwing `IllegalArgumentException` -
On Fri, 5 Mar 2021 16:02:49 GMT, Craig Andrews
wrote:
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for the `getResource` and `findResource` methods,
>> neither should be throwing `IllegalArgumentException` -
On 3/4/21 1:16 PM, Craig Andrews wrote:
@bchristi-git has indicated that a [compatibility and
specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is
needed for this pull request.
@candrews please create a CSR request and add link to it in
On Wed, 3 Mar 2021 18:10:25 GMT, Brent Christian wrote:
>> This seems to be a long standing bug, maybe goes all the way back to JDK
>> 1.2. Are you planning to add a regression test?
>
> Hi, Craig
> The commented-out lines should be removed from the change.
>
> As A
On Wed, 3 Mar 2021 14:28:00 GMT, Alan Bateman wrote:
>> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal
>> review ID : 9069151)
>>
>> `java.net.URLClassLoader.getResource` can throw an undocumented
>> `IllegalArgumentException`.
>>
>> According to the javadoc for
On Tue, 2 Feb 2021 22:08:33 GMT, Mahendra Chhipa
wrote:
> JDK-8261003 : Bad Copyright header format after JDK-8183372
Marked as reviewed by bchristi (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/2365
On Tue, 2 Feb 2021 21:00:00 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Generate the source files in JTWork directory.
Looks good.
On Wed, 27 Jan 2021 23:03:55 GMT, Mahendra Chhipa
wrote:
>> test/jdk/java/lang/Class/getEnclosingClass/EnclosingClassTest.java line 126:
>>
>>> 124: Path pkg1Dir = Paths.get(SRC_DIR + "/pkg1");
>>> 125: FileUtils.deleteFileTreeWithRetry(pkg1Dir);
>>> 126: }
>>
>> I'm not
On Mon, 1 Feb 2021 23:43:25 GMT, Brent Christian wrote:
>> Mahendra Chhipa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Implemented the review comments.
>
> Changes requested by bchristi (Reviewer).
(I
On Mon, 1 Feb 2021 22:23:02 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> throwing the specific exceptions.
On Wed, 27 Jan 2021 22:44:00 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Implemented the review comments.
Changes requested by
On Mon, 25 Jan 2021 20:51:06 GMT, Mahendra Chhipa
wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8183372
>
> Mahendra Chhipa has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Implemented the review comments.
I like keeping the changes
On Fri, 22 Jan 2021 16:57:41 GMT, Mahendra Chhipa
wrote:
>> Can this be done all in `EnclosingClassTest.java`, without a new
>> `RunEnclosingClassTest.java`?
>>
>> Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may
>> just need to
>> change the `test()` calls to
On Wed, 20 Jan 2021 17:27:43 GMT, Mahendra Chhipa
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8183372
Can this be done all in `EnclosingClassTest.java`, without a new
`RunEnclosingClassTest.java`?
Adding the `@BeforeClass` and `@AfterClass` methods to what's there, you may
just need
On Mon, 11 Jan 2021 23:15:07 GMT, Stuart Marks wrote:
> Just fixing a broken link.
Marked as reviewed by bchristi (Reviewer).
-
PR: https://git.openjdk.java.net/jdk16/pull/106
On Fri, 18 Dec 2020 22:33:11 GMT, Brent Christian wrote:
> This change adds some extra test output for NativeLibraryTest, primarily via
> an update to the ForceGC utility class.
>
> It was observed that there was nothing preventing the Cleaner from cleaning
> the sho
On Fri, 18 Dec 2020 23:31:35 GMT, Naoto Sato wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> format() -> println()
>
> test/lib/jdk/test/lib/util/ForceGC.java line 48:
>
ystem.gc() is even called.
>
> The new 'o' reference is kept alive until FoceGC.await() has been called.
>
> We should find out a little more the next time NativeLibraryTest fails (or
> perhaps it won't fail anymore!)
Brent Christian has updated the pull request incrementally
On Fri, 18 Dec 2020 22:43:16 GMT, Mandy Chung wrote:
>> Brent Christian has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add sleep to ForceGC.await()
>
> test/lib/jdk/test/lib/util/
ystem.gc() is even called.
>
> The new 'o' reference is kept alive until FoceGC.await() has been called.
>
> We should find out a little more the next time NativeLibraryTest fails (or
> perhaps it won't fail anymore!)
Brent Christian has updated the pull request incrementally
This change adds some extra test output for NativeLibraryTest, primarily via an
update to the ForceGC utility class.
It was observed that there was nothing preventing the Cleaner from cleaning the
short-lived Object that ForceGC registers before await()/doit()/System.gc() is
even called.
The
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
; 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.
Bren
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
; 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.
Bren
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
>>
; 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.
Bren
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
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
; 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.
Bren
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:
>>
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.
1 - 100 of 497 matches
Mail list logo
