Re: RFR: 8225571: Port DND source to use GTK instead of GDK

2019-12-02 Thread Thiago Milczarek Sayao
On Fri, 4 Oct 2019 23:03:00 GMT, Kevin Rushforth wrote: > On Wed, 2 Oct 2019 20:02:22 GMT, Kevin Rushforth wrote: > >> On Wed, 2 Oct 2019 19:54:50 GMT, Thiago Milczarek Sayao >> wrote: >> >>> On Wed, 2 Oct 2019 19:54:50 GMT, Kevin Rushforth wrote: >>> On Wed, 2 Oct 2019 19:54:48 GMT,

Re: [Rev 01] RFR: 8212034: Potential memory leaks in jpegLoader.c in error case

2019-12-02 Thread Ambarish Rapte
The pull request has been updated with additional changes. Added commits: - 8a48080a: correcting use of scanline_ptr Changes: - all: https://git.openjdk.java.net/jfx/pull/54/files - new: https://git.openjdk.java.net/jfx/pull/54/files/7af932b7..8a48080a Webrevs: - full: ht

Re: RFR: 8212034: Potential memory leaks in jpegLoader.c in error case

2019-12-02 Thread Ambarish Rapte
On Thu, 28 Nov 2019 11:12:42 GMT, Arunprasad Rajkumar wrote: > On Wed, 27 Nov 2019 11:58:18 GMT, Ambarish Rapte wrote: > >> Memory allocated in initDecompressor() and decompressIndirect() is not freed >> in error case. >> In error case, >> 1. Allocated memory should be freed. >> 2. Appropriat

Re: RFR: 8212034: Potential memory leaks in jpegLoader.c in error case

2019-12-02 Thread Ambarish Rapte
On Mon, 2 Dec 2019 12:14:21 GMT, Ambarish Rapte wrote: > On Thu, 28 Nov 2019 11:12:42 GMT, Arunprasad Rajkumar > wrote: > >> On Wed, 27 Nov 2019 11:58:18 GMT, Ambarish Rapte wrote: >> >>> Memory allocated in initDecompressor() and decompressIndirect() is not >>> freed in error case. >>> In

Re: RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader

2019-12-02 Thread Ambarish Rapte
On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth wrote: > On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte wrote: > >> The finalize() method is deprecated in JDK9. See [Java 9 deprecated >> features](https://www.oracle.com/technetwork/java/javase/9-deprecated-features-3745636.html). >> And so

Re: [Rev 01] RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader

2019-12-02 Thread Ambarish Rapte
The pull request has been updated with additional changes. Added commits: - 3ba659f0: update the catch block Changes: - all: https://git.openjdk.java.net/jfx/pull/50/files - new: https://git.openjdk.java.net/jfx/pull/50/files/b48c8087..3ba659f0 Webrevs: - full: https://we

Re: [Integrated] RFR: 8232064: Switch FX build to use JDK 13.0.1 as boot JDK

2019-12-02 Thread Kevin Rushforth
Changeset: 6892fa1b Author:Kevin Rushforth Date: 2019-12-02 15:36:17 + URL: https://git.openjdk.java.net/jfx/commit/6892fa1b 8232064: Switch FX build to use JDK 13.0.1 as boot JDK Reviewed-by: prr, jvos ! build.properties

Re: [Approved] RFR: 8211308: Support HTTP/2 in WebView

2019-12-02 Thread Kevin Rushforth
On Wed, 16 Oct 2019 17:57:58 GMT, Arunprasad Rajkumar wrote: > The pull request has been updated with additional changes. > > > > Added commits: > - 1832c2db: Incorporate fixes provided by @kcr > > Changes: > - all: https://git.openjdk.java.net/jfx/pull/14/files > - new:

Re: RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader

2019-12-02 Thread Kevin Rushforth
On Mon, 2 Dec 2019 15:03:47 GMT, Ambarish Rapte wrote: > On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth wrote: > >> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte wrote: >> >>> The finalize() method is deprecated in JDK9. See [Java 9 deprecated >>> features](https://www.oracle.com/techn

Re: RFR: 8196587: Remove use of deprecated finalize method from JPEGImageLoader

2019-12-02 Thread Kevin Rushforth
On Mon, 2 Dec 2019 20:36:20 GMT, Kevin Rushforth wrote: > On Mon, 2 Dec 2019 15:03:47 GMT, Ambarish Rapte wrote: > >> On Tue, 26 Nov 2019 15:16:41 GMT, Kevin Rushforth wrote: >> >>> On Tue, 26 Nov 2019 15:16:38 GMT, Ambarish Rapte wrote: >>> The finalize() method is deprecated in JDK9.

Re: RFR: 8232524: SynchronizedObservableMap cannot be be protected for copying/iterating

2019-12-02 Thread Ambarish Rapte
On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger wrote: > By using the collection itself as synchronization lock we achieve behaviour > that matches java.util.Collections classes. > > I've create test cases that fail with the current way of synchronizing on a > separate object. > > I'v