May 2016 - core-libs-dev

handling the deprecations introduced by early access builds 116 and 118 of jdk 9
by Richard Hillegas 03 Jun '16

03 Jun '16

Dalibor Topic recommended that I post this feedback on core-libs-dev. This is my feedback after ameliorating the deprecation warnings which surfaced when I compiled and tested Apache Derby with early access builds 116 and 118 of JDK 9. Derby is a pure Java relational database whose original code goes back almost 20 years. Other large, old code bases (like Weblogic) may have similar experiences. More detail on my experience can be found on the JIRA issue which tracks the Derby community's attempt to keep our code evergreen against JDK 9: https://issues.apache.org/jira/browse/DERBY-6856 o Deprecating autoboxing constructors - Deprecating the autoboxing constructors for primitive wrapper objects caused a large rototill of Derby code. That rototill was comparable in size to the changes made necessary by Java 5's introduction of generics. Hopefully, IDEs can automate much of this chore. o Deprecating Class.newInstance() - The deprecation of Class.newInstance() forced a similarly large rototill. The code became more verbose. Additional exceptions had to be caught and propagated up the call stack. For reasons which I don't understand, I had better luck using Class.getConstructor().newInstance() than Class.getDeclaredConstructor().newInstance(). But the former replacement code requires you to make constructors public. For some code bases, that may introduce security problems which are worse than the security problem being addressed by this deprecation. I hope that IDEs and the release notes for JDK 9 will provide some guidance for how to handle these issues. o Deprecating java.util.Observable and java.util.Observer - Two ameliorations are recommended at http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040436.html. The first suggestion (use the awt event model) runs very much counter to the whole intent of Jigsaw. That is because pulling in awt can bloat up an application with large, otherwise unneeded libraries. Using awt was out of the question for Derby, given that the community had already invested a great deal of effort in paring back Derby's dependencies in order to let the code run on JDK 8 compact profile 2. That left us with the other option: write your own replacement classes. If a lot of people end up having to write the same replacement code, then that argues for leaving this small but useful functionality in the JDK. I think that the people who advocated for this deprecation did not have good visibility into how widely these classes are being used in the wild. I recommend that this deprecation be re-evaluated. Thanks, -Rick

2 3

RFR[9]: 8156868 MethodHandles.zero(Class) doc issues
by shilpi.rastogi＠oracle.com 02 Jun '16

02 Jun '16

Hi All, Please review small doc changes- http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/ Fixed following doc issues in same patch https://bugs.openjdk.java.net/browse/JDK-8138599 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/… https://bugs.openjdk.java.net/browse/JDK-8138597 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/… https://bugs.openjdk.java.net/browse/JDK-8156868 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/… https://bugs.openjdk.java.net/browse/JDK-8075283 http://cr.openjdk.java.net/~srastogi/8156868/webrev.01/src/java.base/share/… Thanks, Shilpi

3 4

RE: RFR: Implement RandomAccess spliterator
by Ito, Hiroshi 01 Jun '16

01 Jun '16

