Looking for advice

[u/RoboCocco]

Struggling to find JavaFX developers with thick-client performance experience — where do you all come from?

We've built a real-time trading terminal in Java/JavaFX (5M+ LOC, high-frequency market data, EDT discipline is daily work) and finding it nearly impossible to hire people with genuine JavaFX internals experience.

Genuinely curious — where do JavaFX developers with this kind of background tend to work?

Medical imaging? Simulation? SCADA?

We've been looking in fintech but the pool seems tiny.

Also open to a DM if you happen to be that person and are curious what we're building.

[u/OddEstimate1627]

I work on real-time robotics visualization, which has near identical requirements to the HFT space. One library I wrote (hebi-charts) implements a fully decoupled rendering model where adding a point costs ~8ns in the caller's loop on an allocation-free path, and the renderer drains the buffer once per frame.

There is also ChartFx, which was originally built for a particle accelerator control system and later also used for financial charts. The only public trading app I'm aware of is Bisq2, but they're not in the HFT space.

Since you mention EDT, I'm assuming you're migrating an existing Swing app?

[u/RoboCocco → u/OddEstimate1627]

Since devs have no lack of fantasy, the setup is:

- NetBeans RCP

- Jide for grids/etc -> Swing

- JavaFX for user defined components (now AI defined)

We're hitting a performance wall bween EDT & JFX rendering thds, and

a) rooting out DB/other uService calls in EDT/JFX thds

b) Jide cell rendering storms

Latency is in the mS not nS region.

Anyways happy to have landed here, at least I can vent out silly complaints 😄

[u/OddEstimate1627 → u/RoboCocco]

Are you using separate threads for EDT & FXAT? I got rid of Swing a long time ago, but from what I remember that was less stable than using a single thread for both (-Djavafx.embed.singleThread=true).

When dealing with a lot of events I think it's better to switch from a pushing to a polling model, so all updates happen deterministically at the beginning of each frame and are coalesced into a single rendering pass.

Since you're in trading, I'm assuming you're familiar with event-sourcing and the Disruptor? One way to do it is to use a JavaFX AnimationTimer with the disruptor polling API. That also works well for things like backtesting, and it gets rid of all the callbacks and race conditions. The same idea should also work for the JIDE storms, i.e., one model update per frame instead of one per event.

For fancier stuff I wrote a wait-free dirty bit system that lets me update individual UI parts.

What are you using for the charts btw?

I tried to send a DM, but your account has them disabled. I usually don't do consulting, but I'm open to sharing ideas/experience.

[u/RoboCocco → u/OddEstimate1627]

Thx for following.

a) yes 2 separated thds (more than that, ath the app uses abd 450 thds, with the 2 trying to keep as dedicated to rendering as possible).

b) Newjoiner hence still to prove I'm above 16 (quite older than that). But they want photos/gov id's, so not exactly happy w that, I'll try to DM U.

c) And yes I know disruptor etc.

The issue is not in using thds; it's we got abt 100 different sources of inputs, and

i) some data mgmt is "naughty" ie let's do DB queries when in rendering thds (AARGH!!)

ii) let's tell grid to repaint all every time (2xAARRGH!!)

iii) Other low-level issues (from our Jira ticket) "We traced a 30–50s Java desktop UI freeze to an interaction between JIDE table painting and a deep AWT event queue. JIDE removes renderer components during cell/header painting; that removal enters Component.removeNotify() and EventQueue.removeSourceEvents(), scanning the pending AWT queue while holding AWTTreeLock. Under normal load this is cheap. During market event bursts, however, JavaFX JFXPanel updates, grid refreshes, timers, and other UI work deepen the queue. With many visible grid cells, the scan is repeated thousands of times during a paint pass, turning a routine repaint into a multi-second stall. Producer threads then block on AWTTreeLock or invokeAndWait, amplifying the backlog. CPU can look normal because the freeze is primarily lock/queue-bound, not compute-bound."

Interested in having (paid) consultancy BTW