May 2018 - core-libs-dev

RFR of JDK-8202291,java/rmi/Naming/LookupIPv6.java failed with Connection refused
by Hamlin Li 07 May '18

07 May '18

would you please review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8202291 webrev: http://cr.openjdk.java.net/~mli/8202291/webrev.00/ In original code, there is a window between get registry and rebind which could cause connection refuse. Thank you -Hamlin

2 2

Re: RFR(M): 8201593: Print array length in ArrayIndexOutOfBoundsException.
by David Holmes 07 May '18

07 May '18

Adding core-libs-dev as you're changing java.lang.ArrayIndexOutOfBoundsException. I appreciate the intent here but I find the messages excessively verbose. The basic error is: index N is outside range [0, length-1] David On 18/04/2018 6:09 PM, Lindenmaier, Goetz wrote: > Hi, > > I would like to print a more verbose text on ArrayIndexOutOfBounds exception > that not only mentions the index, but also the length of the array accessed. > See the bug for documentation of the change of the message. > http://cr.openjdk.java.net/~goetz/wr18/8201593-lenInAIOOB/01/ > > @aarch/arm people: > I edited the aarch/arm files. Could you please verify this is correct? > I can not build on these platforms. > > The code on all the other platforms is tested with all the jtreg and jck tests etc. > > Best regards, > Goetz. > >

5 20

[11] RFR: JDK-8202582 : DateTimeFormatterBuilder.parseOffsetBased unnecessarily calls toString()
by Rachna Goel 04 May '18

04 May '18

Hi, Kindly review this small patch for JDK-8202582. https://bugs.openjdk.java.net/browse/JDK-8202582 http://cr.openjdk.java.net/~rgoel/JDK-8202582/webrev/ Fix is to call text.subSequence() before calling toString() on input string, for more performance. -- Thanks, Rachna

4 3

RRF: 8187123: (reflect) Class#getCanonicalName and Class#getSimpleName is a part of performance issue
by Claes Redestad 03 May '18

03 May '18

Hi, please review this patch to enable caching of getCanonicalName and getSimpleName, repeated calls of which has been reported to be a performance bottleneck. The caching improves performance of these methods by up to 20x. Rather than adding new fields to Class itself, which would have footprint implications on classes, we can piggy-back on Class$ReflectionData object. Webrev: http://cr.openjdk.java.net/~redestad/8187123/open.02/ Bug: https://bugs.openjdk.java.net/browse/JDK-8187123 Thanks! /Claes

4 8

RFR (JDK11/java.xml) 8201138: Defect in XMLEventReader.getElementText() may cause data to be skipped, duplicated or otherwise result in a ClassCastException
by Joe Wang 03 May '18

03 May '18

Hi, Please review a fix for a defect in XMLEventReader. The issue was that variable 'type' and 'data' were not set properly within the while statement. JBS: https://bugs.openjdk.java.net/browse/JDK-8201138 webrevs: http://cr.openjdk.java.net/~joehw/jdk11/8201138/webrev/ Thanks, Joe

2 2

Charsets for hex/base64
by Jonas Konrad 03 May '18

03 May '18

