the main issue is of course memory consumption

and the workarounds needed to minimise memory consumption

the big one that worried me from J1 was that static fields aren’t supported properly - i.e. they are common between all users

as I said to them - this is really scary for me as the author of UI controls

@jonathan Is JavaFX reliant upon static fields in places where that will be troublesome?

I fear people will fall in love with JPro when testing in localhost, but have big issues when they deploy to the web - both from a memory consumption (cost of servers) point of view, as well as users clobbering each others state point of view

sure - I have static fields in UI controls for things like remember anchor state in list/tree/table, etc

About memory consumption: All stateful frameworks will use more memory I guess, kind of like JSF, but if you can support a couple of houndred users in a single JVM I guess it might still be useful for business applications. Did they say anything about how much memory each instance will use or talk about metrics at all?

from what they say, the only way to get static fields per user is to stop sharing a class loader, and then memory consumption gets even higher

They said Scene Builder with shared classloader (i.e. no statics) is about 20MB per user instance

I really hope that they can pull this off - but I think they still have a few more technical hurdles to jump

Yeah, that's a good point. Hm.. 20MB per user instance might not be an issue for some kind of transactional applications. There would be no reason to use this tech for a high volume web frontend anyway, but I'm thinking for use cases like control panels etc this might be a very good fit.

also they don’t presently support nested event loops and (somewhat obviously) no separate stages

I see.. so apps would have to be tailored very specifically to support this I guess...

I think to an extent that is correct

you’d probably build with the knowledge you’re targeting JPro

you probably wouldn’t have a desktop app that also works on JPro

Yeah.. and that might be just fine, if the alternative is to use a web framework or some completely different technology. If you can stay with JavaFX and leverange existing knowledge and controls...

exactly

they do plan to move towards a TeaVM impl at some point too, which will bring a lot of the overhead back on to the client

Interesting indeed. It sounds like they have some incredibly talented people over there.

They should be working for you 🙂

🙂

They’re doing good work - I’m interested to see how it pans out when the licensing details are available and it is publicly available

@jonathan Do the jpro scenegraphs work with GTK or other toolkit controls?

Yes, the licensing might be a huge factor in how this turns out. Exciting times, but in any case I'm pretty happy with javapackager and I don't think distribution of JavaFX apps is difficult anymore.

@carlw I don’t know how it is done exactly

@max has left the channel

I started restructuring and copyediting the guide. @edvin your additions to Ch5 were phenomenal and the coverage of all your new goodies (rowExpander and DataGrid) was excellent. The only thing I moved to the appendix was the SmartResize. I think everything else was exactly where it needed to be.

Tomorrow at work I'm going to sweep through CSS. Last time I checked, there were a few things I didn't cover due to some things not being clear, so questions may be coming your way when I wake up!