September 2018 - core-libs-dev

Re: ByteArrayOutputStream should not have a new writeBytes method in Java
by Tomasz Linkowski 10 Oct '18

10 Oct '18

Hello Stuart, I'm not sure whether you're aware that IntelliJ IDEA has an automatic inspection named "C-style array declaration": - description: https://github.com/JetBrains/intellij-community/blob/master/plugins/Inspect… - logic: https://github.com/JetBrains/intellij-community/blob/master/plugins/Inspect… You can run such single inspection over the entire project as described here: https://www.jetbrains.com/help/idea/running-inspection-by-name.html It will fix all such C-style array declarations for you automatically. -- Regards, Tomasz Linkowski From: Stuart Marks <stuart.marks(a)oracle.com> > To: "ullenboom(a)gmail.com" <ullenboom(a)gmail.com> > Cc: "core-libs-dev(a)openjdk.java.net" <core-libs-dev(a)openjdk.java.net> > Bcc: > Date: Tue, 11 Sep 2018 13:23:41 -0700 > Subject: Re: ByteArrayOutputStream should not have a new writeBytes method > in Java 11 2. even if, it should not be byte b[] but byte[] b > Yeah we need to clean occurrences of this anachronistic array declaration > from the JDK. I noticed a few others nearby. It's startling that a new > occurrence has crept it. (Or maybe not, perhaps it was done to conform to > the nearby code.) > Any volunteers to clean this up? > An interesting exercise would be to write a detector for this declaration > style. > s'marks

7 9

RFR 8211295: DriverManager.getConnection fails when called from com.sun.rowset.JdbcRowSetImpl
by Lance Andersen 01 Oct '18

01 Oct '18

Attached is the webrev for the JDBC RowSet/DriverManager issue, https://bugs.openjdk.java.net/browse/JDK-8211295 <https://bugs.openjdk.java.net/browse/JDK-8211295>, that was raised on the thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-September/055755.… I have run the JDBC TestSuite against the Derby Embedded and Derby Network server; Mach 5 jdk tier1, tier2, and tier3 tests as well as the JCK java.sql and javax.sql tests. All pass with the fix The webrev can be found at http://cr.openjdk.java.net/~lancea/8211295/webrev.00/ <http://cr.openjdk.java.net/~lancea/8211295/webrev.00/> Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com <mailto:Lance.Andersen@oracle.com>

3 3

RFR: JDK-8166138 - DateTimeFormatter.ISO_INSTANT should handle offsets
by Pallavi Sonal 01 Oct '18

01 Oct '18

Hi, Please review the changes to the following issue: Bug : https://bugs.openjdk.java.net/browse/JDK-8166138 The proposed fix is located at: Webrev : http://cr.openjdk.java.net/~rpatil/8166138/webrev.00/ As per ISO 8601 standards, an offset of zero, in addition to having the special representation "Z", can also be stated numerically as "+00:00", "+0000", or "+00" [1]. With this fix, Instant.parse() can parse a String containing the zero offsets in any of these three forms. Any other offset apart from "Z", "+00:00", "+0000", or "+00" will not be accepted in the input string to be parsed. [1] https://en.wikipedia.org/wiki/ISO_8601 Thanks, Pallavi Sonal

5 20

How can I solve Modularity related issue ?
by Ichiroh Takiguchi 01 Oct '18

01 Oct '18

