I approve the latest webrev. But can't-stop-nitpicking Martin would write instead of
+ * The output may be discarded by writing to the operating system specific + * <em>null</em> file. """A typical implementation discards the output by writing to an operating system specific "null file".""" And I'd have a chat with Alan about File#nullSink(). On Tue, Sep 22, 2015 at 6:27 AM, Roger Riggs <roger.ri...@oracle.com> wrote: > Hi Martin, > > Please take another look? > The language has been updated so it does not require discarding using a > file. > > The URI of the webrev changed also: > http://cr.openjdk.java.net/~rriggs/webrev-discard-8132541/ > > Thanks, Roger > > > > > > On 9/22/2015 2:52 AM, Martin Buchholz wrote: > > > > On Mon, Sep 21, 2015 at 11:28 AM, Roger Riggs <roger.ri...@oracle.com> > wrote: > >> Hi Martin, >> >> On 09/21/2015 02:18 PM, Martin Buchholz wrote: >> >> >> I'm not sure that all operating systems where Java may run will have such >> a "null file" (does OS400?). >> >> True, but there are multiple ways to discard the output and it need not >> be via the null file, >> that's just easy on Unix and Windows. >> The Redirect.file() method is allowed to return null and I've updated the >> description to reinforce that for OS's that discard the output some other >> way. >> > > That seems to contradict what I see here: > + /** > + * Indicates that subprocess output will be discarded. > + * The output is discarded by writing to the operating specific > + * <em>null</em> file. > + * > + * <p>It will always be true that > + * <pre> {@code > + * Redirect.DISCARD.file() the filename appropriate for the > operating system && > + * Redirect.DISCARD.type() == Redirect.Type.WRITE && > + * Redirect.DISCARD.append() == false > + * }</pre> > + * @since 9 > + */ > + public static final Redirect DISCARD = new Redirect() { > > I think there will be confusion if the "null file" can be null. > > >
