Would it just be better to run some code analysis tools on the code base to hunt for these? Like maybe sonarqube integratedas part of CI build analysis?
Eric Bresie [email protected] > On December 19, 2019 at 4:23:14 PM CST, Florian Kirmaier > <[email protected]> wrote: > On Thu, 19 Dec 2019 19:59:07 GMT, David Grieve <[email protected]> wrote: > > > > Yes, exactly. > > > > > > @FlorianKirmaier Proposing to add test class to the test infrastructure > > > would be a reasonable alternative to pulling it in as a third-party > > > dependency. I recommend separating it out into its own enhancement, with > > > a separate JBS issue. I see that it has a dependency on the > > > `jdk.management` module. As long as that dependency only surfaces as a > > > test dependency, that won't be a problem. It would be nice if it were > > > available to all modules, meaning that putting it somewhere in > > > `javafx.base` would be good. > > > > I would urge caution about incorporating JMemoryBuddy without seeking out > > advice from GC experts. I have my doubts that it will work reliably given > > its reliance on System.gc(). (Opinion is my own, not my employer's). > > @dsgrieve > It's worth mentioning that JavaFX already has many tests based on System.gc(). > An advantage of having a testsuit as an library (or copyied from an library) > is, that its stability is regulary verified by the travis builds for > different JVMs. > The alternative would be to not test for memory-leaks at all which is much > worse than having slightly unstable tests. > Maybe it can make sense to seperate these tests for leaks in an own testgroup. > > I'm introducing this library in more and more projects. I never had problems > with unstable tests. > I only had this kind of problem when I wrote the > WeakReference/System.gc/sleep-logic for every single test. > > ------------- > > PR: https://git.openjdk.java.net/jfx/pull/71
