sideload?

have it installed in parallel with jdk 8, sorry

i think sideload is a .net term or something ...

actually its also an android term, that is why I was suprised, sideloading an apk

but you download, extract and set JAVA_HOME? that what you mean?

@mikehearn OK. The problem is that jdeps won't be able to detect classes we access through reflection. I'll try to get JDK9 up and running to look for incompatibilities this weekend.

that's true

@ron well macos has an OS-specific mechanism for it

but yeah

more or less

do you have a link for that

@ron There is nothing to it really, just install it, and configure the JDK you want to run against in IDEA. No need to even update JAVA_HOME if you do it that way.

I'm going to try it now.

call me paranoid, but I prefer to keep my mac as clean and simple as possible

You can basically just unpack jdk9 into a folder, test it, and then delete it afterwards. No need to install anything.

Not even

Parent.getChildren()

is available by default in JDK9. That's a huge issue for some of the functions in TornadoFX. The exact same thing I do here was also used in ControlsFX, so I could check how they work around that for JDK9 (if they do).

Need to check

org.controlsfx.ImplUtils

They still do it: https://bitbucket.org/controlsfx/controlsfx/src/178170663fb1bf2d7e935728ab8f840e3c312922/controlsfx/src/main/java/impl/org/controlsfx/ImplUtils.java?at=default&fileviewer=file-view-default#ImplUtils.java-133

This won't work without those runtime switches either.

@edvin Will you have some time to look over the todoapp, either my version or the non-TornadoFX version of the project founder? In my version, I think I should move the items to a separate model.TodoItemModel which just manages a single collection and keep the other properties like viewable items, filter, and num active in the view model

If that's the case, maybe use the Event Bus to communicate model changes to the view model

@carlw I can do that. Will start tonight 🙂

About JDK9 compatibility. Several classes have moved, for example the TableRowSkin is in

com.sun

in JDK8 and in

javafx.scene

in JDK9. We need to form a strategy as to how we can deal with this. One approach would be to split the jdk8 and jdk9 specific stuff into separate sub-modules, so you'd use either

tornadofx-jdk8

or

tornadofx-jdk9

for example.

Another approach would be to fork, and keep updating both branches with all changes until JDK9 is out, then switch the jdk8 version into maintenance mode. We could for example keep JDK8 support in the

1.7

version range and start working on

2.0

for jdk9.

If we do that, we can start to clean up the API a little as well.

@edvin is there enough overlap to use a torandofx-core module so that changes don't have to be replicated in 2 places?

@carlw Possibly, but then it would be harder to change the API for 2.0.

Maybe both? It might be a good idea to start a TornadoFx 2 project, and potentially split it into modules, such as

tornadofx-core

,

tornadofx-fxml

,

tornadofx-controls

, etc.

@edvin can the sun-using code be isolated as @Ruckus is describing?

And just treat it as an almost entirely separate project from TornadoFX 1