July 2016 - core-libs-dev

JDK-8067661: transferTo proposal for Appendable
by Patrick Reinhart 15 Nov '17

15 Nov '17

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer. /** * Reads all characters from this readable and writes the characters to * the given appendable in the order that they are read. On return, this * readable will be at end its data. * <p> * This method may block indefinitely reading from the readable, or * writing to the appendable. The behavior for the case where the readable * and/or appendable is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly readable and appendable * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the readable or writing to the * appendable, then it may do so after some characters have been read or * written. Consequently the readable may not be at end of its data and * one, or both participants may be in an inconsistent state. It is strongly * recommended that both readable and appendable be promptly closed * if needed and an I/O error occurs. * * @param out the appendable, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 1.9 */ default long transferTo(Appendable out) throws IOException { .... } -Patrick

5 26

RFR 8145635 : Add TCP_QUICKACK socket option
by vyom 12 Oct '17

12 Oct '17

Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html <http://cr.openjdk.java.net/%7Evtewari/8145635/webrev0.0/index.html> Currently TCP_QUICKACK is only supported on Linux( since Linux 2.4.4) so i implemented is as "ExtendedSocketOption". Thanks, Vyom

5 8

ISO-8859-16 charset/decoder/encoder
by Charles Oliver Nutter 25 Aug '17

25 Aug '17

Again, apologies if this is not the right list. OpenJDK does not currently contain support for encoding/decoding ISO-8859-16. A JRuby user recently reported that they needed this encoding. So, I implemented it. Here's a link to the charset/decoder/encoder in JRuby's repository: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/uti… I tried to follow the general form of the other ISO-8859 charsets, but there's probably more reuse possible (I believe they use sun.nio.cs classes I can't access). Happy to contribute this. Unsure of the process. - Charlie

4 5

Review request 8153912: StackFrame::getFileName and StackFrame::getLineNumber not needed
by Mandy Chung 14 Mar '17

14 Mar '17

Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8153912/webrev.00/index.html StackFrame::getFileName and StackFrame::getLineNumber are originally proposed with the view of any stack walking code can migrate to the StackWalker API without the use of StackTraceElement. File name and line number are useful for debugging and troubleshooting purpose. It has additional overhead to map from a method and BCI to look up the file name and line number. StackFrame::toStackTraceElement method returns StackTraceElement that includes the file name and line number. There is no particular benefit to duplicate getFileName and getLineNumber methods in StackFrame. It is equivalently convenient to call StackFrame.toStackTraceElement().getFileName() (or getLineNumber). This patch proposes to remove StackFrame::getFileName and StackFrame::getLineNumber methods since such information can be obtained from StackFrame.toStackTraceElement(). Mandy

7 45

Proposal: java.lang.reflect.Proxy and default methods
by Peter Levart 03 Mar '17

03 Mar '17

Hi, Since Java SE 8 introduced default methods in interfaces there was a question what to do with java.lang.reflect.Proxy API. Nothing was done to the API at that time, so the default behavior is to proxy default methods too. InvocationHandler gets invoked for default methods, but it has not provision to forward such calls to the default implementations in the interfaces. I propose a simple API addition that allows calling super default methods in proxy instances: http://cr.openjdk.java.net/~plevart/jdk9-dev/Proxy.invokeSuperDefaults/webr… With this addition one can simply decide in the InvocationHandler what to do with invocations to default methods and can forward such invocation to the default implementation: public class Test { interface I1 { default void m() { System.out.println(" default I1.m() called"); } } interface I2 { default void m() { System.out.println(" default I2.m() called"); } } interface I12 extends I1, I2 { @Override void m(); default int sum(int a, int b) { return a + b; } default Object[] concat(Object first, Object... rest) { Object[] result = new Object[1 + rest.length]; result[0] = first; System.arraycopy(rest, 0, result, 1, rest.length); return result; } } public static void main(String[] args) { InvocationHandler h = (proxy, method, params) -> { System.out.println("\nInvocationHandler called for: " + method + " with parameters: " + Arrays.toString(params)); if (method.isDefault()) { try { return Proxy.invokeSuper(proxy, method, params); } catch (InvocationTargetException e) { throw e.getCause(); } } else { switch (method.getName()) { case "m": System.out.println(" abstract I12.m(): called"); return null; default: throw new UnsupportedOperationException( "Unsupported method: " + method); } } }; I1 i1 = (I1) Proxy.newProxyInstance( I1.class.getClassLoader(), new Class<?>[]{I1.class}, h); i1.m(); I2 i2 = (I2) Proxy.newProxyInstance( I2.class.getClassLoader(), new Class<?>[]{I2.class}, h); i2.m(); I12 i12 = (I12) Proxy.newProxyInstance( I12.class.getClassLoader(), new Class<?>[]{I12.class}, h); i12.m(); System.out.println(" 1 + 2 = " + i12.sum(1, 2)); System.out.println(" [1] concat [2, 3, 4] = " + Arrays.toString(i12.concat(1, 2, 3, 4))); } } I know FC date is over, but this is really a small change and I have heard several people that such feature is missing from the Proxy API. I'm prepared to create jtreg tests covering the specification if this proposal is accepted. Regards, Peter