Hi, Conceptually, a 'charset' (in java) is a pair of transformations from bytes to utf-16 code units and vice versa. Could it be useful to have charset implementations that convert from bytes to the hex (or base64) representations of those? The idea is as follows: "0a0b0c".getBytes(HexCharset.getInstance()) = new byte[] { 0x0a, 0x0b, 0x0c } new String(new byte[] { 0x0a, 0x0b, 0x0c }, HexCharset.getInstance()) = "0a0b0c" The motivation behind this idea is that there are lots of APIs that provide efficient transformations between chars and bytes using charsets, but converting to/from hex for debugging is usually more involved. One example of this is netty ByteBuf.toString ( https://netty.io/4.0/api/io/netty/buffer/ByteBuf.html#toString-int-int-java… ) - it would be really convenient to be able to just plug in a hex charset to get nice debug output. Of course this is only one example and there are other ways to get hex output from ByteBuf in netty in particular, but I still think that a hex charset would be an interesting tool to reuse code. I understand this is a somewhat dubious use of a Charset, but I'd like to hear other thoughts on it. I built such a charset a while back for fun, here is the source code: https://gist.github.com/yawkat/6e80f21f5d418a85c3283e55b80fb607 - Jonas

5 6

[PATCH] JDK-8159797 Throw a right IllegalArgumentException from the bytecode generated by Method/ConstructorAccessor
by Jaikiran Pai 03 May '18

03 May '18

Hi, This mail contains a potential patch to the issue[1] that I had reported a couple of years back. The issue is still valid and reproducible with latest upstream JDK. In brief, if a certain code has: public void doSomething(String foo) {...} and then it gets invoked through reflection: thatMethod = // get hold of that method through reflection thatMethod.invoke(validObjectInstance, null); then as per the javadoc of the Method#invoke[2] you would expect an IllegalArgumentException (since the method expects 1 parameter and we are sending none). This does throw an IllegalArgumentException, but when the invocation happens through a (dynamically generated) MethodAccessor, instead of a native MethodAccessor, the IllegalArgumentException that gets thrown is due to a NPE that happens and the NPE's toString() output is contained as a message of the IllegalArgumentException, as noted in the JIRA. This happens even for Constructor invocations, through ConstructorAccessor. The commit in the attached patch, adds bytecode instructions to check if the method arguments being passed is null and if so, doesn't attempt an arraylength instruction and instead just stores 0 on to the stack. This prevents the NullPointerException being reported, enclosed as a message within the IllegalArgumentException and instead throws back a proper IllegalArgumentException (as you would expect if the invocation had happened over a native MethodAccessor). The goal of the patch _isn't_ to match the exception message with what the native MethodAccessor throws but just prevent the NPE from being playing a role in the IllegalArgumentException. i.e. this change _doesn't_ throw a new IllegalArgumentException("wrong number of arguments"). The patch also contains a new testcase which reproduces this against the current upstream and verifies this patch works. This is the first time I'm fiddling with bytecode generation, so I would appreciate some feedback on the changed bytecode and if there's a different/better way to do it. Furthermore, although I do have a signed and approved OCA, I will need a sponsor for this patch. Anyone willing to review and sponsor, please? [1] https://bugs.openjdk.java.net/browse/JDK-8159797 [2] https://docs.oracle.com/javase/10/docs/api/java/lang/reflect/Method.html#in… -Jaikiran

1 0

[JDK 11] RFR 8202575: Remove java/lang/String/nativeEncoding/StringPlatformChars.java from ProblemList
by Amy Lu 03 May '18

03 May '18

java/lang/String/nativeEncoding/StringPlatformChars.java This test was problem listed due to execution environment issue (-nativepath was not set) on Solaris and Windows platforms (JDK-8182569). This is not an issue anymore, test PASS on all platform in CI system. Please review the patch to remove it from ProblemList.txt. Thanks, Amy --- old/test/jdk/ProblemList.txt 2018-05-03 13:00:45.000000000 +0800 +++ new/test/jdk/ProblemList.txt 2018-05-03 13:00:45.000000000 +0800 @@ -490,8 +490,6 @@ java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all -java/lang/String/nativeEncoding/StringPlatformChars.java 8182569 windows-all,solaris-all - ############################################################################ # jdk_instrument

2 1

RFR: Here are some easy patches
by Martin Buchholz 02 May '18

02 May '18

Off by one pixel! 8202397: Typo in X-Buffer javadoc http://cr.openjdk.java.net/~martin/webrevs/jdk/X-Buffer-typo/ https://bugs.openjdk.java.net/browse/JDK-8202397 Fixes a long-term micro-embarrassment: 8201634: Random seedUniquifier uses incorrect LCG http://cr.openjdk.java.net/~martin/webrevs/jdk/Random-Ecuyer/ https://bugs.openjdk.java.net/browse/JDK-8201634 An obvious optimization: 8202398: Optimize Arrays.deepHashCode http://cr.openjdk.java.net/~martin/webrevs/jdk/deepHashCode-optimize/ https://bugs.openjdk.java.net/browse/JDK-8202398

3 8

CSR 8202555: Double.toString(double) sometimes produces incorrect results
by Brian Burkhalter 02 May '18

02 May '18

The CSR [1] of [2] is now available for review. If you have comments, please reply to this thread. If you have JBS access you can add comments directly to the issue, but please also comment here for the benefit of those who cannot receive automated JBS updates. Thanks to Raffaello for supplying all the content of this CSR issue. Brian [1] https://bugs.openjdk.java.net/browse/JDK-8202555 [2] https://bugs.openjdk.java.net/browse/JDK-4511638

1 0