Hello. One of JDBC application with JavaDB did not work on JDK12. Following exception happened: java.sql.SQLException: No suitable driver found for jdbc:derby:xxxxxx I assume, this issue related Modularity feature... I could not solve this issue by myself. In order to investigate the root cause, I would appreciate telling me how to identify the problem and debug it. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. =========================== The detail instruction is as follows: It has two types of SELECT statement call. 1. Use DriverManager 2. Use createJdbcRowSet() "1" worked fine, "2" did not work on JDK11. Same one worked fine on JDK8. System / OS: RHEL 7.5 x86_64 Steps to Reproduce 1. Store JavaDB (derby.jar) in derby/lib/derby.jar You can download Apache Derby (derby.jar) [1] or use JDK8's one 2. Download testcases [2][3][4], then compile and run following command $ javac SetupJavaDB.java JdbcRowSetProvider.java JdbcRowSetProviderA.java 3. Create DB $ java -cp derby/lib/derby.jar:. SetupJavaDB 4. Run testcases ### Use DriverManager and createJdbcRowSet() ### $ java -cp derby/lib/derby.jar:. JdbcRowSetProvider ### Use createJdbcRowSet() ### $ java -cp derby/lib/derby.jar:. JdbcRowSetProviderA On JDK8 $ ~/jdk8_181/jdk1.8.0_181/jre/bin/java -showversion -cp derby/lib/derby.jar:. JdbcRowSetProvider java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) 1,One 2,Two 3,Three 1,One 2,Two 3,Three $ ~/jdk8_181/jdk1.8.0_181/jre/bin/java -showversion -cp derby/lib/derby.jar:. JdbcRowSetProviderA java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) 1,One 2,Two 3,Three On JDK12 $ ~/jdk-12+12/bin/java -showversion -cp derby/lib/derby.jar:. JdbcRowSetProvider openjdk version "12-ea" 2019-03-19 OpenJDK Runtime Environment 19.3 (build 12-ea+12) OpenJDK 64-Bit Server VM 19.3 (build 12-ea+12, mixed mode) 1,One 2,Two 3,Three Exception in thread "main" java.sql.SQLException: No suitable driver found for jdbc:derby:javadb/db at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702) at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.connect(JdbcRowSetImpl.java:643) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.prepare(JdbcRowSetImpl.java:654) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.execute(JdbcRowSetImpl.java:556) at JdbcRowSetProvider.main(JdbcRowSetProvider.java:30) $ ~/jdk-12+12/bin/java -showversion -cp derby/lib/derby.jar:. JdbcRowSetProviderA openjdk version "12-ea" 2019-03-19 OpenJDK Runtime Environment 19.3 (build 12-ea+12) OpenJDK 64-Bit Server VM 19.3 (build 12-ea+12, mixed mode) Exception in thread "main" java.sql.SQLException: No suitable driver found for jdbc:derby:javadb/db at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:702) at java.sql/java.sql.DriverManager.getConnection(DriverManager.java:228) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.connect(JdbcRowSetImpl.java:643) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.prepare(JdbcRowSetImpl.java:654) at java.sql.rowset/com.sun.rowset.JdbcRowSetImpl.execute(JdbcRowSetImpl.java:556) at JdbcRowSetProviderA.main(JdbcRowSetProviderA.java:18) =========================== [1] https://db.apache.org/derby/derby_downloads.html [2] https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/SetupJavaDB.java [3] https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/JdbcRowSetProvider.java [4] https://cr.openjdk.java.net/~itakiguchi/jdk12-jdbc/JdbcRowSetProviderA.java

4 4

Re: RFR: 8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean
by Alan Bateman 29 Sep '18

29 Sep '18

On 26/09/2018 16:58, Alan Bateman wrote: > On 26/09/2018 16:51, Andrew Haley wrote: >> Java_java_io_Console_echo looks like this: >> >> JNIEXPORT jboolean JNICALL >> Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) >> { >> DWORD fdwMode; >> jboolean old; >> ... >> old = (fdwMode & ENABLE_ECHO_INPUT); >> ... >> return old; >> } >> >> It only works by accident. jboolean is an unsigned byte. >> ENABLE_ECHO_INPUT on the systems I know of is 0000010, so fdwMode & >> ENABLE_ECHO_INPUT fits into the result, but only by accident. We >> should do things properly and return a clean boolean. >> >> Note that the Windows version of the code is correct: I assume the >> UNIX version is an oversight. >> >> https://bugs.openjdk.java.net/browse/JDK-8211163 >> http://cr.openjdk.java.net/~aph/8211163/ >> >> OK? > Probably better to bring this to core-libs-dev as I think it's the > same issue as this thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054479.html > > > I can't see a conclusion (as in change-set) but Ichiroh's second mail > has the same patch as you. > Moving this to core-libs-dev as this is third time this has come up. The patch looks okay to me. -Alan

6 10

[PATCH] 8210810: Incorrect argument file parser behavior in certain cases
by Bo Zhang 28 Sep '18

28 Sep '18

