Re: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member

2019-07-27 Thread Mandy Chung
On 7/26/19 11:51 PM, Alan Bateman wrote: On 26/07/2019 22:12, Mandy Chung wrote: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

2019-07-27 Thread Alan Bateman
On 26/07/2019 20:01, Brian Burkhalter wrote: So updated: http://cr.openjdk.java.net/~bpb/8078891/webrev.02/ This version is a lot cleaner and looks okay to me. -Alan

Re: 8078891: java.io.SequenceInputStream.close is not atomic and not idempotent

2019-07-27 Thread Alan Bateman
On 26/07/2019 20:37, Pavel Rappo wrote: For the record. If we change this as you suggested, the code will behave differently in the case of a single `null` element found in the midst of iteration (broken enumeration?). The stream won't be able to close after running into it. But this most likely

Re: Review Request: JDK-8228671: Fastdebug VM throws InternalError when publicLookup.in(T) is used to resolve a member

2019-07-27 Thread Alan Bateman
On 26/07/2019 22:12, Mandy Chung wrote: Debug VM checks if a class is accessible to the lookup class except if the lookup class is java.lang.Object (which was the lookup class of publicLookup previously). WithJDK-8173978, Lookup::in has changed and it can be used to create a new public Lookup