No, I think that makes it hard, because we'd quickly run into the need for

tornadofx-fxml-jdk9

etc.

@Ruckus Ah, now I understand. Yes, you're right!

(Not sure if it's a good idea, since TornadoFX was meant to be lightweight, and multi-module give the impression of heavy-weight)

It might work, because we don't have that much cross cutting code.

But we are bound to run into situations where we'd need bridge modules etc.

I think it would be smart to fork for JDK9 (TornadoFX 2.0), make it work, then create a branch where we try to split it into modules to see what kind of problems we'd run into.

@edvin How so? Presumably everthing would depend on core, and it's possible some modules will need to depend on others (maybe controls requires fxml).

What do you mean by bridge modules?

Realisticly, in terms of runtime weight there won't be much gain to be able to exclude the

fxml

module for example.

That was my point about light weight. If we split it into modules, many of the modules would only be a file or two. Possibly not worth it.

@edvin @Ruckus I think the branch is best at this point which will give us more of a feel on how best to package things. The lightweight form factor is more than just Maven modules these days, but Java 9 modules.

@Ruckus Forget I said bridge modules

#jedimindtrick

😁

Yeah. In any case, modules is a separate quest from simply making it work for JDK9.

If we fork now however, how do we keep new additions to 1.7 in sync with 2.0?

It depends on the additions, but probably yes for the most part. JDK 9 won't be GA till at least July, so we can't assume TFX2 will catch a ton of momentum before then.

Unless we don't want to release new features till July

July isn't that far out, and if we focus on TFX2, we can still manage to backport important additions. If we add new features we can consider backporting or simply using them as leverage to make people upgrade 🙂

Fair

Considering 2.0 would be the branch for the future, would we keep this as master and create a branch for the jdk8 version? What's the established practice for this sort of thing?

Is it possible to make a 2.0 branch now and later swap that with the current master? I'm no git expert.

The timing of this isn't ideal though. I feel like we should implement coroutines support before we shift focus to JDK9.

@edvin I think you have 4 strategies 1. Separate repo (tornadofx-8, tornadofx-9) 2. Separate Maven project (tornadofx/tornadofx8, tornadofx/tornadofx9) 3. Profile (id=jdk8, id=jdk9) 4. Branch For option #4, I've seen some that create a 1.0 and 2.0 right away. The master is almost irrelevant. You can also keep 1.0 as the master and periodically sync with a 2.0 branch. In that latter case, one day the 2.0 branch would take over.

OK. Something to think about. Let's let it stew while we work out the coroutines support. I'll look at the Todo app first though.

@edvin the branch i wrote of earlier was more of a feasibility study on the existing structure to see what a java 9 version would look like. it might just trail off

There are some issues that should probably be addressed soon as well.

@carlw Yeah, we could actually just investigate this without committing to it.

at this point, i'd go ahead and create a branch so that we can share code. this branch wouldn't be stable at all

Good plan. Signing off for a little family time. Will start looking at the todo app tonight.

Sorry, I got busy at work

I agree with waiting to officially split the project (however that's done). There's plenty of other stuff to focus on for now, and we should probably have a better fleshed out plan on how were going handle everything afterward.