July 2015 - core-libs-dev

ProcessBuilder support for pipelines
by Roger Riggs 29 Jul '15

29 Jul '15

On most operating systems, creating pipelines of processes is simple and direct. That same function is missing from the Java Process support and can be provided by java.lang.ProcessBuilder by enabling the pipes created for stdout to be used for standard input when the processes are created. Comments and feedback are appreciated on the prototype API and implementation. Javadoc: java.lang.ProcessBuilder.startPipe: http://cr.openjdk.java.net/~rriggs/pipedoc/java/lang/ProcessBuilder.html#st… webrev prototype: http://cr.openjdk.java.net/~rriggs//webrev-pipeline-8132394 Thanks, Roger

5 7

RFR: JDK-8066013 (prefs) Unused variable in src/java.prefs/share/classes/java/util/prefs/MacOSXPreferences.java
by Steve Drach 29 Jul '15

29 Jul '15

Hello, Please review the fix for JDK-8066013, removing two unused variables from MacOSXPreferences.java. https://bugs.openjdk.java.net/browse/JDK-8066013 <https://bugs.openjdk.java.net/browse/JDK-8066013> http://slc01hfj.us.oracle.com/webrevs/JDK-8066013/webrev/index.html <http://slc01hfj.us.oracle.com/webrevs/JDK-8066013/webrev/index.html> An internal review has been completed. Thanks, Steve

3 2

RFR(s): 8132206: move ScanTest.java into OpenJDK
by Stuart Marks 29 Jul '15

29 Jul '15

Hi all, Please review this small change to add a test for java.util.Scanner into OpenJDK. This test was inadvertently omitted from OpenJDK when the regression tests were migrated into the open. Bug: https://bugs.openjdk.java.net/browse/JDK-8132206 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8132206/webrev.0/ s'marks

3 2

RFR(XS): 8132475 : The commands in the modular images are executable by the owner only (once again)
by Volker Simonis 29 Jul '15

29 Jul '15

Hi, could you please review this tiny change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132475/ https://bugs.openjdk.java.net/browse/JDK-8132475 After "8080511: Refresh of jimage support" the executable commands in jdk/bin and jre/bin are only executable by the file owner. This means that only the user who built the images can execute the programs. The fix is trivial, but I've also added a test now so this won't happen a third time :) Thank you and best regards, Volker

3 3

SelectableChannels and Process API
by Peter Levart 28 Jul '15

28 Jul '15

Hi Roger, So I started new thread... On 04/14/2015 11:33 PM, Roger Riggs wrote: > > On 4/14/2015 11:47 AM, Peter Levart wrote: >> I have been thinking of another small Process API update. Some people >> find it odd how redirected in/out/err streams are exposed: >> >> http://blog.headius.com/2013/06/the-pain-of-broken-subprocess.html > yep, I've read that several times. To be fair, it's mostly, but not entirely correct. The part that says: " So when the child process exits, the any data waiting to be read from its output stream is drained into a buffer. All of it. In memory. Did you launch a process that writes a gigabyte of data to its output stream and then terminates? Well, friend, I sure hope you have a gigabyte of memory, because the JDK is going to read that sucker in and there's nothing you can do about it. And let's hope there's not more than 2GB of data, since this code basically just grows a byte[], which in Java can only grow to 2GB. If there's more than 2GB of data on that stream, this logic errors out and the data is lost forever." ...is exaggeration. This does not happen as the pipe has a bounded buffer. When subprocess exits, there is at most that much data left in the buffer (64k typically) and only that much is sucked into the Java process and the underlying handle closed. >> >> They basically don't like: >> >> - that exposed Input/Output streams are buffered >> - that underlying streams are File(Input/Output)Streams which, >> although the backing OS implementation are not files but pipes, don't >> expose selectable channels so that non-blocking event-based IO could >> be performed on them. >> - that exposed IO streams are automatically "managed" in UNIX >> variants of ProcessImpl which needs subtle "hacks" to do it in a >> perceptively transparent way (delayed close, draining input on exit >> and making it available after the underlying handle is already >> closed, ...) >> >> So I've been playing with the idea of exposing the "real" pipe >> channels in last couple of days. Here's the prototype I came up with: >> >> http://cr.openjdk.java.net/~plevart/jdk9-sandbox/JDK-8046092-branch/Process… >> >> >> This adds new Redirect type to the API and 3 new methods to Process >> that return Pipe channels when this new Redirect type is used. It's >> interesting that no native code changes were necessary. The behavior >> of pipes on Windows is a little different (perhaps because the Pipe >> NIO API uses sockets under the hood on Windows - why is that? Windows >> does have a pipe equivalent). What bothers me is that file handles >> opened on files (when redirecting to/from File) can be closed as soon >> as the subprocess is started and the subprocess is still able to >> read/write from the files (like with UNIX). It's not the same with >> pipe (i.e. socket) handles on Windows. They must be closed only after >> subprocess exits. >> >> If this subtle difference between file handles and socket handles on >> Windows could be dealt with (perhaps some options exist that affect >> subprocess spawning), then the extra waiting thread would not be >> needed on Windows. >> >> So what do you think of this API update? > Definitely worthy of a separate thread. It looks promising and > addresses some of the issues > raised, while moving other problems from the implementation to the > application. > Such as closing of the channels and cleanup. I worry about how the > resources are freed > if the code spawning the app doesn't do the cleanup. Will it require > hooks (like a finalizer) > to do the cleanup? > Also, it doesn't help with Martin's goal of being able to implement > emacs in Java since it doesn't provide pty control. > As you are aware the complexity in Process is to ensure a timely > cleanup and > allowing the Process to terminate and release the process resources > when it was done and not having to wait for the stdout/stderr consumer. I wonder how this automatic stream cleanup really helps in real-world programs. It doesn't help the Process to terminate and release the process resources any sooner as the process terminates on it's own (unless killed) and OS releases it's resources without the outside help anyway. Draining and closing the stream after the process has already exited just releases one file handle (the consuming side of the pipe) in a promptly manner. This could be left to the user and/or finalizer. Draining after the process has already exited does not help the process to exit any sooner as it happens after the fact. A program that doesn't consume the stream can cause the process to hang forever as the pipe's buffer is bounded (64k typically). So draining and closing after the process has exited only potentially helps for the last 64k of the stream and only to release one file handle in a potentially more timely manner. OTOH now that ProcessImpl for UNIX does that (and why does Windows implementation not do that?) sloppy programs might exist that would potentially break if the status quo is not maintained. But new functionality need not be so permissive. I'll take a look at how and if Channel(s) do any kind of automatic cleanup based on reachability and whether this can be bolted on for Process use. I doubt it is possible to drain and close a Channel without disturbing the ongoing Selector IO processing... Regards, Peter > > Thanks, Roger > >

