On Tue, 25 May 2021 04:36:53 GMT, Jaikiran Pai wrote:
> Can I please get a review for this trivial fix in the code sample in javadoc
> comment of `javax.net.ssl.SSLEngine` class?
>
> I've run `make docs-image` locally and the generated javadoc after this
> change looks fine.
Marked as reviewe
Can I please get a review for this trivial fix in the code sample in javadoc
comment of `javax.net.ssl.SSLEngine` class?
I've run `make docs-image` locally and the generated javadoc after this change
looks fine.
-
Commit messages:
- 8255674 SSLEngine class description is missing "
On Tue, 18 May 2021 22:43:14 GMT, Mark Sheppard wrote:
> The test java/net/Socket/UdpSocket.java has been seen to fail with a
> BindException, in the testMaxSockets test, on a regular basis on
> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
> Sockets that may be create
On Mon, 24 May 2021 09:00:07 GMT, Daniel Fuchs wrote:
> Thanks for taking in my suggestions for FtpClient. I have also reviewed the
> changes to java.util.logging and JMX. I wish there was a way to handle
> doPrivileged returning void more nicely. Maybe component maintainers will be
> able to
On Mon, 17 May 2021 17:51:36 GMT, Weijun Wang wrote:
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.secu
> Hi all,
>
> Please review this fix for which corrects the order in which field values are
> returned from the `HttpURLConnection.getHeaderFields` and
> `URLConnection.getRequestProperties` methods.
>
> Currently, the implementation of these methods returns the values in reverse.
> This does
> On May 24, 2021, at 10:39 AM, Mark Sheppard wrote:
>
> I could have used return directly in multiple places ... but my style
> preference is a single exit point from a method
My preference is the opposite :-) I like the "early returns" coding style
because I don't need to "keep state" whil
On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard wrote:
>> The test java/net/Socket/UdpSocket.java has been seen to fail with a
>> BindException, in the testMaxSockets test, on a regular basis on
>> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
>> Sockets that may be cr
On Mon, 24 May 2021 14:34:54 GMT, Mark Sheppard wrote:
>> Mark Sheppard has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JDK-8265362 java/net/Socket/UdpSocket.java fails with
>> "java.net.BindException: Address already in use" (macos-aar
On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard wrote:
>> The test java/net/Socket/UdpSocket.java has been seen to fail with a
>> BindException, in the testMaxSockets test, on a regular basis on
>> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
>> Sockets that may be cr
On Mon, 24 May 2021 12:30:38 GMT, Mark Sheppard wrote:
>> The test java/net/Socket/UdpSocket.java has been seen to fail with a
>> BindException, in the testMaxSockets test, on a regular basis on
>> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
>> Sockets that may be cr
> Please review the test changes for [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> With JEP 411 and the default value of `-Djava.security.manager` becoming
> `disallow`, tests calling `System.setSecurityManager()` need
> `-Djava.security.manager=allow` when launched. This PR covers such
On Sun, 23 May 2021 16:35:43 GMT, Sean Mullan wrote:
>> src/java.base/share/classes/java/lang/SecurityManager.java line 104:
>>
>>> 102: * method will throw an {@code UnsupportedOperationException}). If the
>>> 103: * {@systemProperty java.security.manager} system property is set to
>>> the
>
> Please review this implementation of [JEP
> 411](https://openjdk.java.net/jeps/411).
>
> The code change is divided into 3 commits. Please review them one by one.
>
> 1.
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
> The essential change for this JEP, incl
On Sat, 22 May 2021 10:54:06 GMT, Mark Sheppard wrote:
>> BTW: Is one retry enough? There is at least one other replace where we've
>> had to retry to workaround a macOS bug and one retry was enough there too.
>
> I have submitted a significant number of MACH5 job runs with repeat mode over
> t
> The test java/net/Socket/UdpSocket.java has been seen to fail with a
> BindException, in the testMaxSockets test, on a regular basis on
> macOS-aarch64 platform. testMaxSockets tests the maximum number of UDP
> Sockets that may be created as defined by a system property
> sun.net.maxDatagramS
On Mon, 24 May 2021 10:13:55 GMT, Сергей Цыпанов
wrote:
>> But don't people access these internal code at their own risk, as jdk may
>> change these code at any time without notice?
>
> True, I just wonder whether it's OK to change internals when we know for sure
> that this breaks 3rd party c
On Mon, 24 May 2021 09:25:08 GMT, liach
wrote:
>> Should we then revert the changes to `JarIndex`?
>
> But don't people access these internal code at their own risk, as jdk may
> change these code at any time without notice?
True, I just wonder whether it's OK to change internals when we know
On Mon, 24 May 2021 07:13:29 GMT, Сергей Цыпанов
wrote:
>> Just for completeness, they're using the add-exports:
>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/launchers/itw-modularjdk.args#L19
>
> Should we then revert the changes to `JarIndex`?
But don't people access these intern
On Fri, 21 May 2021 20:37:30 GMT, Weijun Wang wrote:
>> The code change refactors classes that have a `SuppressWarnings("removal")`
>> annotation that covers more than 50KB of code. The big annotation is often
>> quite faraway from the actual deprecated API usage it is suppressing, and
>> with
On Fri, 21 May 2021 15:12:20 GMT, Thiago Henrique Hüpner
wrote:
>>> IcedTea-Web seems to be using this method reflectively:
>>> https://github.com/AdoptOpenJDK/IcedTea-Web/blob/master/common/src/main/java/net/adoptopenjdk/icedteaweb/jdk89access/JarIndexAccess.java#L80
>>
>> I assume this doesn'
On Fri, 21 May 2021 14:18:16 GMT, Daniel Fuchs wrote:
>> The usage of `LinkedList` is senseless and can be replaced with either
>> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>>
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/j
On Fri, 21 May 2021 14:15:53 GMT, Daniel Fuchs wrote:
>> The usage of `LinkedList` is senseless and can be replaced with either
>> `ArrayList` or `ArrayDeque` which are both more compact and effective.
>>
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/util/j
23 matches
Mail list logo
