> On Aug 22, 2023, at 4:42 PM, Alexander Matveev
> wrote:
>
> Hi Alan,
>
>> On Aug 22, 2023, at 3:35 PM, Alan Snyder wrote:
>>
>> I’m confused by this.
>>
>> The issue is marked as macOS, but on macOS you don’t need to “find” the
>> certificate, codesign finds it using the text supplied
On Tue, 22 Aug 2023 18:21:17 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
Hi Alan,
> On Aug 22, 2023, at 3:35 PM, Alan Snyder wrote:
>
> I’m confused by this.
>
> The issue is marked as macOS, but on macOS you don’t need to “find” the
> certificate, codesign finds it using the text supplied by the user. jpackage
> does not need to understand this text.
This is
On Tue, 22 Aug 2023 18:21:17 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
On Tue, 22 Aug 2023 18:21:17 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
I’m confused by this.
The issue is marked as macOS, but on macOS you don’t need to “find” the
certificate, codesign finds it using the text supplied by the user. jpackage
does not need to understand this text.
Surely codesign can handle certificates with unicode names, can’t it?
> On Aug 22,
- Added support for certificates with UNICODE characters.
- Added new approach to find certificate using "security" and "openssl"
commands. Just "security" does not works, since it can truncate certificates
name. "security" is used to dump certificate in PEM format and then "openssl"
to get
Please review this PR and associated
[CSR](https://bugs.openjdk.org/browse/JDK-8314546) which expands on the
`java.text.ChoiceFormat` specification regarding its pattern.
`j.text.ChoiceFormat` provides an example pattern in the class description, but
beyond that it does not specify any
> 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
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
On Mon, 21 Aug 2023 16:57:57 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 1670:
>>
>>> 1668: ObjectStreamField[] serialPersistentFields = null;
>>> 1669: try {
>>> 1670: Field f = getDeclaredField(cl,
> 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
> 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
On Tue, 22 Aug 2023 06:57:23 GMT, Andrey Turbanov wrote:
> Field is unused since
> [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) -
> https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e
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
On Thu, 10 Aug 2023 15:30:19 GMT, Swati Sharma wrote:
> In addition to the issue
> [JDK-8311178](https://bugs.openjdk.org/browse/JDK-8311178), logically fixing
> the scope from benchmark to thread for below benchmark files having shared
> state, also which fixes few of the benchmarks
> 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
On Thu, 13 Jul 2023 23:05:48 GMT, Glavo wrote:
>> `ByteArray` and `ByteArrayLittleEndian` are very useful tool classes that
>> can be used in many places to performance tuning.
>>
>> Currently they are implemented by `VarHandle`, so using them may have some
>> impact on startup time.
>>
>>
On Tue, 22 Aug 2023 06:57:23 GMT, Andrey Turbanov wrote:
> Field is unused since
> [JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) -
> https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e
On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote:
>> Please review this trivial PR.
>
> Pavel Rappo 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 8314753
> - Initial commit
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
On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote:
>> Please review this trivial PR.
>
> Pavel Rappo 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 8314753
> - Initial commit
On Fri, 23 Jun 2023 20:00:12 GMT, Glavo wrote:
> Using `ByteArrayLittleEndian` is simpler and faster.
>
> `make test TEST="micro:java.util.zip.ZipFileOpen"`:
>
>
> Benchmark (size) Mode Cnt Score Error Units
> - ZipFileOpen.openCloseZipFile 512 avgt
> Please review this trivial PR.
Pavel Rappo 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 8314753
- Initial commit
-
Changes: https://git.openjdk.org/jdk/pull/15385/files
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote:
> Please review this simple PR.
This pull request has now been integrated.
Changeset: f39fc0aa
Author:Pavel Rappo
URL:
https://git.openjdk.org/jdk/commit/f39fc0aa2de19332fa51af605ece0660891d8c7a
Stats: 124 lines in 28 files
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote:
> Please review this simple PR.
You can leave the copyright years as-is.
-
PR Comment: https://git.openjdk.org/jdk/pull/15382#issuecomment-1688104170
After [JDK-8245241](https://bugs.openjdk.org/browse/JDK-8245241), the field
`sun.util.locale.provider.LocaleProviderAdapter#defaultLocaleProviderAdapter`
is only written in `` and then is not used after.
We can remove it.
-
Commit messages:
- 8312521: Unused field
On Tue, 22 Aug 2023 12:23:18 GMT, Mark Reinhold wrote:
> I wouldn’t update the copyright year as you have in some of these files.
I was taught to do it every time when I change a file. Would you like me to
revert those changes to copyright years in this case?
-
PR Comment:
On Tue, 22 Aug 2023 08:42:32 GMT, Pavel Rappo wrote:
> Please review this simple PR.
Removing `@revised` tags is not a substantive change, so I wouldn’t update the
copyright year as you have in some of these files.
Otherwise, this looks fine.
-
Marked as reviewed by mr (Lead).
I've published a PR to change the name of that tag:
https://github.com/openjdk/jdk/pull/15387
> On 21 Aug 2023, at 10:57, Pavel Rappo wrote:
>
> Does anybody remember why {@Incubating}, a JDK-specific tag introduced in
> JDK-8173354, starts with an uppercase letter? Put differently, are
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote:
> Please review this trivial PR.
CC'ing client-libs-dev because @beaninfo and @Note and jmx-dev because of
@since.unbundled, which might've been used for JMX before 2007.
-
PR Comment:
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote:
> Please review this trivial PR.
CC'ing core-libs-dev whose members might also have some recollection on tags in
question.
-
PR Comment: https://git.openjdk.org/jdk/pull/15385#issuecomment-1687995105
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
Please review this simple PR.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/15382/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=15382=00
Issue: https://bugs.openjdk.org/browse/JDK-8314738
Stats: 124 lines in 28 files changed: 0 ins; 116
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Mon, 21 Aug 2023 07:14:28 GMT, Alan Bateman 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
On Tue, 27 Jun 2023 18:29:45 GMT, Tim Prinzing wrote:
>> src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 408:
>>
>>> 406: @Override
>>> 407: public int read(ByteBuffer buf) throws IOException {
>>> 408: if (!SocketReadEvent.enabled()) {
>>
>> The read/write
On Wed, 28 Jun 2023 06:09:14 GMT, Alan Bateman wrote:
>> Tim Prinzing has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains ten commits:
>>
>> - remove unused SOCKET_READ and SOCKET_WRITE configurations.
>> - Merge branch 'master'
On Wed, 28 Jun 2023 18:53:12 GMT, Tim Prinzing wrote:
>> The socket read/write JFR events currently use instrumentation of java.base
>> code using templates in the jdk.jfr modules. This results in some java.base
>> code residing in the jdk.jfr module which is undesirable.
>>
>> JDK19 added
On Thu, 22 Jun 2023 13:39:51 GMT, Erik Gahlin wrote:
> An exception event will be emitted. The event is disabled by default, but
> there is ongoing work on a throttling mechanism, so it can be always-on.
Good, I think the exception cases are probably the most interesting for this
area when it
On Wed, 2 Aug 2023 20:09:39 GMT, Alan Bateman wrote:
> https://bugs.openjdk.org/browse/JDK-8310979 - better exception handling
> https://bugs.openjdk.org/browse/JDK-8310978 - missing code paths for event
> generation https://bugs.openjdk.org/browse/JDK-8310994 - non-blocking, event
> for
Field is unused since
[JDK-8004698](https://bugs.openjdk.org/browse/JDK-8004698) -
https://github.com/openjdk/jdk/commit/b29b4794613a2aca125c2a6e9f8ed1d0f01a4ce2#diff-2b6035b7134d61a89cfee1ad7bdc1bf21ce37421358375d6399de950c17c0c8e
-
Commit messages:
- [PATCH] Remove unused field
42 matches
Mail list logo
