And just to dig up an old discussion for old time's sake:

@melston Thanks for the PR, I will look it over soon. By the waty, it's idiomatic to call

action

instead of

setOnAction

. Not sure if the default behavior of

defaultItem

would be the best approach, will look into it 🙂

Will catch up with the rest later today 🙂

@edvin Is there a way to tell fxlauncher to just start the application if there is no network connection?

@nimakro You mean to only start if there is no network connection, or are you talking about the ability to start for the first time even without network connection?

@edvin No, let's say I started the application already once with a network connection everything is downloaded and I have a fully working app. The next time I start the application I dont't have a network connection, but I have already an old version installd so I want fxlauncher to just start the old version.

Right now the launcher ui just hangs?

@nimakro By default it will automatically continue, but the behavior might depend on your network failure mode. If a DNS call just hangs indefinitely for example, the launcher would wait for that. There might be JVM settings that can affect DNS resolution and TCP wait/timeout, or we could build it into the launcher, but my experience has been that with any network related failure, it just prints the strack trace to the console and continues. Try starting the app with a console open to see what you get there.

@edvin Oky I will check that later, thanks for the hint. A nother quick question I am using the wizard and would like to reset it after I pressed finished, I couldn't figure out how you did it in your tutorial ?

@nimakro Try opening the Wizard in a separate scope 🙂

@edvin Hehe, that's it should have thought of that my selfe 😉

This is the issue I ran into while converting TornadoFX to Java 9: https://youtrack.jetbrains.com/issue/KT-20593

@melston I added a review and request for changes to your PR. Bear in mind my current jet lagged state of mind, maybe I'm wrong, but look it over when you have time 🙂

This is the issue I created for the bug, as it affects the kotlin compiler plugin, not just user code: https://youtrack.jetbrains.com/issue/KT-20671

Guys, if you commit fixes, consider adding them to the jdk9 branch as well 🙂 We might need a better strategy for dealing with fixes to both branches though.

@edvin can we factor out the jdk8 and jdk9 common parts and move jdk9 back into the same branch?

@carlw Yes, actually once we know what parts needs to be changed that might be possible. It will take some time before I have a complete overview, but I like that idea. Don't know how others are handling this, we should look around before we decide.

how about 3 modules: core, jdk8, jdk9. drive the core+jdk8 and core+jdk9 off a maven profile

maybe "cross-platform" as the common module instead of core b/c that's clearer

That sounds good, but we need to try it practice to see how it works. "Everything" is in the same package, so there might be complications.

I've seen multi module projects putting code in the same packages (specifically Talend Open Studio)

that's why i think it's important not to call it "core" because we're really not affecting the logical model, but rather the component model to support the build and compiler

Good point indeed.

I can't complete the Java 9 port until Kotlin 1.1.60 is out due to the bug I found. It's quite tedious to use the command line compiler all the time 🙂 I have a lot of work I don't need to run the code for though, so I'll keep busy.

@edvin do you think it's worthwhile to merge the two codebases? the java 8 profile would still compile and work as it does today while the java 9 profile would be broken until the kotlin fix is made

i had some bad experiences going from Java 7 (javafx 2.2) to Java 8 and managing two separate artifacts

Any opinions on the channel? Is everyone hanging out on Java 8 for a while or jumping on Java 9 right away?

@carlw I don't think that would be nice in practice, again due to the same package issue. It would also make it harder to make subtle changes and start removing deprecated features etc.

maybe a proof of concept? I have to do something like this for a client in the upcoming weeks. my recommendation is to make things easier so that you could remove deprecated features in only one place

As I understand it, this would require us to merge several files with the same name, so I don't see how that can be done within the confines of Maven/profiles. At least not while retaining sanity 🙂