Re: Enrich the Lock interface

On 21/08/2023 11:56 pm, Albert Attard wrote: Hello. Thank you very much Pavel for helping me find more information about this. After some research (mainly by Pavel) we found a thread, with subject "/Default Functions for Lock Interface/", from October 2013 that discussed this exact thing.  I

Re: RFR: 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent [v2]

On Mon, 21 Aug 2023 15:44:56 GMT, Brian Burkhalter wrote: >> Revise some verbiage about the `RandomAccessFile(String,String)` constructor >> so that the string name of a file is referred to as _pathname string_ for >> consistency with `java.io.File`. > > Brian Burkhalter has updated the pull re

Withdrawn: 8307575: Migrate the serialization constructor accessors to Method Handles

On Sat, 6 May 2023 16:55:16 GMT, Chen Liang wrote: > Apparently method handle linking doesn't impose extra checks on constructor > invocation, so the special logic for the serialization constructor to call > superclass constructor in MagicAccessorImpl can be removed altogether with > old core

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 21:36:13 GMT, David Holmes wrote: >>> Nit: no need to pre-declare this, just use `int error = getJavaPath(...)` >> >> This one was intentional to keep the style consistent =) > > The others are more widely used and there is a desire to document their > meaning. That isn't ne

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v5]

> 8314491: Linux: jexec launched via PATH fails to find java Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision: declare error in-place - Changes: - all: https://git.openjdk.org/jdk/pull/15343/files - new: https://git.

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v2]

On Mon, 21 Aug 2023 21:10:36 GMT, Mandy Chung wrote: >> 8268829: Provide an optimized way to walk the stack with Class object only >> >> `StackWalker::walk` creates one `StackFrame` per frame and the current >> implementation >> allocates one `StackFrameInfo` and one `MemberName` objects per fr

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v9]

On Mon, 21 Aug 2023 22:10:06 GMT, Weibing Xiao wrote: >> Please refer to JDK-8314063. >> >> The failure scenario is due to the setting of connection timeout. It is >> either too small or not an optimal value for the system. When the client >> tries to connect to the server with LDAPs protocol.

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v9]

> Please refer to JDK-8314063. > > The failure scenario is due to the setting of connection timeout. It is > either too small or not an optimal value for the system. When the client > tries to connect to the server with LDAPs protocol. It requires the handshake > after the socket is created and

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 20:30:54 GMT, Vladimir Petko wrote: >> src/java.base/unix/native/launcher/jexec.c line 162: >> >>> 160: int argi = 0; /* index into old array */ >>> 161: size_talen = 0; /* length of new array */ >>> 162: int e

Re: RFR: 8268829: Provide an optimized way to walk the stack with Class object only [v2]

> 8268829: Provide an optimized way to walk the stack with Class object only > > `StackWalker::walk` creates one `StackFrame` per frame and the current > implementation > allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some > frameworks > like logging may only interest in

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v4]

> 8314491: Linux: jexec launched via PATH fails to find java Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision: remove unused imports - Changes: - all: https://git.openjdk.org/jdk/pull/15343/files - new: https://git.o

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 07:59:35 GMT, David Holmes wrote: > Nit: no need to pre-declare this, just use `int error = getJavaPath(...)` This one was intentional to keep the style consistent =) - PR Review Comment: https://git.openjdk.org/jdk/pull/15343#discussion_r1300614894

RFR: 8268829: Provide an optimized way to walk the stack with Class object only

8268829: Provide an optimized way to walk the stack with Class object only `StackWalker::walk` creates one `StackFrame` per frame and the current implementation allocates one `StackFrameInfo` and one `MemberName` objects per frame. Some frameworks like logging may only interest in the Class obje

Re: RFR: 8311500: StackWalker.getCallerClass() throws UOE if invoked reflectively [v3]

On Mon, 17 Jul 2023 11:02:38 GMT, Volker Simonis wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Fixed case when calling getCallerClass() from a @CallerSensitive method >> reflectively > > We actually have two p

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 07:14:44 GMT, Vladimir Petko wrote: >> 8314491: Linux: jexec launched via PATH fails to find java > > Vladimir Petko has updated the pull request incrementally with one additional > commit since the last revision: > > Review comment: use /proc/self/exe as the backup option

Re: RFR: 8313961: Enhance identification of special serialization methods [v2]

On Mon, 21 Aug 2023 16:13:37 GMT, ExE Boss wrote: >> Raffaello Giulietti has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Removed a spurious, unintended file. > > src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670: > >>

Re: RFR: 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent [v2]

On Mon, 21 Aug 2023 15:44:56 GMT, Brian Burkhalter wrote: >> Revise some verbiage about the `RandomAccessFile(String,String)` constructor >> so that the string name of a file is referred to as _pathname string_ for >> consistency with `java.io.File`. > > Brian Burkhalter has updated the pull re