7 11

Reading subprocess stdout susceptible to deadlock
by Vitaly Davidovich 23 Jan '17

23 Jan '17

Hi, It seems that doing a blocking read on a subprocess's stdout can lead to deadlock between the thread doing the read and the process reaper thread. The deadlock occurs because the reader is synchronized on the ProcessPipeInputStream, blocks for more data to consume, and process reaper comes along trying to call processExited, which also synchronizes on the same PPIS. The reader appears stuck because it's not seeing the EOF due to process reaper not being able to close the stream. I couldn't find any existing reports of this via quick search, which makes me wonder if I'm missing something. Is this a known issue? Thanks -- Sent from my phone

2 4

Unexpected BindException in Endpoint.publish
by KUBOTA Yuji 05 Dec '16

05 Dec '16

Hi Miroslav and all, Could you please review the below issue and patch? I got the advice by Alan at net-dev. So I want to ask you. http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html ---- I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK community. This's second times from JavaOne14. :) We find an unexpected exception in JAX-WS, so I write a patch to fix it. We think that this issue may block the migration to JDK9 from JDK7. If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the following test code, JDK9 (and JDK8) returns "java.net.BindException: Address already in use.” as the below. But JDK7 does NOT return the exception. - Test code for reproduce --- import javax.jws.*; import javax.xml.ws.*; public class WSTest{ @WebService public static class Method1{ @WebMethod public String getMethod1Value(){ return "from Method1"; } } @WebService public static class Method2{ @WebMethod public String getMethod2Value(){ return "from Method2"; } } public static void main(String[] args) throws Exception{ Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1", new Method1()); Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2", new Method2()); System.out.println("Sleep 3 secs..."); Thread.sleep(3000); endPoint2.stop(); endPoint1.stop(); } } --- - StackTrace --- Exception in thread "main" com.sun.xml.internal.ws.server.ServerRtException: Server Runtime Error: java.net.BindException: Address already in use at com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) at com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) at com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) at com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) at javax.xml.ws.Endpoint.publish(Endpoint.java:240) at wstest.WSTest.main(WSTest.java:27) Caused by: java.net.BindException: Address already in use at sun.nio.ch.Net.bind0(Native Method) at sun.nio.ch.Net.bind(Net.java:432) at sun.nio.ch.Net.bind(Net.java:424) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) at sun.net.httpserver.ServerImpl.<init>(ServerImpl.java:102) at sun.net.httpserver.HttpServerImpl.<init>(HttpServerImpl.java:50) at sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) at com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) ... 5 more ----- To publishes the Endpoint, JAX-WS checks whether the HttpContext has been created by given address, then creates a HttpContext if do not exist. If we sets 0.0.0.0 as given address, JAX-WS checks by ServerSocket#getLocalSocketAddress() (server local address), so returns BindException when 0.0.0.0 has been blinded already. Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think about above situation. And JAX_WS-941 does not back port to JDK7. So I write a patch which is based jdk9/dev/jaxws (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. Please review this patch :) [1]: https://java.net/jira/browse/JAX_WS-941 - Patch --- diff -r 2d84c6f4cbba src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java --- a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Thu Oct 22 08:47:47 2015 -0700 +++ b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java Tue Oct 27 19:48:35 2015 +0900 @@ -38,6 +38,7 @@ import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.logging.Logger; +import java.util.Optional; /** * Manages all the WebService HTTP servers created by JAXWS runtime. @@ -81,24 +82,38 @@ synchronized(servers) { state = servers.get(inetAddress); if (state == null) { - logger.fine("Creating new HTTP Server at "+inetAddress); - // Creates server with default socket backlog - server = HttpServer.create(inetAddress, 0); - server.setExecutor(Executors.newCachedThreadPool()); - String path = url.toURI().getPath(); - logger.fine("Creating HTTP Context at = "+path); - HttpContext context = server.createContext(path); - server.start(); + final int finalPortNum = port; + Optional<ServerState> stateOpt = + servers.values() + .stream() + .filter(s -> s.getServer() + .getAddress() + .getPort() == finalPortNum) + .findAny(); - // we have to get actual inetAddress from server, which can differ from the original in some cases. - // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, - // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address - inetAddress = server.getAddress(); + if (inetAddress.getAddress().isAnyLocalAddress() && + stateOpt.isPresent()) { + state = stateOpt.get(); + } else { + logger.fine("Creating new HTTP Server at "+inetAddress); + // Creates server with default socket backlog + server = HttpServer.create(inetAddress, 0); + server.setExecutor(Executors.newCachedThreadPool()); + String path = url.toURI().getPath(); + logger.fine("Creating HTTP Context at = "+path); + HttpContext context = server.createContext(path); + server.start(); - logger.fine("HTTP server started = "+inetAddress); - state = new ServerState(server, path); - servers.put(inetAddress, state); - return context; + // we have to get actual inetAddress from server, which can differ from the original in some cases. + // e.g. A port number of zero will let the system pick up an ephemeral port in a bind operation, + // or IP: 0.0.0.0 - which is used to monitor network traffic from any valid IP address + inetAddress = server.getAddress(); + + logger.fine("HTTP server started = "+inetAddress); + state = new ServerState(server, path); + servers.put(inetAddress, state); + return context; + } } } server = state.getServer(); --- Thanks, Yuji

