@mikehearn Ah, I'm using the TornadoFX plugin, which doesn't know how to deal with the module path

you could try putting all the javafx jars onto the classpath but i'm not sure that works or is tested. really they need to all be on the module path

@mikehearn I just changed to a normal

main

function, and now it works!

The command line is now:

-.kt

yeah so now the module system isn't being used at all, i think

for some reason some jars are being added more than once

Looks like it. Hmm.. then comes the question: How are we supposed to run these apps now? Only using the module system, no classpath?

basically it works like this: jars on the classpath can "read" everything on the module path, automatically. but not vice-versa.

OK

modules are supposed to be self-describing, self-contained, etc. so they can't rely on random stuff that may or may not be on the classpath, only other modules.

some behaviours subtly change when things are on module vs classpath

so the way it's intended to work is:

- javafx jars and any other modularised modules go on the module path

- everything else goes on to the classpath

then stuff should work unless it's using internal APIs, in which case you need the add opens/exports dance, etc

at least you do if you want to get rid of the warnings

however, you can put "modular" jars onto the classpath too. then they just stop being modules

@mikehearn So in a perfect world TornadoFX would be a module, but that might be hard to do because we use reflection and other tricks

reflection is still OK with modules

there are no restrictions on it. you can even reflect your way into internal APIs

it just triggers a warning

but yes ideally, TornadoFX can become a module. then it can isolate its own internal code, and it can describe its dependencies to the JVM, it can be optimised via jlink etc

modules are the future ....

I might also be running into issues because I'm trying to run apps inside the tornadofx code base, I'm not using TornadoFX as a dependency

So maybe a module is all good, but for debugging the apps in the tornadofx code base we'd just run them off of the classpath, does that make sense?

i'd suggest starting by getting a java command line that puts javafx onto the module path and everything else remains on the classpath. that'd be step one. you could try jlinking yourself a java image that has javafx linked in, for instance.

and then just use that as the jdk/jre

well it's up to you, i guess it depends a lot on support in maven/gradle

for maven there's a thing called moditect