The architectural and modeling approach of a trading application are not specific to the Java APIs or to a particular language. However, to illustrate my point with contents, I had to make technical choices.
– The display of graphics will be performed via the JFreeChart API.
There are other ways to proceed. Some JavaScript API are particularly powerful and efficient to display and manipulate financial charts.
But JFreeChart has an advantage over the others: it is correctly documented on the web.
– The general graphic rendering (windows, buttons, lists, signs, etc …) will be based on Swing.
JavaFX or a web page rendering library can also do the trick.
However for simplicity of deployment (no container) and commonly shared knowledge (Swing is more documented and known than JavaFX), Swing is a very good candidate.
Swing being rather poor in widgets, it is essential to enrich swing of third-party components. It can be done using external components or developing our own components. I personally practice the two options according to my needs.
In terms of add-on for Swing, I use the SwingX library.
It was developed in SwingLabs and is globally mature today. Unfortunately, its maintenance and its developments are increasingly rare. So on a lot of projects where I intervened, I had to create a patched or upgraded version of components. As part of creating a minimalist trading application, the latest version of SwingX is sufficient. I give here rather tracks …
– The format of data files will be functional csv.
Again, other alternatives such as xml, json and nosql could have done the job.
Using a relational database is also a possibility, but it requires many tricks to keep good performance on large volumes.
On a significant volume of data to process, NoSQL is a prime candidate: data are naturally distributed (unlike a CSV stored on a local computer) and performance is very good. But, this is a technology that I think relatively little known and little mastered too in general. So using it would complixify the course without adding a great value for a bootstrap application.
Indeed, its use is more relevant for the development of a trading platform with data shared by a significant number of users, for high frequency trading or to handle the roaming aspect (using the application from multiples clients).
Here, we are building a heavy-client application to be used ny one user on one machine.
As it’s an interesting topic, I will try later to present a good use case for a NoSQL base in a trading application.
In our case, an application with non-distributed information (as used by the trader on his local post), using flat files is perfect.
Data being tabular (for a stock quotation, we could have for example : label, isin code, closing price, volume), the CSV format is clearly better than the XML or JSON formats in terms of performance (fewer bytes to read for the same information) and readability. It was therefore naturally retained.
– The library for handling csv is supercsv
The available libraries (Commons CSV, OpenCSV, etc …) to manipulate CSV are quite similar in terms of functionality. Unless you have very large volumes of lines to read and your application does not use any cache system. In these cases, you should fully optimize this processing chain and benchmark each library or do not use lib at all and do this treatment at hand.
This goes without saying but a complete trading platform usually entails the use of a large number of third-party libraries and or the rewriting and the extraction of components from some third party libraries.
The issue of extracting or rewriting third-party public libraries is a subject very interesting and often forgotten. We often underestimate the gains in terms of optimization of processing time and memory consumption.
This topic will probably be the object of articles in the Java development practices section .