My understanding for how to split this project into a JDK8 and JDK9 was to create a core module (which is most of what testfx-core is) that has an interface that can properly handle the internal issues (e.g. InternalJava), and then have a JDK8 and JDK9 subproject that implements this interface for that specific version. Then, when creating a Java 8 build, one only uses the core + JDK8 packages; for the Java 9 build, one uses the core module + the 9 module, ignoring the 8 one.

However, I'm not sure whether that's possible and thus whether it requires things to be done like how you've done here.

Yes, I definitely want to consider other approaches. Just wanted to play around with this approach - will hopefully have time to experiment with others. This will stay [WIP] until we come to a consensus and make the most logical decision.

Sounds good!

Here's my idea:

public interface JavaVersionAdapter {
    public boolean isVisible(Node node);
    public int convertKeyCodeToID(KeyCode keycode);
    public Iterable<Window> getWindows();

    public static JavaVersionAdapter getAdapter() {
        return new JavaVersionAdapterImpl();
    }
}

Then, in two separate subprojects, we can have the implementation for each version that uses the correct method names.
We could then modify the testfx-core.gradle file to add a dependency to the corresponding java version subproject based on which java version is being used. To make this easier, we could add a separate task that properly configures the build settings so that either the 8 or 9 version is built. Then, one can specify which java version of the core they want and use it alongside of their test framework.

Would you have time to open a PR? I'd like to compare the two, but I am heavily favoring your approach.

I believe I could, but perhaps next week, not this one. There are some other things I wish to do on a personal project.

On another hand, I don't think we should use an interface. When accounting for modulation, it creates a cyclic dependency. If we put the JavaVersionAdapter into the testfx-core project, testfx-core-java8 needs access to testfx-core but testfx-core needs access to testfx-core-java8 when building with java 8. Thus, we would have to put the interface in its own package, but this creates "boilerplate directories."
Since we're not exposing it to the public world, just to TestFX itself, we should just use a class since there would only technically be one implementation (depends on which java version is used). If we ever need to change something in testfx-core that affected the implementation (e.g. add/refine API due to changes in the JDK), we'd be forced to change both of them. If we use a class approach, then the dependency arrow only points one way. testfx-core-java8/9 <-- testfx-core

Also, I think that following my approach will make the IDE complain. It may detect that there are two classes with the same fully-qualified name and, depending on which java version one is using, it may complain that the opposite version's implementation is using non-existent API. When it's built with Gradle, that shouldn't be an issue. However, trying to use the IDE to run various things may slow development because the IDE may stop at the compilation phase if it detects the non-existent API.

Closed in favor of #429