December 2017 - core-libs-dev

RFR[10] 8190984 : tools/launcher/TestXcheckJNIWarnings.java WARNING was found in the output
by Brent Christian 13 Dec '17

13 Dec '17

Hi, Please review this small change to the System.initProperties() native method. The tools/launcher/TestXcheckJNIWarnings.java has begun to fail due to this warning being issued: WARNING: JNI local refs: 41, exceeds capacity: 40 at java.lang.System.initProperties(java.base/Native Method) at java.lang.System.initPhase1(java.base/System.java:1943) This has only been seen on solaris-sparc with LANG=C. In fact, the warning can also be seen with a simple HelloWorld program, run with -Xcheck:jni. This started happening as of JDK-8043224 ("-Xcheck:jni improvements to exception checking and excessive local refs"). The following change should be made to prevent the warning: diff -r ed1bb7743b3e src/java.base/share/native/libjava/System.c --- a/src/java.base/share/native/libjava/System.c Tue Dec 12 19:05:02 2017 +0100 +++ b/src/java.base/share/native/libjava/System.c Tue Dec 12 15:21:03 2017 -0800 @@ -186,6 +186,9 @@ jobject ret = NULL; jstring jVMVal = NULL; + if ((*env)->EnsureLocalCapacity(env, 50) < 0) { + return NULL; + } sprops = GetJavaProperties(env); CHECK_NULL_RETURN(sprops, NULL); Of note: an additional change is needed, to EnsureLocalCapacity itself: 8193222 : EnsureLocalCapacity() should maintain capacity requests through multiple calls That fix has already been proposed and reviewed. These two fixes should be pushed together via hs, which David has kindly offered to do, pending code review approval of my change here. Thanks, -Brent

3 6

RFR(s): 8060192: Add default method Collection.toArray(generator)
by Stuart Marks 12 Dec '17

12 Dec '17

Hi all, Please review this small enhancement to add a default method Collection.toArray(generator) that takes a function that creates the destination array. This is analogous to Stream.toArray(generator). Bug: https://bugs.openjdk.java.net/browse/JDK-8060192 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.0/ Thanks, s'marks

10 27

Possible bug in StackFrameInfo#getByteCodeIndex?
by David Lloyd 12 Dec '17

12 Dec '17

I was doing some research related to AccessController, and I noted this code [1] in StackFrameInfo#getByteCodeIndex(): @Override public int getByteCodeIndex() { // bci not available for native methods if (isNativeMethod()) return -1; return bci; } Now bci is of type short, and given the spec of the method, should the return not be: return bci & 0xffff; instead? Else it would return wrong values for methods with more than 32767 bytecodes in them. [1] http://hg.openjdk.java.net/jdk/jdk/file/e3b6cb90d7ce/src/java.base/share/cl… -- - DML

4 8

RFR (JDK10) 8183743: Umbrella: add overloads that take a Charset parameter
by Joe Wang 12 Dec '17

12 Dec '17

Hi, Adding convenient methods that take a Charset to several classes that have already had methods with a Charset/Encoding name as a parameter. To avoid any impact on compatibility and JCK tests, we've kept the existing methods virtually untouched except making a reference to the new ones to encourage the use of these new methods going forward. The javadocs of the new methods however, may be more complete with details on handling edge cases / Exceptions. JBS: https://bugs.openjdk.java.net/browse/JDK-8183743 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8183743/webrev/index.html Thanks, Joe

3 9

Review Request: JDK-8193192: jdeps --generate-module-info does not look at module path
by mandy chung 12 Dec '17

12 Dec '17

jdeps currently finds modules from the module path for analysis based on the value specified via --add-modules option. When the input classes depend on a module on the given module path, it will report missing dependences until the module is specified in --add-modules option. This fixes this issue and jdeps should look at the modules on the module path when analyzing classes (except jdeps -m option). http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193192/webrev.00 thanks Mandy

2 1

[10]RFR 8190278: ClassCastException is thrown by java.util.Scanner when a NumberFormatProvider is used.
by Nishit Jain 12 Dec '17

12 Dec '17

Hi, Please review the fix for JDK-8190278 Bug: https://bugs.openjdk.java.net/browse/JDK-8190278 Webrev: http://cr.openjdk.java.net/~nishjain/8190278/webrev.03/ Fix: Modified the code to check whether the object returned by NumberFormat#getNumberInstance(Locale) is a DecimalFormat object, if not, then use the DecimalFormat constructor way to create its object, where SPI provider implementation is ignored. Regards, Nishit Jain

3 2

Any news from JDK-8151981 in Java8 ?
by João Paulo Varandas 12 Dec '17

12 Dec '17

