I am not an expert in Java. For those that are, if you had to write an open source program that used a GUI interface to display real-time option chains, what GUI libraries would you use to display a grid so that it reached the greatest number of people so they understood the code, and worked on multiple platforms like Mac OS, Windows, Linux, etc? Would that be, Swing, AWT, or something else? Thanks in advance.
I not an expert in Java either. Both the thinkorswim platform and IB's TWS are based on Swing and both display "real-time" option chains. Having said that, Swing's JTable wasn't exactly performant last time I looked at it (a long time ago) SWT is perhaps a better option IMO. Though it might fail your second requirement of being comprehensible by the most amount of people. Dug up a very old post about JP Morgan using the Eclipse RCP and hence SWT for their trading platforms: http://wallstreettechdaily.com/2006...r-than-swing-and-net-for-the-trading-desktop/
JTable performance depends almost entirely on your table cell renderer which is by default a JLabel. You can improve performance by fiddling around with the cell renderer. I don't have any performance issues with a JTable of 100 or more high volume stocks (inc SPY, QQQQ etc) showing bid, ask, bid size, ask size, last etc - even during first few minutes of market. Q9550 CPU easily copes with a large amount in reserve (< 20% CPU utilization max with other stuff running as well). I reckon it's probably "good enough" on modern CPU and graphics card. But it might be advisable to set some performance requirements and run some tests before committing to any one path. I don't have any experience with SWT, but I think I have read comments about cross platform issues. Swing *might* be better in that respect.
I've been playing with Eclipse's SWT framework. The issue was that somehow Swing never quite registered with me; it might now. SWT's big claim to fame was native controls; stuff that looked like it was a native application. Swing used to have some odd look to it, but I hear they've improved that considerably. I've had a few problems with SWT. A lot of my text boxes had a lag to them. That could be some handling I put in, but the file management dialogs also run surprisingly slow. Just typing in a filename lags way to much. A lot of other components are fine. You'll want to look into resource usage too. I have a viewer that lists all equities across all exchanges in a table, with some GUI controls on opening up a chart on them, or doing other things. This window will starve itself out and die sometimes, even when I bump up the heap. My big gripe with Java GUI work is that without something approximate function pointers, you find yourself having to create anonymous classes, with all the extra scaffolding, in order to feed a lot of the event-driven messaging that GUIs tend to use. It's a little bit messy for a language that was trying to clean things up.
NONE of the standard components will be at enough. THis is not a Swing issue - it is an issue more in the line of common sense. Basically, trading applications are very specific in their requirements and demands. Generic components will never be fast enough, unless they are perfectly optimized for that. A generic grid in general will pretty much blow