Re: RFR: 8313961: Enhance identification of special serialization methods [v2]

On Mon, 21 Aug 2023 16:04:49 GMT, Raffaello Giulietti wrote: >> This improves the identification of the serialization magic fields and >> methods. > > Raffaello Giulietti has updated the pull request incrementally with one > additional commit since the last revision: > > Removed a spurious,

Re: @Incubating

Oh, I see that you are referring to JavaDoc tags as opposed to Java Annotations. In that case, nevermind. On Mon, Aug 21, 2023 at 11:59 AM David Alayachew wrote: > Hello Pavel, > > I am not on the teams of any of the mailing lists you responded to, but I > feel confident that I can answer this.

Re: RFR: 8313961: Enhance identification of special serialization methods

On Mon, 21 Aug 2023 15:46:53 GMT, Raffaello Giulietti wrote: > This improves the identification of the serialization magic fields and > methods. The test is a bit unusual, in that it uses the [Classfile API](https://openjdk.org/jeps/8280389). It is used to generate two classes that cannot be

Re: RFR: 8313961: Enhance identification of special serialization methods [v2]

> This improves the identification of the serialization magic fields and > methods. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Removed a spurious, unintended file. - Changes: - all: https://git.openjdk.org

Re: @Incubating

Hello Pavel, I am not on the teams of any of the mailing lists you responded to, but I feel confident that I can answer this. Most, if not all annotations provided by Java (@Override, @SuppressWarnings, @FunctionalInterface) actually start with uppercase. This is, in fact, maintaining the status

RFR: 8313961: Enhance identification of special serialization methods

This improves the identification of the serialization magic fields and methods. - Commit messages: - 8313961: Enhance identification of special serialization methods - 8313961: Enhance identification of special serialization methods - Merge branch 'master' into 8313961 - 8313961:

Re: RFR: 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent [v2]

On Sun, 20 Aug 2023 06:28:26 GMT, Jaikiran Pai wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8219567: Align checkWrite() verbiage with that of checkRead() > > src/java.base/share/classes/java/io/RandomAccessF

Re: RFR: 8219567: Name of first parameter of RandomAccessFile(String,String) is inconsistent [v2]

> Revise some verbiage about the `RandomAccessFile(String,String)` constructor > so that the string name of a file is referred to as _pathname string_ for > consistency with `java.io.File`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last rev

Re: RFR: 8288899: java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted" [v11]

> Addresses Jdk 8288899 : java/util/concurrent/ExecutorService/CloseTest.java > failed with "InterruptedException: sleep interrupted" and related issues. > > This is a major ForkJoin update (and hard to review -- sorry) that finally > addresses incompatibilities between ExecutorService and ForkJ

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

On Mon, 21 Aug 2023 15:00:59 GMT, Chen Liang wrote: >> I thought of this ,but i was not 100% sure. I will create CSR first. > > You can convert this method, or the `closed` field, to be package-private > (default access) instead. > I thought of this ,but i was not 100% sure. I will create CSR f

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v7]

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao wrote: >> Please refer to JDK-8314063. >> >> The failure scenario is due to the setting of connection timeout. It is >> either too small or not an optimal value for the system. When the client >> tries to connect to the server with LDAPs protocol.

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

On Mon, 21 Aug 2023 14:26:39 GMT, Vyom Tewari wrote: > With the current implementation of BufferedOutputStream if you close the > stream and try to write to the closed stream BufferedOutputStream does not > throw an IOException until the internal buffer is full. To fix this issue i > added a

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

On Mon, 21 Aug 2023 14:50:12 GMT, Vyom Tewari wrote: >> src/java.base/share/classes/java/io/FilterOutputStream.java line 209: >> >>> 207: * @return {@code true} if, and only if, this stream is open >>> 208: */ >>> 209: protected boolean isOpen(){ >> >> Adding a protected method to

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v8]

> Please refer to JDK-8314063. > > The failure scenario is due to the setting of connection timeout. It is > either too small or not an optimal value for the system. When the client > tries to connect to the server with LDAPs protocol. It requires the handshake > after the socket is created and

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

On Mon, 21 Aug 2023 14:37:37 GMT, Alan Bateman wrote: >> With the current implementation of BufferedOutputStream if you close the >> stream and try to write to the closed stream BufferedOutputStream does not >> throw an IOException until the internal buffer is full. To fix this issue i >> add

Re: RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

On Mon, 21 Aug 2023 14:26:39 GMT, Vyom Tewari wrote: > With the current implementation of BufferedOutputStream if you close the > stream and try to write to the closed stream BufferedOutputStream does not > throw an IOException until the internal buffer is full. To fix this issue i > added a

