Hi,
Could someone please review my proposed changeset for JDK-8235139: '`Remove the
socket impl factory mechanism`' ?
These changes propose to deprecate (for the eventual removal) the API points
for statically configuring a system-wide factory for the `Socket`,
`ServerSocket`, and `DatagramSoc
On Wed, 3 Feb 2021 11:03:51 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my proposed changeset for JDK-8235139: '`Remove
> the socket impl factory mechanism`' ?
>
> These changes propose to deprecate (for the eventual removal) the API points
> for statically configurin
On Tue, 2 Feb 2021 16:14:10 GMT, Michael McMahon wrote:
>> This change clarifies the InetSocketAddress::toString specification, which
>> was recently updated to reflect an implementation change [1]. The
>> specification is not changed, but it is enhanced with two examples and some
>> more verb
On Wed, 3 Feb 2021 11:36:23 GMT, Daniel Fuchs wrote:
>> Hi,
>>
>> Could someone please review my proposed changeset for JDK-8235139: '`Remove
>> the socket impl factory mechanism`' ?
>>
>> These changes propose to deprecate (for the eventual removal) the API points
>> for statically configuri
On Wed, 3 Feb 2021 11:36:28 GMT, Julia Boes wrote:
>> Maybe could say "rather than parsing the output of toString()" instead of
>> "rather than parsing the string representation". Might be clearer?
>
> Ok, how about this: "rather than parsing the string returned by this
> toString() method"?
T
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote:
> This change clarifies the InetSocketAddress::toString specification, which
> was recently updated to reflect an implementation change [1]. The
> specification is not changed, but it is enhanced with two examples and some
> more verbiage, as
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote:
> This change clarifies the InetSocketAddress::toString specification, which
> was recently updated to reflect an implementation change [1]. The
> specification is not changed, but it is enhanced with two examples and some
> more verbiage, as
On Tue, 2 Feb 2021 15:55:40 GMT, Julia Boes wrote:
> This change clarifies the InetSocketAddress::toString specification, which
> was recently updated to reflect an implementation change [1]. The
> specification is not changed, but it is enhanced with two examples and some
> more verbiage, as
> This change clarifies the InetSocketAddress::toString specification, which
> was recently updated to reflect an implementation change [1]. The
> specification is not changed, but it is enhanced with two examples and some
> more verbiage, as per earlier suggestions on the net-dev mailing list [
On Wed, 3 Feb 2021 14:17:58 GMT, Julia Boes wrote:
>> This change clarifies the InetSocketAddress::toString specification, which
>> was recently updated to reflect an implementation change [1]. The
>> specification is not changed, but it is enhanced with two examples and some
>> more verbiage,
On Wed, 3 Feb 2021 11:03:51 GMT, Patrick Concannon
wrote:
> Hi,
>
> Could someone please review my proposed changeset for JDK-8235139: '`Remove
> the socket impl factory mechanism`' ?
>
> These changes propose to deprecate (for the eventual removal) the API points
> for statically configurin
On Wed, 3 Feb 2021 14:19:27 GMT, Alan Bateman wrote:
>> Julia Boes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> small adjustment
>
> src/java.base/share/classes/java/net/InetSocketAddress.java line 387:
>
>> 385: * To retrieve a
On Tue, 2 Feb 2021 01:19:01 GMT, Clive Verghese wrote:
>> Redo for 8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears
>> to not be fully fixed
>>
>> This also fixes JDK-8259516: Alerts sent by peer may not be received
>> correctly during TLS handshake
>
> Clive Verghese has upd
13 matches
Mail list logo
