April 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

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: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR
by Kumar Srinivasan 03 Sep '16

03 Sep '16

Hi John, This patch contains fixes for two bugs: 8151901: test/tools/pack200/Pack200Test fails on verifying native unpacked JAR 8062335: Pack200 Java implementation differs from C version, outputs unused UTF8 for BootstrapMethods Note: The test case exhibits both of the above. With this the classes produced by java and the native implementation are congruent, though the JDK image's classes exhibit these issues, as a precaution I have extracted the minimal set of classes to reproduce the issues, into the golden jar. The webrev is at: http://cr.openjdk.java.net/~ksrini/8151901/webrev.00/ Thanks Kumar

3 5

Review request for JDK-8145545 : Typos in Javadoc of XmlAdapter
by Abhijit Roy 05 Aug '16

05 Aug '16

Hi all, Please review a fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8145545 Bug - Typos in Javadoc of XmlAdapter Webrev - http://cr.openjdk.java.net/~ntv/ababroy/8145545/webrev.00/ I have just rectified and modified those error. And moving forward it for review. Regards, Abhijit.

3 3

[8u40] RFR 6642881: Improve performance of Class.getClassLoader()
by Coleen Phillimore 30 Jul '16

30 Jul '16

Summary: Add classLoader to java/lang/Class instance for fast access This is a backport request for 8u40. This change has been in the jdk9 code for 3 months without any problems. The JDK changes hg imported cleanly. The Hotspot change needed a hand merge for create_mirror call in klass.cpp. http://cr.openjdk.java.net/~coleenp/6642881_8u40_jdk/ http://cr.openjdk.java.net/~coleenp/6642881_8u40_hotspot/ bug link https://bugs.openjdk.java.net/browse/JDK-6642881 Ran jdk_core jtreg tests in jdk with both jdk/hotspot changes. Also ran jck java_lang tests with only the hotspot change. The hotspot change can be tested separately from the jdk change (but not the other way around). Thanks, Coleen

4 8

RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value
by Joel Borggrén-Franck 26 Jul '16

26 Jul '16

Hi, Can I get a review for this fix and javadoc clarification for https://bugs.openjdk.java.net/browse/JDK-8044629 The problem is with potentially annotated receiver parameters, they only exist for inner class constructors, so this fix makes sure that a ctor is for an inner class or returns null (as for a static method) otherwise. CCC has been approved. Webrev: http://cr.openjdk.java.net/~jfranck/8044629/webrev.00/ cheers /Joel

5 11