Does it matter that they are not in 1.8 FCS? Maybe it depends on the
exact meaning
of @since. Does it refer to the JDK version, or the Java SE version? If
the latter,
then we couldn't put them in these classes at all, which doesn't seem right.
Michael
On 04/06/14 10:12, Chris Hegarty wrote:
Si
Since these APIs are not in 1.8 FCS, is there another way to indicate
what release they were added in?
-Chris.
On 04/06/14 09:51, Michael McMahon wrote:
Hi Deven,
Thanks for pointing that out. I'll see if we can fix it in time for 8u20.
In fact, it should really have the same value in JDK 9 a
Hi Deven,
Thanks for pointing that out. I'll see if we can fix it in time for 8u20.
In fact, it should really have the same value in JDK 9 as well.
Michael
On 03/06/14 08:48, Deven You wrote:
Hi Michael,
I have a small question here. I have roughly gone through the patch
and find several jav
Thanks Alan. Points taken. I'll add the lambda to the 9 version also.
Michael
On 11/04/14 16:04, Alan Bateman wrote:
Reflection or shared secrets is a coin toss here, I think what you
have is okay. An alternative name for the package private class in
java.net is SocketSecrets, just a suggest
Reflection or shared secrets is a coin toss here, I think what you have
is okay. An alternative name for the package private class in java.net
is SocketSecrets, just a suggestion as SocketsUtil sounds more general
that it is.
I agree with Chris on throwing InternalError if any of the reflect
On 11/04/14 10:27, Chris Hegarty wrote:
This looks mainly good to me.
Just a few small comments (mainly on the use of reflection):
1) jdk/net/Sockets.java
You could use a SharedSecret to access the private methods in the
public java.net package, but reflection is ok too.
I think the am
This looks mainly good to me.
Just a few small comments (mainly on the use of reflection):
1) jdk/net/Sockets.java
You could use a SharedSecret to access the private methods in the
public java.net package, but reflection is ok too.
2) If you stick with reflection then if a lookup of any o
Hi,
This is the webrev for the 8u20 version of the fix that was reviewed
yesterday for 9.
JDK
===
http://cr.openjdk.java.net/~michaelm/8036979.8u20/jdk/01/webrev/
Top repo
=
http://cr.openjdk.java.net/~michaelm/8036979.8u20/top/01/webrev/
The good news is that the change is almost the sa
Thanks Alan. All comments accepted, except as clarified below.
Michael
On 09/04/14 15:07, Alan Bateman wrote:
On 08/04/2014 18:49, Michael McMahon wrote:
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, wh
Thanks Chris.
Michael.
On 09/04/14 13:34, Chris Hegarty wrote:
This is a nice addition, and looks very good to me.
Just a few small comments:
1) SocketImpl getOption/setOption need javadoc to describe how they can
throw IOException. Maybe even the same, of similar javdoc to the
socket t
On 08/04/2014 18:49, Michael McMahon wrote:
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, which implements a platform specific
socket option SO_FLOW_SLA (in jdk.net)
There are changes to two repos:
http:
This is a nice addition, and looks very good to me.
Just a few small comments:
1) SocketImpl getOption/setOption need javadoc to describe how they can
throw IOException. Maybe even the same, of similar javdoc to the
socket type equivalent methods?
2) New protected methods in SocketImpl ne
Could I get the following reviewed please?
In addition to providing generic support for java.net.SocketOption,
it also includes 8032808, which implements a platform specific
socket option SO_FLOW_SLA (in jdk.net)
There are changes to two repos:
http://cr.openjdk.java.net/~michaelm/8036979/jdk/0
13 matches
Mail list logo