Hi Paul, Thank you very much for your feedback, and apologize for the delay in response.. I have incorporated your comments in the attached patch. Please kindly take a look and let me know if you have further feedback. - Modified @implSpec to add a description in case the list implements RandomAccess. - Added modification checking in RandomAccessSpliterator, only when the list implements AbstractList. Sorry for the confusion about SubList. It was all about the concurrent modification checking, so adding the change above pretty much addressed my issue earlier. Thanks, Hiroshi -----Original Message----- From: Paul Sandoz [mailto:paul.sandoz@oracle.com] Sent: Thursday, May 12, 2016 8:46 PM To: Ito, Hiroshi [Tech] Cc: core-libs-dev(a)openjdk.java.net; Chan, Sunny [Tech]; Raab, Donald [Tech] Subject: Re: RFR: Implement RandomAccess spliterator Hi Hiroshi, This is a good example of what seems like a small feature and yet there are some unexpected complexities :-) We will need to refine the implementation specification of List.spliterator, which currently states: * @implSpec * The default implementation creates a * <em><a href="Spliterator.html#binding">late-binding</a></em> spliterator * from the list's {@code Iterator}. The spliterator inherits the * <em>fail-fast</em> properties of the list's iterator. Since the existing implementation is derived from the iterator: @Override default Spliterator<E> spliterator() { return Spliterators.spliterator(this, Spliterator.ORDERED); } concurrent modification checking will occur. The RandomAccessSpliterator should also support modification checking, which i think requires it be an inner class to check co-mod state. I am struggling to understand the points you make about the spliterator of a sub-list of a Vector being required to be an iterator-based implementation. Since AbstractList.SubList can access a Vector's elements through List.get/set why cannot RandomAccessSpliterator? If we want to support random access spliterators on sub-lists i think we would anyway need to override the spliterator method to check for concurrent modification (as is the case of the iterator method). Paul. > On 11 May 2016, at 11:25, Ito, Hiroshi <Hiroshi.Ito(a)gs.com> wrote: > > Hi, > > Please kindly review the attached patch for RandomAccessSpliterator implementation. > > Currently default implementation of spliterator is an IteratorSpliterator which is not optimal for RandomAccess data structures (besides ArrayList and Vector). This patch is to provide a default RandomAccessSpliterator implementation for RandomAccess data structure. > > The figures below demonstrate the performance difference before and after the change. Note the significant performance improvement in test SelectTest.parallel_lazy_streams_gsc (parallel streams performance test for non-JDK Lists that implement RandomAccess but don't yet implement their own spliterators). > > Benchmark code: https://github.com/goldmansachs/gs-collections/blob/master/jmh-tests/src/ma… > > With IteratorSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 172.671 ± 14.231 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 20.662 ± 0.493 ops/s > SelectTest.serial_lazy_jdk thrpt 20 89.384 ± 4.431 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 80.831 ± 7.875 ops/s > > With RandomAccessSpliterator as default: > > Benchmark Mode Cnt Score Error Units > SelectTest.parallel_lazy_jdk thrpt 20 174.190 ± 16.870 ops/s > SelectTest.parallel_lazy_streams_gsc thrpt 20 180.740 ± 9.594 ops/s > SelectTest.serial_lazy_jdk thrpt 20 85.719 ± 2.414 ops/s > SelectTest.serial_lazy_streams_gsc thrpt 20 78.760 ± 1.029 ops/s > > Majority of the patch is contributed by Paul Sandoz and he should be credited in the Contributed-by field. > > Along with this patch submission, we have a question for SubList spliterator implementation that we retained old behavior for now (i.e. return IteratorSpliterator, refer to RandomAccessSubList#spliterator()). We have found that Vector's subList is wrapped by RandomAccessSubList, that is RandomAccess but not a Vector anymore, and it expects to use IteratorSpliterator. We were not sure what's the best approach to distinguish Vector from other RandomAccess data structure within RandomAccessSublist, so we kept it return IteratorSpliterator for now. > > One approach could be to introduce VectorSubList that returns IteratorSpliterator (or an implementation similar to VectorSpliterator?). Then we could revert the spliterator() override in RandomAccessSublist. > > What would be your suggestion to handle this? > > Depending on your suggestion, we might fix the subList spliterator in this patch, or submit a separate patch if the amount of the change is significant. > > Thanks, > Hiroshi > <RandomAccessSpliterator.patch.txt>

3 5

Re: PING: RFR: JDK-4347142: Need method to set Password protection to Zip entries
by KUBOTA Yuji 01 Jun '16

01 Jun '16

2016-04-20 7:57 GMT+09:00 <mark.reinhold(a)oracle.com>: > I have to agree. I don't think it makes sense to add a known-vulnerable > encryption algorithm to the JDK. It might work perfectly well for one > use case but it will eventually be used by someone who doesn't take the > time to understand it, assumes that it provides strong encryption when > it doesn't, gets burned, and then blames Java. Yes, Mark. We never hope to make OpenJDK be blamed with our proposal. Mark, I am glad if you are interested in this proposal if using any strong encryption algorithm like Sherman's implementation (AES encryption). If so, we hope to continue discussion the better way to fill our needs and given comments for improving OpenJDK. Thanks, Yuji

