Re: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output to file should work with long file names (win)
Hi Thomas,
Conventionally, File.deleteOnExit is used for file cleanup in the test.
An unexpected exception could leave the file around. An alternative is to
use try {...} finally {file.delete};
Fixed file names can sometime cause issues if they are left around by
previous test runs or with a concurrent run of the same test on the same
system. Can File.createTempFile be used with a suitably long prefix or
suffix?
It would ensure a unique file name.
The rest looks good.
Thanks, Roger
On 2/9/15 8:30 AM, Thomas Stüfe wrote:
Hi all,
please review this small change at your convenience:
http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/
It fixes a small issue which causes ProcessBuilder not to be able to open
files to redirect into (when using Redirect.append) on windows, if that
file name is longer than 255 chars.
Kind Regards, Thomas Stuefe
Re: JEP 102 Process Updates revised API draft
Hi David, On 2/9/15 6:44 PM, David M. Lloyd wrote: On 02/09/2015 05:25 PM, Roger Riggs wrote: Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the security model validated. Both Processes and ProcessHandles can be monitored using CompletableFuture for termination and to trigger additional actions on Process exit. Information about processes includes the total cputime, starttime, user, executable, and arguments. Please review and comment: http://cr.openjdk.java.net/~rriggs/ph-apidraft/ Great, I'm glad to see this come to fruition. I have a couple minor questions though. ProcessHandle.Info provides a startTime and totalTime. But it seems odd and inconsistent that startTime is an Instant, yet totalTime is a raw long as opposed to the arguably more consistent Duration. Is there a reason you went with a raw long for this property? I considered a Duration, but Duration is a relative time; it make senses to add it to an absolute time to come up with another absolute time. But it didn't seem completely correct since CPU time is not accumulated continuously. For ease in formatting, Duration.ofNanos(nn) can be used. I'm open to suggestions. Also, as a general comment, there isn't really a good explanation as to what the difference is between a normal destroy and a forcible destroy. Given that you've added an isDestroyForcible() method, I think it might be a good idea to explain what it means when this method returns true. There must be some criteria in the implementation to return true here, so at the least, that criteria should be explained. Also the destroy() method now has the odd characteristic that its implementation *may* forcibly destroy a process, but you can't really determine that from the API at all. From an implementation perspective, for Unix it is the distinction between SIGTERM and SIGKILL; one is allowed/expected to be caught and handled by the application for a clean shutdown, the other is not interceptable. But the OS variations and caveats make it hard to write anything more than an informative statement. The descriptions are copied from Process, which previously did not offer an explanation. Thanks, Roger
Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module
Thank you Roger! Yes, please sponsor this. Thanks, Amy On 2/10/15 9:55 AM, Roger Riggs wrote: Hi Amy, Looks fine to me; If no one already volunteered to sponsor, I can. Roger On 2/9/15 8:20 PM, Amy Lu wrote: Kindly reminder ... On 1/29/15 11:09 AM, Amy Lu wrote: I updated the webrev, suppress deprecation warnings for jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered. Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/ Thanks, Amy On 1/19/15 2:31 PM, Amy Lu wrote: Please review these changes to address a few stray deprecation warnings in the jdk.rmic module: JDK-8069255: Suppress deprecation warnings in jdk.rmic module http://cr.openjdk.java.net/~amlu/8069255/webrev.00/ I also need a sponsor for this. Thanks, Amy
Re: RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output to file should work with long file names (win)
Hi Thomas, the change looks good and I can sponsor it once it is reviewed. Just some small notes: - it seems that getPath() isn't used anywhere else in ProcessImpl_md.c and because it is static it can't be used anywhere else. So can you please remove it completely. - io_util_md.h has a list of files which use the prototypes like pathToNTPath before the declaration of the prototypes. Could you please also add ProcessImpl_md.c to this list - can you pleae place the new include in ProcessImpl_md.c as follows: #include io_util.h +#include io_util_md.h #include windows.h #include io.h I saw that system and local headers are already intermixed in that file but at I think at least we shouldn't introduce more disorder. - is robocopy really available on all supported Windows system. In http://en.wikipedia.org/wiki/Robocopy I read that it was introduced in Server 2008. I just verified that Java 8 only supports Server 2008 and above but just think of our internal test system:) Maybe we can use a program which is supported in every Windows version? Regards, Volker On Mon, Feb 9, 2015 at 2:30 PM, Thomas Stüfe thomas.stu...@gmail.com wrote: Hi all, please review this small change at your convenience: http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/ It fixes a small issue which causes ProcessBuilder not to be able to open files to redirect into (when using Redirect.append) on windows, if that file name is longer than 255 chars. Kind Regards, Thomas Stuefe
Re: FilePermission Canonical path optimization
It sounds to me like we need additional means to protect the file permission without canocialization. I am looking forward to seeing the new proposal with appropriate solution for problem Peter raised. Thanks a lot! 2015-02-09 14:50 GMT+08:00 Wang Weijun weijun.w...@oracle.com: On Feb 9, 2015, at 14:42, Peter Levart peter.lev...@gmail.com wrote: Hi Max, Of course you are aware that by trusting the symlinks, you potentially give much more permission than you would hope to. Suppose that some code has permission to read and write into a particular directory (for temporary files). With this permission the code can actually read and/or write any file in the filesystem that OS grants access to the java process. Merely by creating a symlink in the read/write-able directory and accessing the file through it. That's why Apache HTTP Server by default disables FollowSymLinks option. Yes, we will be careful. In Java, a LinkPermission is needed to create a link. Of course, there might be other (existing) symlinks created by other non-Java processes. We will evaluate this possibility. Thanks Max
Re: JEP 102 Process Updates revised API draft
On 9 February 2015 at 23:44, David M. Lloyd david.ll...@redhat.com wrote: ProcessHandle.Info provides a startTime and totalTime. But it seems odd and inconsistent that startTime is an Instant, yet totalTime is a raw long as opposed to the arguably more consistent Duration. Is there a reason you went with a raw long for this property? I think using Duration would be OK here, even though the CPU time was used up in a discontinuous manner. The returned value is, in essence, a sum of many smaller durations. I'd also suggest adjusting the two method names: startTime() - startInstant() totalTime() - totalCpuDuration() Those communicate the intent more clearly IMO. Stephen
RFR 8068587: ScriptEngineFactory.getParameter() should specify NPE for a null key
Please review http://cr.openjdk.java.net/~sundar/8068587/ for https://bugs.openjdk.java.net/browse/JDK-8068587 Thanks, -Sundar
Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module
Hi Amy, Looks fine to me; If no one already volunteered to sponsor, I can. Roger On 2/9/15 8:20 PM, Amy Lu wrote: Kindly reminder ... On 1/29/15 11:09 AM, Amy Lu wrote: I updated the webrev, suppress deprecation warnings for jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered. Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/ Thanks, Amy On 1/19/15 2:31 PM, Amy Lu wrote: Please review these changes to address a few stray deprecation warnings in the jdk.rmic module: JDK-8069255: Suppress deprecation warnings in jdk.rmic module http://cr.openjdk.java.net/~amlu/8069255/webrev.00/ I also need a sponsor for this. Thanks, Amy
Re: RFR: JDK-8068682 - Deprivilege/move java.corba to the ext class loader
On 08/02/2015 06:58, Mandy Chung wrote: : Mark's patch is first to move it out from the boot loader to the ext class loader. Identifying the permissions required by corba requires more effort and not straight-forward. So it's granted with AllPermissions for now and reduce the permission set in the future. Just to add to Mandy's comment then another motive for this move is to make it easier to support the concept of upgradable modules that it cited in JEP 220. As part of JEP 220 then we have removed the legacy endorsed-standards override mechanism and the proposal is to bring in a new mechanism that allows app servers and others to override the version of the EE modules that are in Java SE. One module that needs to move is the java.transaction module but to get there requires moving the java.corba module first. -Alan.
Re: RFR 8071479: Stream and lamdification improvements to j.u.regex.Matcher
Here is an alternative that pushes the methods on to Pattern instead: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/on-Pattern/webrev/ (Whe webrev reports some files as empty, please ingore those, i have this webrev stacked on the previous one.) I have also included replaceFirst. This simplifies things for streaming on the match results and also for replacing. Note that the existing replace* methods on Matcher reset the matcher before matching and indicate that the matcher should be reset afterwards for reuse. Thus there is no loss in functionality moving such lambda accepting methods from Matcher to Pattern. It comes down to the performance of reusing a matcher, which does not seems so compelling to me. Paul. On Feb 5, 2015, at 11:59 AM, Paul Sandoz paul.san...@oracle.com wrote: Hi. Please review these stream/lambda enhancements on Matcher: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071479--Matcher-stream-results/webrev/ Two new methods are added to Matcher: 1) replaceAll(FunctionMatchResult, String ) that is more flexible than the existing replaceAll that accepts a single value. 2) StreamMatchResult results() that returns a stream of MatchResult for all matches. The former does introduce a minor source incompatibility for a null argument, but then so did the new append methods accepting StringBuilder that were recently added (see JDK-8039124). For the latter i opted to place the method on Matcher rather than Pattern as i think that is a better fit with current usages of Matcher and operating on a MatchResult. That marginally increases the complexity since co-modification checking is required. I update the test PatternStreamTest to derive the expected result. I suppose i could add another method replaceFirst(FunctionMatchResult, String ) if anyone feels strongly about that. Consistency-wise it seems the right thing to do. Paul.
RFR(XS): 8072770: [TESTBUG] Some Introspector tests fail with a Java heap bigger than 4GB
Hi,
the three Introspector test:
java/beans/Introspector/7064279/Test7064279.java
java/beans/Introspector/Test7172865.java
java/beans/Introspector/Test7195106.java
provoke an OutOfMemory situation by repeatedly allocating constantly
growing arrays with the following loop:
int[] array = new int[1024];
while (true) {
array = new int[array.length 1];
}
However if we're running on a machine with plenty of RAM the default
Java heap will be bigger than ~4GB and we will get a
NegativeArraySizeException instead of an OutOfMemoryError because the
array length which is a signed int will wrap around and become
negative.
The fix is easy - just specify a concrete -Xmx value for the test:
http://cr.openjdk.java.net/~simonis/webrevs/2015/8072770/
https://bugs.openjdk.java.net/browse/JDK-8072770
Thank you and best regards,
Volker
RFR (xs): JDK-8072611: (process) ProcessBuilder redirecting output to file should work with long file names (win)
Hi all, please review this small change at your convenience: http://cr.openjdk.java.net/~stuefe/webrevs/8072611/webrev.01/webrev/ It fixes a small issue which causes ProcessBuilder not to be able to open files to redirect into (when using Redirect.append) on windows, if that file name is longer than 255 chars. Kind Regards, Thomas Stuefe
Re: JEP 102 Process Updates revised API draft
On 02/09/2015 05:25 PM, Roger Riggs wrote: Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the security model validated. Both Processes and ProcessHandles can be monitored using CompletableFuture for termination and to trigger additional actions on Process exit. Information about processes includes the total cputime, starttime, user, executable, and arguments. Please review and comment: http://cr.openjdk.java.net/~rriggs/ph-apidraft/ Great, I'm glad to see this come to fruition. I have a couple minor questions though. ProcessHandle.Info provides a startTime and totalTime. But it seems odd and inconsistent that startTime is an Instant, yet totalTime is a raw long as opposed to the arguably more consistent Duration. Is there a reason you went with a raw long for this property? Also, as a general comment, there isn't really a good explanation as to what the difference is between a normal destroy and a forcible destroy. Given that you've added an isDestroyForcible() method, I think it might be a good idea to explain what it means when this method returns true. There must be some criteria in the implementation to return true here, so at the least, that criteria should be explained. Also the destroy() method now has the odd characteristic that its implementation *may* forcibly destroy a process, but you can't really determine that from the API at all. -- - DML
Re: JDK 9 RFR of JDK-8041395: Doclint regression in java.net.SocketOption
looks fine joe
best
lance
On Feb 9, 2015, at 6:27 PM, joe darcy joe.da...@oracle.com wrote:
Hello,
Please review these straightforward changes to address some doclint issues in
java.net:
JDK-8041395: Doclint regression in java.net.SocketOption
http://cr.openjdk.java.net/~darcy/8041395.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/net/DatagramSocket.java 2015-02-09
15:19:25.407396706 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocket.java 2015-02-09
15:19:25.223399019 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -1308,6 +1308,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code null}
* may be valid for some options.
@@ -1342,6 +1343,7 @@
/**
* Returns the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/DatagramSocketImpl.java
2015-02-09 15:19:25.855391074 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocketImpl.java
2015-02-09 15:19:25.695393086 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -267,6 +267,7 @@
/**
* Called to set a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @param value The value of the socket option. A value of {@code null}
@@ -276,7 +277,7 @@
* support the option
*
* @throws NullPointerException if name is {@code null}
- *
+ * @throws IOException if an I/O problem occurs while attempting to set
the option
* @since 1.9
*/
protected T void setOption(SocketOptionT name, T value) throws
IOException {
@@ -308,12 +309,15 @@
/**
* Called to get a socket option.
*
+ * @return the socket option
+ * @param T The type of the socket option value
* @param name The socket option
*
* @throws UnsupportedOperationException if the DatagramSocketImpl does
not
* support the option
*
* @throws NullPointerException if name is {@code null}
+ * @throws IOException if an I/O problem occurs while attempting to set
the option
*
* @since 1.9
*/
--- old/src/java.base/share/classes/java/net/ServerSocket.java 2015-02-09
15:19:26.303385442 -0800
+++ new/src/java.base/share/classes/java/net/ServerSocket.java 2015-02-09
15:19:26.131387604 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -924,6 +924,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code null}
* may be valid for some options.
@@ -957,6 +958,7 @@
/**
* Returns the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/Socket.java 2015-02-09
15:19:26.739379961 -0800
+++ new/src/java.base/share/classes/java/net/Socket.java 2015-02-09
15:19:26.579381972 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -1727,6 +1727,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code null}
* may be valid for some options.
@@ -1758,6
JEP 102 Process Updates revised API draft
Hi, After a protracted absence from working on JEP 102, the updated API draft provides access to process hierarchies and individual process information; as permitted by the OS. The relationship between Process and ProcessHandle is clarified and the security model validated. Both Processes and ProcessHandles can be monitored using CompletableFuture for termination and to trigger additional actions on Process exit. Information about processes includes the total cputime, starttime, user, executable, and arguments. Please review and comment: http://cr.openjdk.java.net/~rriggs/ph-apidraft/ Thanks, Roger
JDK 9 RFR of JDK-8041395: Doclint regression in java.net.SocketOption
Hello,
Please review these straightforward changes to address some doclint
issues in java.net:
JDK-8041395: Doclint regression in java.net.SocketOption
http://cr.openjdk.java.net/~darcy/8041395.0/
Patch below.
Thanks,
-Joe
--- old/src/java.base/share/classes/java/net/DatagramSocket.java
2015-02-09 15:19:25.407396706 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocket.java
2015-02-09 15:19:25.223399019 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -1308,6 +1308,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code
null}
* may be valid for some options.
@@ -1342,6 +1343,7 @@
/**
* Returns the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/DatagramSocketImpl.java
2015-02-09 15:19:25.855391074 -0800
+++ new/src/java.base/share/classes/java/net/DatagramSocketImpl.java
2015-02-09 15:19:25.695393086 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1996, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -267,6 +267,7 @@
/**
* Called to set a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @param value The value of the socket option. A value of {@code
null}
@@ -276,7 +277,7 @@
* support the option
*
* @throws NullPointerException if name is {@code null}
- *
+ * @throws IOException if an I/O problem occurs while attempting to
set the option
* @since 1.9
*/
protected T void setOption(SocketOptionT name, T value) throws
IOException {
@@ -308,12 +309,15 @@
/**
* Called to get a socket option.
*
+ * @return the socket option
+ * @param T The type of the socket option value
* @param name The socket option
*
* @throws UnsupportedOperationException if the DatagramSocketImpl
does not
* support the option
*
* @throws NullPointerException if name is {@code null}
+ * @throws IOException if an I/O problem occurs while attempting to
set the option
*
* @since 1.9
*/
--- old/src/java.base/share/classes/java/net/ServerSocket.java
2015-02-09 15:19:26.303385442 -0800
+++ new/src/java.base/share/classes/java/net/ServerSocket.java
2015-02-09 15:19:26.131387604 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -924,6 +924,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code
null}
* may be valid for some options.
@@ -957,6 +958,7 @@
/**
* Returns the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
*
* @return The value of the socket option.
--- old/src/java.base/share/classes/java/net/Socket.java 2015-02-09
15:19:26.739379961 -0800
+++ new/src/java.base/share/classes/java/net/Socket.java 2015-02-09
15:19:26.579381972 -0800
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 1995, 2013, Oracle and/or its affiliates. All rights
reserved.
+ * Copyright (c) 1995, 2015, Oracle and/or its affiliates. All rights
reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
@@ -1727,6 +1727,7 @@
/**
* Sets the value of a socket option.
*
+ * @param T The type of the socket option value
* @param name The socket option
* @param value The value of the socket option. A value of {@code
null}
* may be valid for some options.
@@ -1758,6 +1759,7 @@
/**
* Returns the value of a socket option.
*
+ * @param T The type of the socket option value
* @param
Re: RFR 8064924: Update java.net.URL to work with modules
Thank you for the comments Alan. On 06/02/15 10:20, Alan Bateman wrote: On 04/02/2015 15:11, Chris Hegarty wrote: Agreed. Updated in-place http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html I think the approach and naming is good. A few small comments on the wording: 1. used to locate URLStreamHandlerProvider providers - the wording hints as further redirection, maybe it would be better as URLStreamHandlerProvider implementations. Updated. ( result of previous refactoring ) 2. the ordering that providers are located - maybe this should be the order that providers are located. Updated. Thanks 3. Some protocol, that are fundamental Here's a re-worded statement to consider: Some protocol handlers, for example those used for loading platform classes or classes on the class path, may not be overridden. The details of such restrictions, and when those restrictions apply (during initialization of the runtime for example), are implementation specific and therefore not specified. This is better. Updated. One other thing in this area is setURLStreamHandlerFactory(null). Long standing behavior is to remove the system-wide URLStreamHandlerFactory, should this continue? setURLStreamHandlerFactory can be called many times with 'null', but once it is called with a non-null arg then it can never be called again ( it will throw ). What I found was that code setting the pkg prefix property would call setURLStreamHandlerFactory(null) to clear the protocol handlers cache, and subsequent lookups would then consult the updated property. This is really only interesting if you plan to override existing protocols, and appears benign. I have not changed this in the latest webrev. It seems like a corner case, and could be argued either way. The spec is less than clear about the expected behavior of this method when you pass it null. Updated webrev [ spec and implementation] : http://cr.openjdk.java.net/~chegar/8064924/04/ Regarding jaxws, I suspect that I can simply reverse the changes in the webrev, and do nothing. Running on pre-JDK9 the property will continue to be set and used, on JDK9 and later the property will be set but ignored. I don't see that it is necessary anyway. Looks like technical debt. I'll file a separate issue for Miran to follow up and verify this. -Chris. -Alan
Re: JDK 9 RFR of JDK-8069255: Suppress deprecation warnings in jdk.rmic module
Kindly reminder ... On 1/29/15 11:09 AM, Amy Lu wrote: I updated the webrev, suppress deprecation warnings for jdk/src/jdk.rmic/share/classes/sun/tools/java/* now also covered. Please review: http://cr.openjdk.java.net/~amlu/8069255/webrev.01/ Thanks, Amy On 1/19/15 2:31 PM, Amy Lu wrote: Please review these changes to address a few stray deprecation warnings in the jdk.rmic module: JDK-8069255: Suppress deprecation warnings in jdk.rmic module http://cr.openjdk.java.net/~amlu/8069255/webrev.00/ I also need a sponsor for this. Thanks, Amy