RFR: 4799358: BufferOutputStream.write() should immediately throw IOExcept on closed stream

With the current implementation of BufferedOutputStream if you close the stream and try to write to the closed stream BufferedOutputStream does not throw an IOException until the internal buffer is full. To fix this issue i added a private "ensureOpen" function to BufferedOutputStream which wi

Re: Enrich the Lock interface

Hello. Thank you very much Pavel for helping me find more information about this. After some research (mainly by Pavel) we found a thread, with subject "*Default Functions for Lock Interface*", from October 2013 that discussed this exact thing. I don't believe that this thread is available on th

ConcurrentHashMap - Removal for unnecessary bounds check i >= n || i + n >= nextn from transfer()

Hi, I am trying to get my head around to why you need i >= n || i + n >= nextn https://github.com/openjdk/jdk/blob/af5bf81754072fa5879726cfacb7404892b553f0/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java#L2465 in the transfer method of the CHM. https://github.com/open

Re: Enrich the Lock interface

Okay. Here are some relevant messages/threads I've been able to find within 5 minutes, using google.com: * https://mail.openjdk.org/pipermail/coin-dev/2009-March/000267.html * https://mail.openjdk.org/pipermail/core-libs-dev/2016-September/043303.html * https://mail.openjdk.org/pipermail/discu

Re: Enrich the Lock interface

I couldn't find a discussion on openjdk, but for those interested (and to save others some searching) there is a JBS ticket: https://bugs.openjdk.org/browse/JDK-8025597 --John On 21/08/2023 14:37, Pavel Rappo wrote: This is suggested every once in a while. I appreciate that openjdk mailing l

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v7]

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao wrote: >> Please refer to JDK-8314063. >> >> The failure scenario is due to the setting of connection timeout. It is >> either too small or not an optimal value for the system. When the client >> tries to connect to the server with LDAPs protocol.

Re: RFR: 8314063 : The socket is not closed in Connection::createSocket when the handshake failed for LDAP connection [v7]

On Sat, 19 Aug 2023 02:15:06 GMT, Weibing Xiao wrote: >> Please refer to JDK-8314063. >> >> The failure scenario is due to the setting of connection timeout. It is >> either too small or not an optimal value for the system. When the client >> tries to connect to the server with LDAPs protocol.

Re: Enrich the Lock interface

This is suggested every once in a while. I appreciate that openjdk mailing lists are not easily searchable, but with a bit of skill, you could find a few previous discussions on the topic. This has also been discussed on concurrency-interest (at cs.oswego.edu ), a dedicat

Enrich the Lock interface

Hello. I hope all is well. Do you believe it is a bad idea to enrich the Lock interface with a set of default methods that safely release the lock once ready? Consider the following (dangerous) example. final Lock lock = new ReentrantLock (); lock.lock(); /* Code that may throw an exception */

@Incubating

Does anybody remember why {@Incubating}, a JDK-specific tag introduced in JDK-8173354, starts with an uppercase letter? Put differently, are there any reasons why we should not make it conform to implicit convention of camelCase, like all other standard and JDK tags do?

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 07:14:44 GMT, Vladimir Petko wrote: >> 8314491: Linux: jexec launched via PATH fails to find java > > Vladimir Petko has updated the pull request incrementally with one additional > commit since the last revision: > > Review comment: use /proc/self/exe as the backup option

Integrated: 8311630: [s390] Implementation of Foreign Function & Memory API (Preview)

On Fri, 7 Jul 2023 07:55:03 GMT, sid8606 wrote: > Implementation of "Foreign Function & Memory API" for s390x (Big Endian). This pull request has now been integrated. Changeset: ec1f7a84 Author:Sidraya Committer: Andrew Dinn URL: https://git.openjdk.org/jdk/commit/ec1f7a8480db025a6

Re: RFR: JDK-8314272: Improve java.util.prefs.BackingStoreException: Couldn't get file lock.

On Mon, 21 Aug 2023 06:48:18 GMT, David Holmes wrote: > How long is the file-lock typically held? How many such tests can run > concurrently? And how long do we retry for? It's typically the sync method when writing back the cached changes. I suspect the Unix implementation could be easily re-

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

> 8314491: Linux: jexec launched via PATH fails to find java Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision: Review comment: use /proc/self/exe as the backup option - Changes: - all: https://git.openjdk.org/jdk/pull/

Re: RFR: 8314491: Linux: jexec launched via PATH fails to find java [v3]

On Mon, 21 Aug 2023 06:33:50 GMT, David Holmes wrote: > To minimise the impact on existing users can this be implemented as a > fallback if the initial attempt to locate `java` fails? Updated and re-run the affected test: == Test summary