April 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

[PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics
by Chris Dennis 02 Nov '17

02 Nov '17

Hi Paul (et al) Like all things API there are wrinkles here when it comes to implementing. This patch isn’t final, there appears to be no existing test coverage for these classes beyond testing the compensating summation used in the double implementation, and I left off adding any until it was decided how much parameter validation we want (since that’s the only testing that can really occur here). The wrinkles relate to the issues around instances that have suffered overflow in count and/or sum which the existing implementation doesn’t defend against: * I chose to ignore all parameters if 'count == 0’ and just leave the instance empty. I held off from validating min, max and count however. This obviously 'breaks things’ (beyond how broken they would already be) if count == 0 only due to overflow. * I chose to fail if count is negative. * I chose to enforce that max and min are logically consistent with count and sum, this can break the moment either one of the overflows as well (I’m also pretty sure that the FPU logic is going to suffer here too - there might be some magic I can do with a pessimistic bit of rounding on the FPU multiplication result). I intentionally went with the most aggressive parameter validation here to establish one end of what could be implemented. There are arguments for this and also arguments for the other extreme (no validation at all). Personally I’m in favor of the current version where the creation will fail if the inputs are only possible through overflow (modulo fixing the FPU precision issues above) even though it’s at odds with approach of the existing implementation. Would appreciate thoughts/feedback. Thanks. Chris P.S. I presume tests would be required for the parameter checking (once it is finalized)?

8 23

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

RFR: jsr166 jdk10 integration wave 1
by Martin Buchholz 22 Jul '17

22 Jul '17

First jdk10 integration http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/ Mostly focused on thread pools.

2 7

RFR: 8176508 Update JAX-WS RI integration to latest version
by Roman Grigoriadi 16 Jun '17

16 Jun '17

Hi, Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ Summary of changes: jaxws/src/java.activation/share/classes/javax/activation/* These are from Bill, fixing JDK-8049379 jaxws/src/java.xml.bind/share/classes/javax/xml/bind/* JDK-8169496 - JAXB annotated classes needs to be open for JAXB impl module. Javadoc updates + propagation of openness if JAXB impl is in other module than java.xml.bind. This needs an update to JAXB JCK tests. jaxws/src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/** Contains a fix for reported bug after removal dependencies to JDK internal classes from SAAJ + formattig updates according to review comments on last sync. jaxws/src/java.xml.ws/share/classes/**/*Messages.java jaxws/src/jdk.xml.ws/share/classes/**/*Messages.java These are generated files, which were modified manually in JDK in order to solve JDK-8153944. Generation of these file was updated (removed Lambda), these changes should respect JDK-8153944 fix. Patch also contains several small bugfixes, not tracked in JBS. Best regards, Roman

8 30

Accessing module internals from bytecode rewriting agent
by Martin Buchholz 16 Jun '17

16 Jun '17

We've been playing with byteman. If I have a simple rule that accesses a private field, RULE trace java.util.PriorityQueue_add CLASS java.util.PriorityQueue METHOD add AT EXIT IF true DO traceln(java.util.Arrays.toString($0.queue)) ENDRULE Then with jdk8 I get output like: [1, 2, 3] but in jdk9 we fail with java.lang.IllegalArgumentException: illegal lookupClass: class java.util.PriorityQueue Bytecode rewriting agents have the power to inject code into classes; they should somehow also be able to reflectively inspect those same classes! But how? We ran into similar problems trying to port java agents at Google to jdk9. Details: JAVA_TOOL_OPTIONS="-javaagent:${BYTEMAN_JAR}=script:${BYTEMAN_SCRIPT},boot:${BYTEMAN_JAR}" [java] java.lang.IllegalArgumentException: illegal lookupClass: class java.util.PriorityQueue [java] at java.base/java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:123) [java] at java.base/java.lang.invoke.MethodHandles$Lookup.checkUnprivilegedlookupClass(MethodHandles.java:1003) [java] at java.base/java.lang.invoke.MethodHandles$Lookup.<init>(MethodHandles.java:750) [java] at java.base/java.lang.invoke.MethodHandles.privateLookupIn(MethodHandles.java:205) [java] at org.jboss.byteman.jigsaw/org.jboss.byteman.jigsaw.JigsawAccessEnabler.createFieldGetter(JigsawAccessEnabler.java) [java] at org.jboss.byteman.rule.Rule.addAccessibleFieldGetter(Rule.java:1043) [java] at org.jboss.byteman.rule.expression.FieldExpression.lookupField(FieldExpression.java:549) [java] at org.jboss.byteman.rule.expression.FieldExpression.typeCheckAny(FieldExpression.java:201) [java] at org.jboss.byteman.rule.expression.FieldExpression.typeCheck(FieldExpression.java:110) [java] at org.jboss.byteman.rule.expression.MethodExpression.findMethod(MethodExpression.java:297)

11 37

RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp
by Brent Christian 12 May '17

12 May '17

Hi, This test times out under our automated testing configurations that include -Xcomp. Please review my change to increase the timeout for this test. It is sufficient for the test configurations in question to pass on two different local machines (Mac & Linux). diff -r 7c04ab31b4d6 test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java Wed Apr 26 09:37:23 2017 -0700 +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java Thu Apr 27 12:03:33 2017 -0700 @@ -29,7 +29,7 @@ * @library /lib/testlibrary * @modules java.base/jdk.internal.module * @build JarUtils CompilerUtils - * @run main/timeout=240 ClassLoaderTest + * @run main/timeout=1200 ClassLoaderTest */ Thanks, -Brent

6 18

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 [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo
by Pavel Rappo 09 May '17

09 May '17

Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8179021/webrev.00/ Along with refactoring this change contains a number of critical fixes for WebSocket. Critical fixes are applied to Receiver and OpeningHandshake. Also this change removes 2 convenience methods and 1 constant from WebSocket interface. Since this interface is a part of incubation feature there shouldn't be any problem. Those members were initially controversial. Thanks, -Pavel

1 1