Re: RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Hi Bhanu, I think you should add a test case comparing the return value of getFrom() ( Not an official reviewer) Regards, Nadeesh On 5/16/2016 11:46 AM, Bhanu Gopularam wrote: Hi all, Could you please review fix for following issue. Bug id:

Can an object be finalized while still weakly reachable?

I have some evidence that an object's finalize method can run while a weak reference pointing to it is not yet cleared, which surprised me. E.g. class F { protected void finalize() { assert wref.get() != this; } } static WeakReference wref = new WeakReference(new F()); If this is a bug, I can

RFR [9]: 8157096: [TEST_BUG] test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java is skipped by jtreg

Hi, Please review the changes to test/javax/xml/bind/xjc/8145039/JaxbMarshallTest.java: 1. The test is skipped by JTREG due to incorrect module name in jtreg @modules tag: javax.xml.bind -> java.xml.bind 2. The compilation of XJC generated classes now requires "-addmods java.xml.bind"

RFR [9]: 8072579: XjcOptionalPropertyTest.java creates files in test.src

Hi, Please, help to review XjcOptionalPropertyTest test modification bug [1]. The list of applied changes: 1. Test files are now generated in jtreg work directory (scratch), instead of test source folder. 2. Shell script was replaced with java code: xjc tool is now invoked via

RFR: JDK-8157069: Assorted ZipFile improvements

Hi Xueming, https://bugs.openjdk.java.net/browse/JDK-8157069 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/ZipFile-assortment/ Hopefully other improvements later. BTW, I notice that the CEN is stored in a byte[], and someday someone will create a zip file with a CEN that won't fit!

RE: RFR: 8144062: Move jdk.Version to java.lang.Runtime.Version

Hi, Remi. Thanks for taking the time to review this change. > java.lang.Runtime.Version is used during the boot process I don’t think that Runtime.Version is used during boot because I'm not seeing it loaded with a small test program invoked with "java -verbose:class Hi". In fact, I'm not

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Martin, As I have been studying the CleanerTest too recently, let me comment on some questions... On 05/09/2016 06:34 PM, Martin Buchholz wrote: --- Assert.assertEquals(map.get(k2), data, "value should be found in the map"); key = null; System.gc();

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

On 16/05/2016 14:45, Seán Coffey wrote: On 16/05/16 13:51, Alan Bateman wrote: On 16/05/2016 13:44, Seán Coffey wrote: Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits.

Helpers for MethodHandles.byteArrayViewVarHandle VarHandle

Hi, what do you thing about adding helper methods for this kind of VarHandle? It would be nice to have something like Long.getFrom[LE/BE](byte[] arr, int index) // LE/BE -> endianity Long.setTo[LE/BE](long val, byte[] arr, int index) or Arrays.getLongFrom[LE/BE](byte[] arr, int

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

On 16/05/16 13:51, Alan Bateman wrote: On 16/05/2016 13:44, Seán Coffey wrote: Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev :

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

On 16/05/2016 13:44, Seán Coffey wrote: Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html

RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

Some extra capturing of context in exception handling. I've re-based the original suggested patch and added some minor edits. https://bugs.openjdk.java.net/browse/JDK-8151832 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832/webrev/index.html -- Regards, Sean.

Re: Cleaner cleanup

Hi Peter, I for one think this looks like a very nice cleanup. The patch drops 5 classes from a minimal VM startup test, which is a welcome improvement. /Claes On 2016-05-16 00:08, Peter Levart wrote: Hi Roger and others, When the new Cleaner API was created the implementation of

Re: RFR 8156485 MethodHandles.varHandleExactInvoker should perform exact checks

Looks good. Best regards, Vladimir Ivanov PS: regarding naming, makeVarHandleMethodInvoker is shorter and as informative. Since there are only 2 flavors of invokers for VarHandles (for MHs there are also basic invokers), there's no need to explicitly mention the modes in method names. On

Re: Cleaner cleanup

Hey Peter, Thanks for your answer. Actually you’re right, makes perfect sense. Somehow it still feels wrong to implement the same pattern (inside lots of classes) over and over again. Inheritance, on the other hand, is not always possible. Chris > On 16 May 2016, at 12:57, Peter Levart

Re: Cleaner cleanup

Correction in line... On 05/16/2016 12:54 PM, Peter Levart wrote: Hi Christoph, On 05/16/2016 10:37 AM, Christoph Engelbert wrote: Hey Peter, First of all, I really love this Cleanup API! Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case

Re: Cleaner cleanup

Hi Christoph, On 05/16/2016 10:37 AM, Christoph Engelbert wrote: Hey Peter, First of all, I really love this Cleanup API! Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. Made up example:

Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

Looks good. Best regards, Vladimir Ivanov PS: I noticed you missed ACC_PRIVATE flag on the invoker class, but then erroneously put it on the method. Please, move it to class flags before pushing. No need to send updated webrev. + cw.visit(52, ACC_PRIVATE | ACC_SUPER,

Re: Cleaner cleanup

Peter, Just as a quick correction of the previous example, obviously Buffer::deallocate wouldn’t work, but I guess you get the point. Chris > On 16 May 2016, at 10:37, Christoph Engelbert wrote: > > Hey Peter, > > First of all, I really love this Cleanup API! > Anyhow I

Re: Cleaner cleanup

Hey Peter, First of all, I really love this Cleanup API! Anyhow I think it would make sense to have Cleanable extend AutoCloseable for exactly the use case you rendered in your JavaDoc of the Cleaner class. Made up example: public T execute(BufferAction bufferAction) { Buffer buffer =

JDK 9 RFR of JDK-8157006/8157011: Problem list java/io/pathNames/GeneralWin32.java and tools/pack200/TestNormal.java

java/io/pathNames/GeneralWin32.java has been seen to fail with high frequency on windows. Until JDK-8156595 is addressed, the test should be problem listed. bug: https://bugs.openjdk.java.net/browse/JDK-8157006 tools/pack200/TestNormal.java has been seen to fail with some frequency on windows.

RFR 8156718: Need tests for IsoFields getFrom for unsupported non-Iso Temporal fields

Hi all, Could you please review fix for following issue. Bug id: https://bugs.openjdk.java.net/browse/JDK-8156718 Solution: Added tck tests for validating getFrom method for unsupported non-Iso temporal fields Webrev: http://cr.openjdk.java.net/~bgopularam/JDK-8156718/webrev.00/ Thanks,