3 7

RFR 8158880: java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java fail with zh_CN locale
by Bhanu Gopularam 21 Nov '16

21 Nov '16

Hi all, May I request you to review fix for following issue Bug id: https://bugs.openjdk.java.net/browse/JDK-8158880 Solution: To avoid test failure in non english locales, set the default locale while initial test setup Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8158880/webrev.00/ Thanks, Bhanu

4 8

RFR 9: JEP 290: Filter Incoming Serialization Data
by Roger Riggs 03 Oct '16

03 Oct '16

Please review the design, implementation, and tests of JEP 290: Filter Incoming Serialization Data[1] It allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. The JEP[1] has more detail on the background and scope. The core mechanism is a filter interface implemented by serialization clients and set on an |ObjectInputStream|. The filter is called during the deserialization process to validate the classes being deserialized, the sizes of arrays being created, and metrics describing stream length, stream depth, and number of references as the stream is being decoded. A process-wide filter can be configured that is applied to every ObjectInputStream. The API of ObjectInputStream can be used to set a custom filter to supersede or augment the process-wide filter. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serial-filter-jdk9-8155760/ SpecDiff: http://cr.openjdk.java.net/~rriggs/filter-diffs/overview-summary.html Javadoc (subset) http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputStream… http://cr.openjdk.java.net/~rriggs/filter-javadoc/java/io/ObjectInputFilter… Comments appreciated, Roger [1] JEP 290: https://bugs.openjdk.java.net/browse/JDK-8154961

8 36

RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code
by Seán Coffey 22 Sep '16

22 Sep '16

Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html -- Regards, Sean.

4 14