also there are a bunch of tools and other frameworks that have upgraded to 11 and started using new apis, so we want to follow them

+ jvm improvements in general, in particular, for Corda, 11 will let us simplify our programming model somewhat so we're looking forward to it

@mikehearn Cool, yeah it needs to be done. I'm stuck on something I don't quite understand and haven't had a time to look further at the moment. If you have time to check out and try to run some of the test apps in the framework I suspect you might spot the issue pretty easily? 😁 I think the error message I was getting now was that it couldn't find the JavaFX runtime, though it is clearly on the class path.

i'll have a play with it once i've got graviton 1 shipped. my last bug is some weird graphics issue that's linux specific

@mikehearn Any help getting over the hill here is greatly appreciated 🙂 I know a lot of people are waiting for J11 support

I'm wondering how you handle different platforms with JNI

ship different binaries along with the java code

and set up your java.exe call with different library paths

If I have a tree of immutable items (

class Foo

) displayed in a

TableTreeView

, and I have a

Label

(outside of the

TableTreeView

) that should display the result of

Foo::getSomething()

(which returns

String

) of the selected tree item (and update when the selection changes). Is there a way to bind that to an observable? Or do I have to write a listener to do the update?

I did it with

label().apply { bind( property = model.itemProperty, readonly = true, converter = object: StringConverter<Foo>() { /* toString calls Foo::getSomething() */ } ) }

. Is there a better approach?

@edvin which branch do you recommend to test on for Java 11 compatibility?

(debugging I mean)

@sbyrne What about

label(model.itemProperty.stringBinding { it.getSomething() })

?

@bjonnh The Java 11 branch is called jdk10

thx

Does anybody know how

javafx.stage.Screen.getPrimary()

decides which one is primary? It clearly isn't getting it from

xrandr

.

AWT gets it right.

JavaFX doc is so bad…

Screen.getMainScreen() is what is in Quantum (not sure it is that in JFX8)

well, that explains the behavior I'm seeing.

Getting the bounds from the primary device according to AWT and matching that to a JavaFX screen to get the primary seems to work.

you are using gtk?

I wonder how that works: @Override native protected Screen[] staticScreen_getScreens();

I'm using whatever is default.

rebuild_screnes

screens

that

from what I see here, assuming it is using GTK (I have no idea what the default is)