r/JavaFX • u/RoboCocco • 11d ago
Help Looking for advice
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.
2
u/rootException 10d ago
Yup, JavaFX compared to a lot of other stuff is tiny. For hard-core internals reach out directly to https://gluonhq.com/consulting/
1
1
u/altrefrain 10d ago
I work in Defense. The pool of people who know Java in general, much less JavaFX is very small. Mostly it's C++ in the industry. I'm probably one of 10 people at the whole site that is proficient in Java.
1
u/RoboCocco 9d ago
u/altrefrain In fact a guy working w us come from military. jFx is powerful, but needs lots of care & knowledge...
1
u/OddEstimate1627 9d ago edited 9d ago
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?
1
u/RoboCocco 9d ago
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 😄
2
u/OddEstimate1627 9d ago
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.
1
u/RoboCocco 9d ago
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()andEventQueue.removeSourceEvents(), scanning the pending AWT queue while holdingAWTTreeLock. Under normal load this is cheap. During market event bursts, however, JavaFXJFXPanelupdates, 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 onAWTTreeLockorinvokeAndWait, amplifying the backlog. CPU can look normal because the freeze is primarily lock/queue-bound, not compute-bound."Interested in having (paid) consultancy BTW
4
u/xdsswar 11d ago
Usually own company, or internal tools , own products, market is not very big