Hi all, This is my first time to try to submit a patch. Please forgive me if I did anything inappropriate. I’ve signed the OCA with the name “Bo Zhang”. Bug description: 8210810 <https://bugs.openjdk.java.net/browse/JDK-8210810>: Incorrect argument file parser behavior in certain cases Previously, if a quoted backslash character appears at argument file parser buffer boundary (i.e. 4096th/8192nd/... character of an argument file is backslash '\'), the segment before the backslash character will be added into argument twice due to a missing anchor position reset operation. For example, you have an argument file: -cp "...a\\b" and the 4096th and 4097th characters happen to be both '\', the result generated by the argument file parser would be: -cp "...aa\\b” This patch fixes the issue by resetting anchor position correctly in this case. I’m a little surprised that this issue has existed for several years unnoticed. Patch: # HG changeset patch # User Bo Zhang <zhangbodut(a)gmail.com <mailto:zhangbodut@gmail.com>> # Date 1537835887 -28800 # Tue Sep 25 08:38:07 2018 +0800 # Node ID 34f2803ad62cde8c82e3dfcf0b66e80276bd7352 # Parent 16f0deae8fa6ef85f7230308e1fe7556bd007c39 8210810: Incorrect argument file parser behavior in certain cases Previously, if a quoted backslash character appears at argument file parser buffer boundary (i.e. 4096th/8192nd/... character of an argument file is backslash '\'), the segment before the backslash character will be added into argument twice due to a missing anchor position reset operation. For example, you have an argument file: -cp "...a\\b" and the 4096th and 4097th characters happen to be both '\', the result generated by the argument file parser would be: -cp "...aa\\b" This patch fixes the issue by resetting anchor position correctly in this case. diff --git a/src/java.base/share/native/libjli/args.c b/src/java.base/share/native/libjli/args.c --- a/src/java.base/share/native/libjli/args.c +++ b/src/java.base/share/native/libjli/args.c @@ -262,6 +262,8 @@ continue; } JLI_List_addSubstring(pctx->parts, anchor, nextc - anchor); + // anchor after backslash character + anchor = nextc + 1; pctx->state = IN_ESCAPE; break; case '\'': diff --git a/test/jdk/tools/launcher/Test8210810.java b/test/jdk/tools/launcher/Test8210810.java new file mode 100644 --- /dev/null +++ b/test/jdk/tools/launcher/Test8210810.java @@ -0,0 +1,107 @@ +/* + * Copyright (c) 2018, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com <http://www.oracle.com/> if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8210810 + * @summary Incorrect argument file parser behavior when backslash appears at buffer boundary + * @modules java.base + * @author Bo Zhang + * @build TestHelper + * @run main Test8210810 + */ + +/* + * 8210810: Previously, if a quoted backslash character appears at argument file + * parser buffer boundary (i.e. 4096th/8192nd/... character of an argument + * file is backslash '\'), the segment before the backslash character will + * be added into argument twice due to a missing anchor position reset + * operation. This test creates a special argument file which can reproduce this issue. + */ +import java.io.File; +import java.nio.file.Files; +import java.io.IOException; +import java.util.Arrays; + +public class Test8210810 extends TestHelper { + // Buffer size in args.c readArgFile() method + private static final int ARG_FILE_PARSER_BUF_SIZE = 4096; + public static void main(String... args) throws Exception { + new Test8210810().canParseArgFileCorrectly(); + } + + private void canParseArgFileCorrectly() throws IOException { + File testJar = createTestClassWhichPrintsClasspath(); + File argFile = createArgFileWithSpecificClasspath(); + TestResult result = doExec(javaCmd, "@argFile", "Foo"); + + long zCountInArgFile = countZ(new String(Files.readAllBytes(argFile.toPath()))); + long zCountReadByParser = countZ(result.testOutput.get(0)); + if(zCountInArgFile != zCountReadByParser) { + throw new RuntimeException("Classpath parsed by parser is different from argument file!"); + } + + testJar.delete(); + argFile.delete(); + } + + private long countZ(String str) { + return str.chars().filter(ch -> ch == 'z').count(); + } + + private File createTestClassWhichPrintsClasspath() throws IOException { + File testJar = new File("test.jar"); + testJar.delete(); + + StringBuilder tsrc = new StringBuilder(); + tsrc.append("public static void main(String... args) {\n"); + tsrc.append(" System.out.println(\"Classpath:\" + System.getProperty(\"java.class.path\"));\n"); + tsrc.append("}\n"); + createJar(testJar, new File("Foo"), tsrc.toString()); + return testJar; + } + + // Create a file whose 4096th and 4097th characters are both '\' (backslash) + // File content: + // |-cp "test.jar:zzzzz...zzz\\"| + private File createArgFileWithSpecificClasspath() throws IOException { + File argFile = new File("argFile"); + argFile.delete(); + + StringBuilder arg = new StringBuilder("-cp \"test.jar"); + arg.append(File.pathSeparator); + + int fillingCharactersCount = ARG_FILE_PARSER_BUF_SIZE - 1 - arg.length(); + + for(int i = 0; i < fillingCharactersCount; ++i) { + arg.append('z'); + } + + arg.append('\\'); // 4096th character in the arg file + arg.append('\\'); // 4097th character in the arg file + arg.append('"'); + + createAFile(argFile, Arrays.asList(arg.toString())); + return argFile; + } +} Unit test: Included in the patch. It creates a special argument file whose 4096th and 4097th characters are both ‘\’. Then it compares the classpath read in the VM and the classpath in the argument file to verify they’re identical.

3 11

Reactive Streams utility API
by James Roper 28 Sep '18

28 Sep '18

