RFR: 8307408: Some jdk/sun/tools/jhsdb tests don't pass test JVM args to the debuggee JVM
Normally we want the test args passed to the SA debuggee. In fact for proper SA test coverage, it is more important for the test args to be passed to the debuggee than to be passed to the test or the the SA tool that the test launches. For a couple of jhsdb tests that launch jshell as the debuggee, this wasn't happening, and jshell was always launched with no extra args. Fixing this was very simple. Dealing with the unexpected fallout wasn't. I filed a number of bugs that turned up (or where otherwise exposed) once I fixed this CR. The main onces were: [JDK-8313798](https://bugs.openjdk.org/browse/JDK-8313798) [aarch64] sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java sometimes times out on aarch64 [JDK-8313655](https://bugs.openjdk.org/browse/JDK-8313655) sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java frequently fails with SerialGC For the first one I'm problem listing the test for now, but have a fix and will get it out for review shortly. For the second one I'm just having the test avoid the issue by not allowing jshell to be launched with SerialGC. Note also that this change caused some failures with ZGC due to an already filed CR. - Commit messages: - Pass test args to debuggee Changes: https://git.openjdk.org/jdk/pull/15168/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15168=00 Issue: https://bugs.openjdk.org/browse/JDK-8307408 Stats: 17 lines in 4 files changed: 13 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15168/head:pull/15168 PR: https://git.openjdk.org/jdk/pull/15168
Re: RFR: 8041488: Locale-Dependent List Patterns [v4]
> Introducing a new formatting class for locale-dependent list patterns. The > class is to provide the functionality from the Unicode Consortium's LDML > specification for [list > patterns](https://www.unicode.org/reports/tr35/tr35-general.html#ListPatterns). > For example, given a list of String as "Monday", "Wednesday", "Friday", its > `format` method would produce "Monday, Wednesday, and Friday" in US English. > A CSR has also been drafted, and its draft javadoc can be viewed here: > https://cr.openjdk.org/~naoto/JDK-8041488-ListPatterns-PR/api.00/java.base/java/text/ListFormat.html Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: parsePosition update - Changes: - all: https://git.openjdk.org/jdk/pull/15130/files - new: https://git.openjdk.org/jdk/pull/15130/files/cf3dddba..50ba267c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15130=03 - incr: https://webrevs.openjdk.org/?repo=jdk=15130=02-03 Stats: 42 lines in 2 files changed: 40 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15130/head:pull/15130 PR: https://git.openjdk.org/jdk/pull/15130
Re: RFR: JDK-8313670: Simplify shared lib name handling code in some tests
On Fri, 4 Aug 2023 18:34:52 GMT, Chris Plummer wrote: >> There is coding e.g. in >> https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 >> that deals with shared lib naming on different OS. >> This code should be simplified. > > test/lib/jdk/test/lib/Platform.java line 376: > >> 374: } >> 375: } >> 376: > > The following tests could leverage this new API. Just look for calls to > `Platform.sharedLibraryExt()`: > > test/hotspot/jtreg/runtime/signal/SigTestDriver.java > test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java > test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java > > Perhaps a `Platform.buildSharedLibraryName()` API is worth considering. The fix looks good in general. But I like the suggestion from Chris above - PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284840135
Integrated: 8311517: Add performance information to ArrayList javadoc
On Wed, 26 Jul 2023 11:02:20 GMT, dan1st wrote: > The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add > addFirst(), removeFirst() and reversed() methods to lists. > However, the Javadoc of List mentions: > > The size, isEmpty, get, set, iterator, and listIterator operations run in > constant time. The add operation runs in amortized constant time, that is, > adding n elements requires O(n) time. All of the other operations run in > linear time (roughly speaking). The constant factor is low compared to that > for the LinkedList implementation. > > This PR updates that Javadoc to factor in the new methods introduced by JEP > 431. > > https://bugs.openjdk.org/browse/JDK-8311517 > https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html > https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html > > This PR only affects documentation. This pull request has now been integrated. Changeset: b463c6d3 Author:danthe1st Committer: Stuart Marks URL: https://git.openjdk.org/jdk/commit/b463c6d3b0f27c8f124b5733cb9e7677542abe37 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8311517: Add performance information to ArrayList javadoc Reviewed-by: smarks, bpb - PR: https://git.openjdk.org/jdk/pull/15040
Integrated: 8159527: Collections mutator methods should all be marked as optional operations
On Wed, 2 Aug 2023 20:11:35 GMT, Stuart Marks wrote: > Adjust the leading javadoc sentence of several collections mutator methods to > include "(optional operation)" as appropriate. Also adjust doc for > UnsupportedOperationException on those methods as necessary. This pull request has now been integrated. Changeset: b2add96c Author:Stuart Marks URL: https://git.openjdk.org/jdk/commit/b2add96c353f15b91524e10207e49841298bed01 Stats: 70 lines in 5 files changed: 17 ins; 8 del; 45 mod 8159527: Collections mutator methods should all be marked as optional operations Reviewed-by: naoto, bpb - PR: https://git.openjdk.org/jdk/pull/15127
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors [v3]
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if > the is an IOException generation when the output stream was flushing the > buffer. > > Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: update error message - Changes: - all: https://git.openjdk.org/jdk/pull/15143/files - new: https://git.openjdk.org/jdk/pull/15143/files/abf8126c..f33a565c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15143=02 - incr: https://webrevs.openjdk.org/?repo=jdk=15143=01-02 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/15143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143 PR: https://git.openjdk.org/jdk/pull/15143
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors [v2]
On Fri, 4 Aug 2023 18:24:04 GMT, Weibing Xiao wrote: >> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if >> the is an IOException generation when the output stream was flushing the >> buffer. >> >> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657. > > Weibing Xiao has updated the pull request incrementally with one additional > commit since the last revision: > > updated the code according the review comments 1) Extracted the methods for finally black of Connection::cleanUP 2) Move the test class to LDAP test folder and updated the test comments. 3) Removed the redundant code and update the import statement. - PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1666054865
Re: RFR: JDK-8313670: Simplify shared lib name handling code in some tests
On Fri, 4 Aug 2023 09:59:41 GMT, Matthias Baesken wrote: > There is coding e.g. in > https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 > that deals with shared lib naming on different OS. > This code should be simplified. Changes requested by cjplummer (Reviewer). test/lib/jdk/test/lib/Platform.java line 376: > 374: } > 375: } > 376: The following tests could leverage this new API. Just look for calls to `Platform.sharedLibraryExt()`: test/hotspot/jtreg/runtime/signal/SigTestDriver.java test/hotspot/jtreg/vmTestbase/nsk/jvmti/NativeLibraryCopier.java test/jdk/com/sun/tools/attach/warnings/DynamicLoadWarningTest.java Perhaps a `Platform.buildSharedLibraryName()` API is worth considering. - PR Review: https://git.openjdk.org/jdk/pull/15151#pullrequestreview-1563375724 PR Review Comment: https://git.openjdk.org/jdk/pull/15151#discussion_r1284731606
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors [v2]
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if > the is an IOException generation when the output stream was flushing the > buffer. > > Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: updated the code according the review comments - Changes: - all: https://git.openjdk.org/jdk/pull/15143/files - new: https://git.openjdk.org/jdk/pull/15143/files/c7feb93f..abf8126c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk=15143=01 - incr: https://webrevs.openjdk.org/?repo=jdk=15143=00-01 Stats: 409 lines in 3 files changed: 205 ins; 198 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/15143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143 PR: https://git.openjdk.org/jdk/pull/15143
Wrong exception in ComputedConstant#orElse Javadoc
When viewing the propsed Javadoc of ComputedConstant#orElse (https://cr.openjdk.org/~pminborg/computed-constant/api/java.base/java/lang/ComputedConstant.html#orElse(V)),it mentions throwing an NoSuchElementException in case the element cannot be bound. However, the Javadoc also mentions returning the passed value in that case. If we take a look at the code for that in the Leyden repository (https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L127 and https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L161C27-L161C27), we can see that "rethrow" is false and no NoSuchElementException is thrown (https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/jdk/internal/constant/AbstractComputedConstant.java#L183-L186). I think the "@throws NoSuchElementException" should be removed from ComputedConstant#orElse (https://github.com/openjdk/leyden/blob/b9219784cc277417dc112a7fbf652bdc021cf806/src/java.base/share/classes/java/lang/ComputedConstant.java#L294C19-L294C19) Yours, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors
On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao wrote:
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
> the is an IOException generation when the output stream was flushing the
> buffer.
>
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 652:
> 650: } catch (IOException ie) {
> 651: if (debug)
> 652: System.err.println("Connection: problem
> closing socket: " + ie);
How about combining the debug statement here with the one below and just print
the socket isClosed state, something like
if (debug) {
System.err.println("Connection: problem cleaning-up the connection: " + ie);
System.err.println("Socket isClosed: " + sock.isClosed());
}
The text was changed here since the exception can also be thrown by
`unpauseReader`
src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 664:
> 662: } catch (IOException ioe) {
> 663: if (debug)
> 664: System.err.println("Connection::cleanup
> problem: " + ioe);
Maybe change the message here to highlight the fact that it's the 2nd attemp to
clean-up the connection
test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 28:
> 26: import javax.naming.directory.InitialDirContext;
> 27: import javax.net.SocketFactory;
> 28: import java.io.*;
Can we please use a set of class imports instead of package import here:
import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 44:
> 42: */
> 43:
> 44: public class SocketCloseTest {
Can we change the test location from `test/javax/naming/InitialContext` to an
LDAP-implementation specific folder - `test/jdk/com/sun/jndi/ldap`
test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 53:
> 51: };
> 52: private static final int SEARCH_SIZE = 87;
> 53: private static final byte[] SEARCH_RESPONSE = new byte[]{
`SEARCH_RESPONSE`, `SEARCH_SIZE` and `BIND_SIZE` are not used in the test. If
they're not needed they can be removed.
test/jdk/javax/naming/InitialContext/SocketCloseTest.java line 71:
> 69:
> 70: props.put(Context.INITIAL_CONTEXT_FACTORY,
> "com.sun.jndi.ldap.LdapCtxFactory");
> 71: props.put(Context.PROVIDER_URL,
> "ldap://localhost:1389/o=example;);
For future test maintainers - can we please clarify that the hostname and port
do not matter here because the provided custom socket factory doesn't establish
a connection to the specified provider URL
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284631833
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284633364
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284569423
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284579620
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284582686
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1284587752
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Fri, 4 Aug 2023 07:11:58 GMT, dan1st wrote: >> Thanks for the updates. I've drafted a CSR; see link in header. Please take >> a look. > >> Thanks for the updates. I've drafted a CSR; see link in header. Please take >> a look. > > @stuart-marks Thanks, the CSR looks good to me. I guess the `Fix versions` > field will be added when the CSR is reviewed? > Also, I guess this change will not be backported to 21 as it requires a CSR > and we are approaching the initial release candidate? @danthe1st >Thanks, the CSR looks good to me. I guess the Fix versions field will be added >when the CSR is reviewed? Also, I guess this change will not be backported to 21 as it requires a CSR and we are approaching the initial release candidate? I've marked the CSR with Fix-Version 22. The bug itself should have its Fix-Version stay at "tbd" because it gets filled in automatically when the change is integrated. That doesn't happen for CSRs. (Admittedly this is kind of confusing and there's been some discussion about the best way to handle this.) Right, it's too late to get this into JDK 21, and there's no compelling reason to do so. For stuff like this we just fix it in the "latest" release and move forward. - PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665885792
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Fri, 4 Aug 2023 15:36:05 GMT, dan1st wrote:
>> src/java.base/share/classes/java/util/ArrayList.java line 46:
>>
>>> 44: * {@code listIterator}, and {@code reversed} operations run in
>>> constant time.
>>> 45: * The {@code add}, and {@code addLast} operations runs in amortized
>>> 46: * constant time, that is, adding n elements requires O(n) time.
>>> All of
>>
>> Should `n` and `O(n)` here be in italics or code font?
>
> It wasn't in italic or code font before so I didn't change that. However, I
> am open to changing that.
Fine to leave it as is in that case.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284596785
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Thu, 27 Jul 2023 06:31:06 GMT, dan1st wrote: >> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add >> addFirst(), removeFirst() and reversed() methods to lists. >> However, the Javadoc of List mentions: >> > The size, isEmpty, get, set, iterator, and listIterator operations run in >> constant time. The add operation runs in amortized constant time, that is, >> adding n elements requires O(n) time. All of the other operations run in >> linear time (roughly speaking). The constant factor is low compared to that >> for the LinkedList implementation. >> >> This PR updates that Javadoc to factor in the new methods introduced by JEP >> 431. >> >> https://bugs.openjdk.org/browse/JDK-8311517 >> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html >> >> This PR only affects documentation. > > dan1st has updated the pull request incrementally with one additional commit > since the last revision: > > 8311517: ArrayList Javadoc of getFirst/getLast/removeLast > > as requested by > https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426 Marked as reviewed by bpb (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/15040#pullrequestreview-1563165924
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Fri, 4 Aug 2023 15:31:59 GMT, Brian Burkhalter wrote:
>> dan1st has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> 8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>>
>> as requested by
>> https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426
>
> src/java.base/share/classes/java/util/ArrayList.java line 46:
>
>> 44: * {@code listIterator}, and {@code reversed} operations run in constant
>> time.
>> 45: * The {@code add}, and {@code addLast} operations runs in amortized
>> 46: * constant time, that is, adding n elements requires O(n) time.
>> All of
>
> Should `n` and `O(n)` here be in italics or code font?
It wasn't in italic or code font before so I didn't change that. However, I am
open to changing that.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284573107
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Thu, 27 Jul 2023 06:31:06 GMT, dan1st wrote:
>> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add
>> addFirst(), removeFirst() and reversed() methods to lists.
>> However, the Javadoc of List mentions:
>> > The size, isEmpty, get, set, iterator, and listIterator operations run in
>> constant time. The add operation runs in amortized constant time, that is,
>> adding n elements requires O(n) time. All of the other operations run in
>> linear time (roughly speaking). The constant factor is low compared to that
>> for the LinkedList implementation.
>>
>> This PR updates that Javadoc to factor in the new methods introduced by JEP
>> 431.
>>
>> https://bugs.openjdk.org/browse/JDK-8311517
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html
>>
>> This PR only affects documentation.
>
> dan1st has updated the pull request incrementally with one additional commit
> since the last revision:
>
> 8311517: ArrayList Javadoc of getFirst/getLast/removeLast
>
> as requested by
> https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426
src/java.base/share/classes/java/util/ArrayList.java line 46:
> 44: * {@code listIterator}, and {@code reversed} operations run in constant
> time.
> 45: * The {@code add}, and {@code addLast} operations runs in amortized
> 46: * constant time, that is, adding n elements requires O(n) time. All
> of
Should `n` and `O(n)` here be in italics or code font?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15040#discussion_r1284569426
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors
On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao wrote:
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
> the is an IOException generation when the output stream was flushing the
> buffer.
>
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
why not restructure the finally block a little ... refactor extract methods
flushOutputStream,
closeConnectionSocket
... should the outputStream be closed in this finally block, also?
} finally {
flushOutputStream(outStream);
closeConnectionSocket(sock);
try {
unpauseReader();
} catch (IOException ie) {
if (debug)
System.err.println("Connection.cleanup: problem
with unpuaseReader " + ie);
}
...
private void flushOutputStream (OutputStream outputStream) {
try {
outStream.flush();
outStream.close();
} catch (IOException ioEx) {
if (debug)
System.err.println("Connection.flushOutputStream: OutputStream
flush or close problem " + ioEx);
}
}
private void closeConnectionSocket (Socket sock) {
//bug 8313657, socket not closed util GC running
try {
sock.close();
} catch (IOException ioEx) {
if (debug)
System.err.println("ConnectioncloseConnectioSocket: problem
closing socket: " + ioEx);
}
}
-
PR Comment: https://git.openjdk.org/jdk/pull/15143#issuecomment-1665777500
RFR: 8313768: Reduce interaction with volatile field in j.u.l.StreamHandler
In `publish0()`, `flush0()` and `flushAndClose()`methods of `StreamHandler` we read multiple times from volatile writer. The access number can be reduced by reading the field into local variable once. - Commit messages: - 8313768: Reduce interaction with volatile field in j.u.l.StreamHandler Changes: https://git.openjdk.org/jdk/pull/15161/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15161=00 Issue: https://bugs.openjdk.org/browse/JDK-8313768 Stats: 7 lines in 1 file changed: 6 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15161/head:pull/15161 PR: https://git.openjdk.org/jdk/pull/15161
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors
On Thu, 3 Aug 2023 17:59:10 GMT, Alan Bateman wrote:
>> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
>> the is an IOException generation when the output stream was flushing the
>> buffer.
>>
>> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 658:
>
>> 656: unpauseReader();
>> 657: if (debug) {
>> 658: if (sock.isClosed()) {
>
> How is it possible for sock.close() to succeed but isClosed to return false?
It is an unreachable code and got removed.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1283640395
RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors
com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if the is an IOException generation when the output stream was flushing the buffer. Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657. - Commit messages: - reformat the code - remove unreachable code and reformatting the code - 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors Changes: https://git.openjdk.org/jdk/pull/15143/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15143=00 Issue: https://bugs.openjdk.org/browse/JDK-8313657 Stats: 197 lines in 2 files changed: 196 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15143/head:pull/15143 PR: https://git.openjdk.org/jdk/pull/15143
Re: RFR: 8313657 : com.sun.jndi.ldap.Connection.cleanup does not close connections on SocketTimeoutErrors
On Thu, 3 Aug 2023 17:32:43 GMT, Weibing Xiao wrote:
> com.sun.jndi.ldap.Connection::leanup does not close the underlying socket if
> the is an IOException generation when the output stream was flushing the
> buffer.
>
> Please refer to the bug https://bugs.openjdk.org/browse/JDK-8313657.
src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 658:
> 656: unpauseReader();
> 657: if (debug) {
> 658: if (sock.isClosed()) {
How is it possible for sock.close() to succeed but isClosed to return false?
-
PR Review Comment: https://git.openjdk.org/jdk/pull/15143#discussion_r1283542206
RFR: JDK-8313670: Simplify shared lib name handling code in some tests
There is coding e.g. in https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java#L72 that deals with shared lib naming on different OS. This code should be simplified. - Commit messages: - JDK-8313670 Changes: https://git.openjdk.org/jdk/pull/15151/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15151=00 Issue: https://bugs.openjdk.org/browse/JDK-8313670 Stats: 77 lines in 6 files changed: 13 ins; 59 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/15151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15151/head:pull/15151 PR: https://git.openjdk.org/jdk/pull/15151
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Thu, 27 Jul 2023 06:31:06 GMT, dan1st wrote: >> The [JEP for sequenced collections](https://openjdk.org/jeps/431) would add >> addFirst(), removeFirst() and reversed() methods to lists. >> However, the Javadoc of List mentions: >> > The size, isEmpty, get, set, iterator, and listIterator operations run in >> constant time. The add operation runs in amortized constant time, that is, >> adding n elements requires O(n) time. All of the other operations run in >> linear time (roughly speaking). The constant factor is low compared to that >> for the LinkedList implementation. >> >> This PR updates that Javadoc to factor in the new methods introduced by JEP >> 431. >> >> https://bugs.openjdk.org/browse/JDK-8311517 >> https://mail.openjdk.org/pipermail/core-libs-dev/2023-June/107328.html >> https://mail.openjdk.org/pipermail/core-libs-dev/2023-July/109637.html >> >> This PR only affects documentation. > > dan1st has updated the pull request incrementally with one additional commit > since the last revision: > > 8311517: ArrayList Javadoc of getFirst/getLast/removeLast > > as requested by > https://github.com/openjdk/jdk/pull/15040#issuecomment-1652555426 LGTM (not a Reviewer) - PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665309184
[jdk21] RFR: 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match
Hi all, This pull request contains a backport of commit [61c58fdd](https://github.com/openjdk/jdk/commit/61c58fdd00727da2841a052477e4f4ecfa7094d6) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Raffaello Giulietti on 4 Aug 2023 and was reviewed by Alan Bateman and Stuart Marks. Thanks! - Commit messages: - Backport 61c58fdd00727da2841a052477e4f4ecfa7094d6 Changes: https://git.openjdk.org/jdk21/pull/164/files Webrev: https://webrevs.openjdk.org/?repo=jdk21=164=00 Issue: https://bugs.openjdk.org/browse/JDK-8312976 Stats: 88 lines in 2 files changed: 80 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk21/pull/164.diff Fetch: git fetch https://git.openjdk.org/jdk21.git pull/164/head:pull/164 PR: https://git.openjdk.org/jdk21/pull/164
Integrated: 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match
On Thu, 27 Jul 2023 11:25:57 GMT, Raffaello Giulietti wrote: > Fixes a bug showing up after > [JDK-8132995](https://bugs.openjdk.org/browse/JDK-8132995) when there are > capturing groups outside the match. This pull request has now been integrated. Changeset: 61c58fdd Author:Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/61c58fdd00727da2841a052477e4f4ecfa7094d6 Stats: 88 lines in 2 files changed: 80 ins; 0 del; 8 mod 8312976: MatchResult produces StringIndexOutOfBoundsException for groups outside match Reviewed-by: alanb, smarks - PR: https://git.openjdk.org/jdk/pull/15053
Re: RFR: 8311517: Add performance information to ArrayList javadoc [v2]
On Fri, 4 Aug 2023 03:08:26 GMT, Stuart Marks wrote: > Thanks for the updates. I've drafted a CSR; see link in header. Please take a > look. @stuart-marks Thanks, the CSR looks good to me. I guess the `Fix versions` field will be added when the CSR is reviewed? - PR Comment: https://git.openjdk.org/jdk/pull/15040#issuecomment-1665120343