Hi guys! We are also experiencing some odd issues here with setCallSiteTargetNormal with Java8. https://bugs.openjdk.java.net/browse/JDK-8151981 Our cenario is: - Web Application using Tomcat; - 8 HTTP Threads; - A single ScriptEngine for the whole application; When a request hits the server, that request may be processed by a JavaScript (using Nashorn), this script is evaluated during runtime, it may run queries(Jdbc) or execute business logic and then return results(Maps and/or Collections) that are serialized to JSON before being written to the response. The problem is... sometimes 7 or more threads are getting stuck in the setCallSiteTargetNormal method and I have no clue why is that happening. Could you guys help me out troubleshooting this? - Or, if there's a bug are there workarounds? By the way, those are not freshly created ScriptEngines(which differ from the normal issues related in the internet). -- "Esta mensagem, incluindo seus anexos, pode conter informacoes confidenciais e privilegiadas. Se voce a recebeu por engano, solicitamos que a apague e avise o remetente imediatamente. Opinioes ou informacoes aqui contidas nao refletem necessariamente a posicao oficial da Plusoft." "Antes de imprimir, pense em sua responsabilidade e compromisso com o MEIO AMBIENTE"

1 0

JDK-8190919 :StaX buffers do not really close underlying buffers
by Srividya Shamaiah 12 Dec '17

12 Dec '17

Joe, Thanks you for your response. I agree with you that the specification says the underlying stream should not be closed. However, it is not clear what was the reason for decided not to close the underlying stream. Also, it is not evident at what point the underlying streams will get closed and whether it will result in a resource leak. We understand not to close the stream if it is shared by multiple threads. However, there should be a logic like reference count which can decide the point at which the stream can be closed. However, we are not finding any such mechanism in this area of code and hence worried about the resource leak. Please let me know how we will ensure that the underlying stream is not getting leaked. With Thanks and Regards, Srividya S

1 0

RFR(JDK10/JAXP) 8190823: Broken link in org/w3c/dom/ls/
by Joe Wang 12 Dec '17

12 Dec '17

Hi, Please review a doc-only fix for 4 dom classes. The material change is s/broken link/correct link/g, that is replacing all occurrence of the non-existent link "http://www.w3.org/TR/DOM-Level-3-Core/core.html" with https://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html. Other changes are format related. In order to avoid the extra space before the text of the hyperlink (e.g. " error handler"), in most cases, I kept the <a> element in one line although it's unfortunately long. jbs: https://bugs.openjdk.java.net/browse/JDK-8190823 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8190823/webrev/ Thanks, Joe

2 2

[10] RFR 8187254 Rearrange private MethodType constructors
by Paul Sandoz 12 Dec '17

12 Dec '17

Hi, Please review this small fix to collapse the two private constructors of MethodType into one. This consolidates all the copying/validation logic into the factory method makeImpl. Thanks, Paul. diff -r 77866b9147be src/java.base/share/classes/java/lang/invoke/MethodType.java --- a/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon Dec 11 10:50:17 2017 -0800 +++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java Mon Dec 11 14:00:09 2017 -0800 @@ -105,23 +105,10 @@ private @Stable String methodDescriptor; // cache for toMethodDescriptorString /** - * Check the given parameters for validity and store them into the final fields. + * Constructor that performs no copying or validation. + * Should only be called from the factory method makeImpl */ - private MethodType(Class<?> rtype, Class<?>[] ptypes, boolean trusted) { - checkRtype(rtype); - checkPtypes(ptypes); - this.rtype = rtype; - // defensively copy the array passed in by the user - this.ptypes = trusted ? ptypes : Arrays.copyOf(ptypes, ptypes.length); - } - - /** - * Construct a temporary unchecked instance of MethodType for use only as a key to the intern table. - * Does not check the given parameters for validity, and must discarded (if untrusted) or checked - * (if trusted) after it has been used as a searching key. - * The parameters are reversed for this constructor, so that it is not accidentally used. - */ - private MethodType(Class<?>[] ptypes, Class<?> rtype) { + private MethodType(Class<?> rtype, Class<?>[] ptypes) { this.rtype = rtype; this.ptypes = ptypes; } @@ -308,18 +295,21 @@ if (ptypes.length == 0) { ptypes = NO_PTYPES; trusted = true; } - MethodType primordialMT = new MethodType(ptypes, rtype); + MethodType primordialMT = new MethodType(rtype, ptypes); MethodType mt = internTable.get(primordialMT); if (mt != null) return mt; // promote the object to the Real Thing, and reprobe + MethodType.checkRtype(rtype); if (trusted) { - MethodType.checkRtype(rtype); MethodType.checkPtypes(ptypes); mt = primordialMT; } else { - mt = new MethodType(rtype, ptypes, false); + // Make defensive copy then validate + ptypes = Arrays.copyOf(ptypes, ptypes.length); + MethodType.checkPtypes(ptypes); + mt = new MethodType(rtype, ptypes); } mt.form = MethodTypeForm.findForm(mt); return internTable.add(mt);

3 2