3 4

RFR: 8151876: (tz) Support tzdata2016d
by Ramanand Patil 01 Jun '16

01 Jun '16

HI all, Please review the latest TZDATA integration (tzdata2016d) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8151876 Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ Patch Contains: 1. IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 2. "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 3. Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 4. Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. Regards, Ramanand.

3 10

RFR: JDK-8157850 Jar tests should pass through VM options
by Andrey Nazarov 31 May '16

31 May '16

Some jar tests start VMs without passing vmoptions from jtreg. This fix pass jtreg's vmoptions and javaoptions to processes(java, jar, javac) started by tests. webrev: http://cr.openjdk.java.net/~anazarov/8157850/webrev.01/ jbs: https://bugs.openjdk.java.net/browse/JDK-8157850 --Andrey

5 12

JDK 9 RFR of problem listing of java_sql_Timestamp.java
by Joseph D. Darcy 31 May '16

31 May '16

Hello, After the push for , the test java/beans/XMLEncoder/java_sql_Timestamp.java is failing across platforms. I'd like to problem list the test until the fix for JDK-8158281: "java_sql_Timestamp.java fails with AssertionError" is ready. Patch below. Thanks, -Joe --- a/test/ProblemList.txt Tue May 31 13:15:48 2016 -0700 +++ b/test/ProblemList.txt Tue May 31 15:16:18 2016 -0700 @@ -122,6 +122,8 @@ java/beans/Introspector/8132566/OverridePropertyInfoTest.java 8132565 generic-all java/beans/Introspector/8132566/OverrideUserDefPropertyInfoTest.java 8132565 generic-all +java/beans/XMLEncoder/java_sql_Timestamp.java 8158281 generic-all + ############################################################################ # jdk_lang

2 1

RFR (JAXP) 8158246: Several api/org_xml/sax/helpers/XMLReader tests failed due to no SAXException occurs
by huizhe wang 31 May '16

31 May '16

Hi, This issue was caused by the change 8152912 where the logic was changed so that the parser was directly instantiated when the className was within the DEFAULT_PACKAGE. The problem is that the className can be wrong even if it contains the DEFAULT_PACKAGE. The patch reverts the change 8152912 and adds a check for the default class name so that only if the specified className is the default parser, an instance is instantiated. JBS: https://bugs.openjdk.java.net/browse/JDK-8158246 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8158246/webrev/ 8152912 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8152912/webrev01/src/java.xml/share/… Thanks, Joe

1 0

RFR 9: 8158254 : Put java/time/test/java/time/TestClock_System on the problem list for Solaris
by Roger Riggs 31 May '16

31 May '16

Please review this change to add a java.time test to the ProblemList.txt, only for Solaris. A change[1] was tried for a more efficient way to read the current time but it didn't work out and had to be fixed. The original change propagated to the jdk9-master but the fix [2] has not yet. Jira: 8158128: regression: java/time/test/java/time/TestClock_System.java fails at test_OffsetRegular() -- old/test/ProblemList.txt 2016-05-31 12:31:46.530188722 -0400 +++ new/test/ProblemList.txt 2016-05-31 12:31:46.210188722 -0400 @@ -346,6 +346,13 @@ ############################################################################ +# jdk_time + +java/time/test/java/time/TestClock_System.java 8158128 solaris + + +############################################################################ + # jdk_util Thanks, Roger [1] JDK-8154710 Investigate use of in-memory low-resolution timestamps for Java and internal time API [2] 8157175 GetNanoTimeAdjustment.java fails with excessive adjustment error

3 3

Review Request JDK-8152721: Java Web Start splash mechanism is not working in JDK9
by Mandy Chung 31 May '16

31 May '16

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152721/webrev.00/ The launcher does not handle the new options with whitespace separated arguments properly. This patch applies that consistently in java.c I leave arg.c as is that Kumar/Henry can consider cleanup in the future. Mandy

3 4