February 2017 - 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. * * 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 asynchronously closed, or the thread * interrupted during the transfer, is highly readable and appendable * specific, and therefore not specified. * * 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

8169425: Values computed by a ClassValue should not strongly reference the ClassValue
by Paul Sandoz 11 May '17

11 May '17

Hi, Please review the addition of an api note to ClassValue.computeValue. There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC’ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down. But, there is an edge case where it’s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics. So i have opted for an api note. I don’t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.) Thanks, Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8136353 --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 2016 -0800 +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 2016 -0800 @@ -62,6 +62,13 @@ * If this method throws an exception, the corresponding call to {@code get} * will terminate abnormally with that exception, and no class value will be recorded. * + * @apiNote + * Care should be taken to ensure that this {@code ClassValue} is not + * <a href="../ref/package-summary.html#reachability">strongly reachable</a> + * from the computed value. Doing so may prevent classes and their loaders + * from being garbage collected which in turn may induce out of memory + * errors. + * * @param type the type whose class value must be computed * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface * @see #get

5 15

[RFR] 8160768: Add capability to custom resolve host/domain names within the default JDNI LDAP provider
by Rob McKenna 27 Apr '17

27 Apr '17

Hi folks, I'm looking for feedback on this suggested fix for the following bug: https://bugs.openjdk.java.net/browse/JDK-816076 http://cr.openjdk.java.net/~robm/8160768/webrev.01/ This is something that has come up a few times. Basically in certain environments (e.g. MS Active Directory) there is a dependence on DNS records to provide a pointer to the actual ldap server to be used for a given LdapCtx.PROVIDER_URL where the url itself simply points to the domain name. This fix add a new Ldap context property which allows a user to specify a class (implementing BiFunction) which can perform any necessary extra steps to derive the ldap servers hostname/port from the PROVIDER_URL. -Rob

3 9

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

RFR: jsr166 jdk? integration wave ?
by Martin Buchholz 06 Mar '17

06 Mar '17

We half promised "no more jdk9 changes", but ... http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ as usual, I think they should go into jdk9, but y'all probably tell me it's too late (and that's OK; we can retarget for jdk10) There's only one line of production code change, in ArrayBlockingQueue. The rest is test and javadoc wording improvements, so the risk to the jdk9 release is rather low. Because test changes cannot delay a release, I think rampdown rules should not apply to them the same way.

2 4

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

JDK 9 RFR for JDK-8175972: Remove javax/xml/ws/clientjar/TestWsImport.java from ProblemList
by Amy Lu 28 Feb '17

28 Feb '17

javax/xml/ws/clientjar/TestWsImport.java This test in ProblemList was associated with JDK-8170370. Though JDK-8170370 has been resolved, this test is still in ProblemList.txt. Test has been re-visited and verified in JDK-8173317, no issue. Please review this patch to remove this test from ProblemList.txt bug: https://bugs.openjdk.java.net/browse/JDK-8175972 Thanks, Amy --- old/test/ProblemList.txt 2017-02-28 14:02:27.000000000 +0800 +++ new/test/ProblemList.txt 2017-02-28 14:02:27.000000000 +0800 @@ -309,8 +309,6 @@ javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all -javax/xml/ws/clientjar/TestWsImport.java 8173317 generic-all - org/omg/CORBA/OrbPropertiesTest.java 8175177 generic-all ############################################################################

2 1

On 8175846: Provide javadoc descriptions for jdk.policytool and jdk.crypto.ec modules
by Wang Weijun 26 Feb '17

26 Feb '17

Hi All I'm looking at this bug and have several questions: 1. jdk.jartool is newly introduced in jdk9 (well, all modules are new) but the main class inside it -- sun.security.tools.policytool.PolicyTool -- is already deprecated. Can I also add @deprecated/@Deprecated to the module-info.java of this module? 2. I try to run javadoc on this single module but see the following error. Not sure what it means. Shall I provide more arguments? $ javadoc --module jdk.jartool -d /tmp javadoc: error - fatal error encountered: java.lang.IllegalArgumentException: location is not an output location or a module-oriented location: CLASS_PATH javadoc: error - Please file a bug against the javadoc tool via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include error messages and the following diagnostic in your report. Thank you. java.lang.IllegalArgumentException: location is not an output location or a module-oriented location: CLASS_PATH at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.checkModuleOrientedOrOutputLocation(JavacFileManager.java:1114) at jdk.compiler/com.sun.tools.javac.file.JavacFileManager.getLocationForModule(JavacFileManager.java:955) at jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.getModuleLocation(ElementsTable.java:796) at jdk.javadoc/jdk.javadoc.internal.tool.ElementsTable.scanSpecifiedItems(ElementsTable.java:352) at jdk.javadoc/jdk.javadoc.internal.tool.JavadocTool.getEnvironment(JavadocTool.java:189) at jdk.javadoc/jdk.javadoc.internal.tool.Start.parseAndExecute(Start.java:591) at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:424) at jdk.javadoc/jdk.javadoc.internal.tool.Start.begin(Start.java:341) at jdk.javadoc/jdk.javadoc.internal.tool.Main.execute(Main.java:63) at jdk.javadoc/jdk.javadoc.internal.tool.Main.main(Main.java:52) Thanks Max

2 1