Accepting that static analysis tools are not best at finding memory
leaks...however they can find some easy to find ones. I was just wondering
if some of these can be run across the code base to find these "easy to
find" ones to help in the process.
Additionally, if there are certain checks that
Trivial fix for a compiler error where a void function returns a long
-
Commits:
- 5c066016: Trivial fix for a compiler error where a void function returns a
long
Changes: https://git.openjdk.java.net/jfx/pull/74/files
Webrev: https://webrevs.openjdk.java.net/jfx/74/webrev.00
Is
On Wed, 18 Dec 2019 16:55:30 GMT, Ambarish Rapte wrote:
>> modules/javafx.graphics/src/main/native-prism-sw/JAbstractSurface.c line 63:
>>
>>> 62: }
>>> 63: }
>>> 64:
>>
>> there are no checks on memory errors as used to be in the finalize
>> implementation. Are those not needed anymore?
On Sat, 21 Dec 2019 03:03:57 GMT, Scott Palmer wrote:
>> Interesting. I was only running the tests in graphics (gradle
>> :graphics:test) as when I run all the tests I always get this failure
>> (unrelated to anything I've changed):
>>
>>> Task :base:test
>>
>> test.javafx.util.converter.Loc
On Sat, 21 Dec 2019 18:35:26 GMT, Scott Palmer wrote:
>> I'm not sure if I'me supposed to try to integrate now that I've made that 10
>> -> 0 change, or if the new change resets the need for review... Also, note
>> that the link in the bot msg for "project specific requirements" is giving
>> m
