Looks good, Jason, just a couple of comments:
- Add an @Deprecated annotation to the package-info.java files since the
entire package is deprecated. Put {@code} around the package/class names.
- add a noreg label to the bug
--Sean
On 03/04/2015 02:02 PM, Jason Uh wrote:
webrev:
On Mar 6, 2015, at 01:55, Mandy Chung mandy.ch...@oracle.com wrote:
For this review request, are you okay with this patch moving policytool and
jarsigner tools to the new home?
Yes.
--Max
webrev: http://cr.openjdk.java.net/~xuelei/8072385/webrev.00/
On 3/4/2015 10:51 PM, Xuelei Fan wrote:
Hi,
Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8072385
In SunJSSE implementation, during endpoint identification, there is a
bug in SubjectAlternativeName
On 05/03/2015 01:13, Mandy Chung wrote:
:
Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/
I think this looks okay. In the unshuffle_list (for back/forward porting
patches)
On 5 Mar 2015, at 08:31, Alan Bateman alan.bate...@oracle.com wrote:
On 05/03/2015 01:13, Mandy Chung wrote:
:
Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/
I think
On 05/03/2015 01:13, Mandy Chung wrote:
3. policytool to jdk.policytool
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074430/webrev.00/
This part looks good to me.
-Alan
On 05/03/2015 01:13, Mandy Chung wrote:
:
2. jar, jarsigner to jdk.jartool
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074429/webrev.00/
It seems reasonable to have both jar and jarsigner in the same module so
I think this is good. This will also work if
On 3/5/2015 12:31 AM, Alan Bateman wrote:
On 05/03/2015 01:13, Mandy Chung wrote:
:
Separate webrevs for each issue:
1. pack200, unpack200 to jdk.pack200
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074428%2b8074429%2b8074430/8074428/webrev.00/
I think this looks okay. In the
Hello Mandy,
The build changes look ok to me.
/Erik
On 2015-03-05 02:13, Mandy Chung wrote:
As listed in an open issue in JEP 200:
The jdk.dev and jdk.runtime modules contain miscellaneous tools that do
not obviously belong to any other module; these modules will eventually
be either renamed
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
If I understand correctly, there should be no warning if a deprecated method
calls another deprecated method. And by deprecating the caller we will get
warnings if they are called by more methods and we can evaluate
What is the policy for deprecating a non-public-API method?
On Mar 6, 2015, at 13:30, Wang Weijun weijun.w...@oracle.com wrote:
Instead of adding @SupressWarnings to a method, can we add @Deprecated to it?
Hi Max,
A couple of these, we probably won't be able to remove in JDK 9. I'm
deprecating getPeerCertificateChain() in the javax.net.ssl.SSLSession
interface in this change, so the implementation in
sun.security.ssl.SSLSessionImpl will have to be suppressed. Also,
X509V1CertImpl will probably
12 matches
Mail list logo