3 6

RfR - 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
by Daniel Fuchs 28 Jul '15

28 Jul '15

Hi, Please find below a fix for yet another cleanup for jaxp: 8130059: jaxp: Investigate removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java https://bugs.openjdk.java.net/browse/JDK-8130059 http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/ EnvironmentCheck doesn't seem to serve any purpose in JDK 9. It is not called anywhere. The proposal is to remove it. By doing a full grep on the JDK I also identified another unused class (Hashtree2Node.java) which referred to EnvironmentCheck inside a comment. I took the liberty to remove that class as well. As for the latter cleanup, what triggered this is that EnvironmentCheck is using sun.boot.class.path... best regards, -- daniel

2 3

One more minor addition to ProcessBuilder
by David M. Lloyd 28 Jul '15

28 Jul '15

Roger & co.: Since you're already on the topic of manipulating pipes, I thought I'd mention one very small yet very useful potential enhancement. It would be very handy to be able to specify a NULL/bit-bucket source/destination for pipes. For the target process' input, the user can generally (I believe) just close the stream, but for output, there isn't really a good option. While this is possible to achieve by redirecting to /dev/null on UNIX-likes and NUL (iirc) on Windows, having to do platform detection to decide where this device is seems overly cumbersome. Having a ProcessBuilder.Redirect#DISCARD or similar would be quite useful, and should be fairly straightforward I think. -- - DML

4 3

References to non-existing methods in java.util.stream comments
by Tagir F. Valeev 28 Jul '15

28 Jul '15

Hello! Although it's not the part of public API, there are references to non-existing methods in SliceOps.java and Streams.java: http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/sha… // @@@ OOMEs will occur for LongStream.longs().filter(i -> true).limit(n) http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/sha… * <p>This is optimized for cases such as LongStream.longs() that is ... There's no method like LongStream.longs(). http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/sha… * <p>This is optimized for cases such as IntStream.ints() that is ... There's no method like IntStream.ints(). Probably these comments should be changed to avoid confusion. With best regards, Tagir Valeev.

2 1

FYI - fix for JDK-8062849 -- Optimize EnumMap.equals
by Steve Drach 28 Jul '15

28 Jul '15

Hi, I’ve fixed the issue reported in https://bugs.openjdk.java.net/browse/JDK-8062849 <https://bugs.openjdk.java.net/browse/JDK-8062849>. It’s been reviewed by Brent Christian and Paul Sandoz. Both the changeset and webrev.zip are attached. Steve

3 3

RFR(XS): 8132374: AIX: fix value of os.version property
by Volker Simonis 27 Jul '15

27 Jul '15

Hi, can somebody please review this tiny fix to get the value of the 'os.version' property correct on AIX: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/ https://bugs.openjdk.java.net/browse/JDK-8132374 Thank you and best regards, Volker

3 5