Hi all, This is an email to give people a heads up that we'd like to look at creating an API, in the same vein as the JDK8 Streams API, for building reactive streams (a la JDK9 juc.Flow). Our goals for this are: * To fill a gap in the JDK where if a developer wants to do even the simplest of things with a JDK9 juc.Flow, such as map or filter, they need to bring in a third party library that implements that. * To produce an API that can build Publishers, Subscribers, Processors, and complete graphs, for the purposes of consuming APIs that use reactive streams (for example, JDK9 Http Client). * To produce an API that aligns closely with ju.stream.Stream, using it for inspiration for naming, scope, general API shape, and other aspects. The purpose of this goal is to ensure familiarity of Java developers with the new API, and to limit the number of concepts Java developers need to understand to do the different types of streaming offered by the JDK. * To produce an API that can be implemented by multiple providers (including an RI in the JDK itself), using the ServiceLoader mechanism to provide and load a default implementation (while allowing custom implementations to be manually provided). There are a lot of concerns that each different streams implementation provides and implements, beyond streaming, for example monitoring/tracing, concurrency modelling, buffering strategies, performance aspects of the streams handling including fusing, and context (eg thread local) propagation. This will allow libraries to use and provide contracts based on this API without depending on a particular implementation, and allows developers to select the implementation that meets their needs. Non goals: * To produce a kitchen sink of utilities for working with reactive streams. There already exist a number of reactive streams implementations that seek to meet this goal (eg, Akka Streams, Reactor, RxJava), and once you go past the basics (map, filter, collect), and start dealing with things like fan in/out, cycles, restarting, etc, the different approaches to solving this start to vary greatly. The JDK should provide enough to be useful for typical every day streaming use cases, with developers being able to select a third party library for anything more advanced. We will update this list when we have something ready for public review. This probably won't be far off. Our hope is that we can propose this as a JEP. Regards, James -- *James Roper* *Senior Octonaut* Lightbend <https://www.lightbend.com/> – Build reactive apps! Twitter: @jroper <https://twitter.com/jroper>

3 11

[XS] RFR : 8211149: fix potential memleak in getJavaIDFromLangID after failing SetupI18nProps call [windows]
by Baesken, Matthias 27 Sep '18

27 Sep '18

Hello, could you please review this small change (windows only) ? Currently, the function "getJavaIDFromLangID" (located in windows java_props_md.c) only does proper deallocations after a successful call to the function SetupI18nProps. See if (SetupI18nProps(MAKELCID(langID, SORT_DEFAULT), &(elems[0]), &(elems[1]), &(elems[2]), &(elems[3]), &(elems[4]))) { ...... for (index = 0; index < 5; index++) { free(elems[index]); } However a failing call (SetupI18nProps returning false) might still need deallocations, because the function SetupI18nProps can malloc memory in the failing case as well . The change initializes the pointers in char * elems[5]; And later frees them in case they are not NULL . Webrev and bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8211149.0/8211149.0/webrev/ https://bugs.openjdk.java.net/browse/JDK-8211149 Best regards, Matthias

3 3

RFR: jsr166 integration 2018-09
by Martin Buchholz 27 Sep '18

27 Sep '18

https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview… 8210971: Add exception handling methods to CompletionStage and CompletableFuture https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/exceptio… https://bugs.openjdk.java.net/browse/JDK-8210971 8207003: Miscellaneous changes imported from jsr166 CVS 2018-09 https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscella… https://bugs.openjdk.java.net/browse/JDK-8207003 This one continues to be stuck in CSR limbo: 8203662: remove increment of modCount from ArrayList and Vector replaceAll() https://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceA… https://bugs.openjdk.java.net/browse/JDK-8203662

2 1

Re: RFR: JDK-8211071: unpack.cpp fails to compile with statement has no effect [-Werror=unused-value]
by Magnus Ihse Bursie 27 Sep '18

27 Sep '18

> 25 sep. 2018 kl. 10:21 skrev Roman Kennke <rkennke(a)redhat.com>: > > Not sure this is the correct list. Please redirect as appropriate. I believe core-libs is the appropriate place. Cc:d. > > Please review the following proposed change: > > > There are 3 asserts in unpack.cpp which check only constants, and which > the compiler rejects as 'has no effect' (in fastdebug builds). This > seems to be caused by: > > https://bugs.openjdk.java.net/browse/JDK-8211029 > > I propose to fix this by defining a STATIC_ASSERT which can evaluate and > reject this at compile time: > > Webrev: > http://cr.openjdk.java.net/~rkennke/JDK-8211071/webrev.00/ From a build perspective, this looks good. But please let someone from core-libs review also. > Bug: > https://bugs.openjdk.java.net/browse/JDK-8211071 > > It might be useful to define the STATIC_ASSERT in a more central place > to be used elsewhere too. For example, there is a similar #define in > Hotspot's debug.hpp Unfortunately, we do not have a good place to share definitions like this across JDK libraries. :-( The need for that has struck me more than once. For some stuff, we mis-use jni.h. But it would definitely be out of line to add a STATIC_ASSERT there. /Magnus > > Thanks, Roman >

3 3