Hi! Yes, I am aware of that Problem and the PR was merely meant as document if someone else need a Java 9 version of RichtTextFX right now. I am also playing around with SceneBuilder and would like to also keep the codebase the same for Java 8 + Java 9. I too would go the adapter way. Having a JavaFxAdapter interface and a JavaFx8AdapterImpl and JavaFx9AdapterImpl in separate projects. Gradle then can choose which to bundle depending on the target Java version. Using the manifest a factory can then lookup which of those two class to load. Because I am on vacation for a couple of days now I can not start with that right now. Best regards, Mario Am 26.09.2017 um 20:53 schrieb JordanMartinez <notifications@github.com<mailto:notifications@github.com>>: Thanks for the PR! We'll need to update the build-related files to generate a separate build for Java 9 on Linux and Mac. However, since everyone is not yet using Java 9, we want to allow RTFX to build on Java 9 and 8 machines alike. This code seems like it will only work on Java 9 if merged. TestFX encountered the same problem: how can one build the project on both Java versions while maintaining the same code base as much as possible in cases where the API does not change across the Java versions? When I wrote TestFX/TestFX#429<TestFX/TestFX#429>, I created two packages with the same exact name and type signature. However, their implementations were specific to the Java version. Thus, Gradle would configure the core project in TestFX to use the correct internal package as a dependency based on which Java version was being used in Gradle. Using this API-adapter approach, any future changes to the core project will work in both versions of Java. I don't know if we can take a similar approach here. It depends on what we need to access and how the type signatures change between the two Java versions. However, if we can, then let's do it that way because everyone is not yet using Java 9. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#593 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEcBe-NhJf_zNucHan-gqLPP5Qhu4k8zks5smUgrgaJpZM4PkPao>.

Hi! No need to check for canAccess. I just always do … but in this case it is not required. Regards, Mario Am 15.10.2017 um 13:24 schrieb JFormDesigner <notifications@github.com<mailto:notifications@github.com>>: @imario42<https://github.com/imario42> I've rebased your PR to master and made it compatible to Java 8 in PR #614<#614> This works good so far, but I've a question regarding class GenericIceBreaker: What's the reason for checking delegateMethod.canAccess(delegate) before invoking delegateMethod.setAccessible(true)? Are there any downsides if I remove this check and always invoke setAccessible(true)? canAccess() is not available in Java 8 and I'd like to avoid using reflection for Java 9 if this check is not necessary. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#593 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AEcBexKVBvymMeAL6WUtm7v-_J6iZdHUks5ssetVgaJpZM4PkPao>.