Anyone use JAVA to develop there automated trading systems?

[dholliday]

Hello,
I'm learning to code in JAVA with the plan to create an algo trading system using JAVA + Interactive Brokers API. I would like to know if anyone used JAVA to code there automated trading systems? I mainly hear of people using Python for algo trading. Anyone have experience with JAVA and could point out the pro's/con's of coding a trading system using JAVA vs. Python?

I use Java. I was a C++ programmer for many years. I would choose Java/Kotlin or C# but C++ or Python are fine depending on various factors.
Fewer lines of code should not be your goal. Readability, maintainability, extensibility, etc. should be.
Python was designed to be mainly a quick language for smaller (whatever that is) projects. There are many libraries to help you achieve your goals. There are many books and online resources with examples of how to do trading apps, etc. (I have some books by Howard Bandy). Unless you have a need to watch every tick of thousands of symbols with lots of calculations on each tick you may not notice the difference between Python and Java (you would have to do a lot to care).

Java is very much used in the industry of trading. Usually for larger projects or for when there is a need for speed and no compromise (when those standard libraries don't do what you want or in the way you want). You will notice the difference in speed, between Python and Java, when doing backtesting/optimization of large amounts of data.

I do think Java/Kotlin, C#, and Python are by far the best choices for most traders.
There are lots of things to consider. One is, are the available libraries sufficient for your needs?
Ex. If you find a library (or code) to buy/sell with IBs API. Does it track the trade? What does that mean?
When you buy you send a message to IB. Asynchronously you (may) receive massages of failure, partial fills, buy complete, etc. What happens if your machine crashes in the middle of these messages? What happens when IB disconnects in the middle of these messages. What happens when you short and IB can't find shares to borrow? Then, fifteen minutes later, they find the shares that you need, and they short. There is much more... How do you handle these scenarios?
What about when the power supply in your machine pops in a cloud of smoke in the middle of a transaction? Can you start a new machine and access your trades state and recover what has happened?
The libraries in Python (and Java) are enough, but few of them do what I want for high-performance robust trading systems.
I still don't have a suggestion for you, but you are correct to do some research so that you don't regret your decision.

 

[ET180]

Definitely agree with everything you said here.

Just adding that Visual Assist is what makes coding in C/C++ pleasant, speeds up the programmer 2-3 times. Ironically that's due to providing features that IMO should be in all IDEs: Near instant symbol look up, references look up, text search, etc. Whereas default Visual Studio struggles with the C/C++ complexity and has unbearably slow (and erroneous) symbol look up.

Also, when using memory handling features of the newer C++ releases you get away from the nasty heap corruption issues plaguing code that uses new/malloc/delete/free. So while I used to hate C++ a decade ago and went as far as declaring it a doomed language, it's pretty neat now. The old stuff is still there in the language and confuses newbies though, a bit like all the noise about how you just need to add the right magic indicator to your screen in trading to become successful hurts newbie traders.

I'll look into Visual Assist. Visual Studio 2019 does the bare minimum for efficient C++ development, but Eclipse for Java automates a lot more of the things that should be automatic. I suspect that might be somewhat intentional -- to push people towards C# and to maybe support 3rd party extensions.

STL and the more recent versions of C++ have made programming in C++ easier. But macros, pre-processor stuff and handling cyclical / co-dependent include loops suck. That part needs a refresh.

 

[guest_trader_1]

I develop in c++ as well. Mainly because that is the language I was trained on initially, but these days I have to find a really good reason to not to use Java or C#.
Visual Studio made a massive improvement compared to what it used to be developing in the early 2000's, but as a test try to develop c++ on any Linux flavour and you will feel the pain.
Those days where using the most difficult language made people happy are gone. Today's code must be efficient and easy to write, otherwise people will choose another language.
You might find a better reson to use c++ in other fields , like hardware development, gaming or robotics but for trading it is simply not necessary.
As algo traders we are always limited to use a gateway to the markets that usually limit your number of interactions you can have. If we also include network latencies c++ simply does not stand an edge against any other language when it comes to trading. Using it is simply a way to make your life difficult.

 

[Aquarians]

Hello,
I'm learning to code in JAVA with the plan to create an algo trading system using JAVA + Interactive Brokers API. I would like to know if anyone used JAVA to code there automated trading systems? I mainly hear of people using Python for algo trading. Anyone have experience with JAVA and could point out the pro's/con's of coding a trading system using JAVA vs. Python?

I develop in Java, both a backtester and live auto-trading system using Interactive Brokers.

i chose c++ instead of Java. I made mistake

I know what you mean. I still program in C++ at my job and sucks massively and perhaps that's why I have a job. Anyways, at least I'm paid to get tortured, but why on Earth would I do that to myself by my own choosing?

Java is very much used in the industry of trading. Usually for larger projects [...]

Python is for toy projects, period. Once the project gets complex, it'll make you hate life almost as much as C++ due to the lack of static type checking.

Overall Java is best of both worlds, fast enough for all jobs except hardcore HFT which you can't touch anyway as a retailer with a great IDE (IntelliJ), filtering out 99% of the crap that C++ hits you with and capable of handling huge complexity (unlike Python) while still maintaining comprehensibility.

Only one problem I have with it (and Python suffers for it as well): you can't hide the source code if you want to sell proprietary software. By default the library files (JARs) that the compiler generates are fully decompile-able. You don't see the exact names of the variables but the code is exposed. I can look inside the JARs of Interactive Brokers and see how they are implemented almost as easy as looking at the exact source code.

This is one problem I need to figure out for my software, which I plan to sell at some point (at least parts of it). I know there's obfuscators and such but don't like the idea, I think (sadly) the only way to keep code proprietary is have it run on your own servers and give the customer only a thin client for it.

 

[trend2009]

I develop in Java, both a backtester and live auto-trading system using Interactive Brokers.



I know what you mean. I still program in C++ at my job and sucks massively and perhaps that's why I have a job. Anyways, at least I'm paid to get tortured, but why on Earth would I do that to myself by my own choosing?



Python is for toy projects, period. Once the project gets complex, it'll make you hate life almost as much as C++ due to the lack of static type checking.

Overall Java is best of both worlds, fast enough for all jobs except hardcore HFT which you can't touch anyway as a retailer with a great IDE (IntelliJ), filtering out 99% of the crap that C++ hits you with and capable of handling huge complexity (unlike Python) while still maintaining comprehensibility.

Only one problem I have with it (and Python suffers for it as well): you can't hide the source code if you want to sell proprietary software. By default the library files (JARs) that the compiler generates are fully decompile-able. You don't see the exact names of the variables but the code is exposed. I can look inside the JARs of Interactive Brokers and see how they are implemented almost as easy as looking at the exact source code.

This is one problem I need to figure out for my software, which I plan to sell at some point (at least parts of it). I know there's obfuscators and such but don't like the idea, I think (sadly) the only way to keep code proprietary is have it run on your own servers and give the customer only a thin client for it.

i totally agree with every word you said here. One reason I chose c++ at the first is that I do not want to expose my code. now that concern is not a big issue anymore since I have no plan to sell to anyone, so c++ becomes ugly to maintain.

in my c++ project which uses iqfeed datafeed, I wrote the connection from tcp/ip listen from bottom up, what a pain.

 

[Aquarians]

in my c++ project which uses iqfeed datafeed, I wrote the connection from tcp/ip listen from bottom up, what a pain.

It can be fun to write something from the (low level) ground up as it teaches you the inner workings of things (I have done it too ). But in the end it's similar to data structures and algorithms like implement a quicksearch or a hashtree, apart from job interviews you're better off just using some library implementation and concentrate on business logic, coze that's what makes the money. Time spent on implementing a message broker is time not spent on experimenting / implementing some algorithmic trading strategy and it's the latter not the former that will make you money.

 

[georgio6]

Hello everyone,

I have used the IB API to try to develop a frontend for orders, and add some automation. To be honest, it seems very buggy, and with no documentation. For example to make a limit order, I have a call to the limit order, and then an infinite yes answer to every question the IB API might return (It can be 2-3 times, when I make a limit order, I'm sure I want to make it, I don't want any stupid confirmations).

Do you have this kind of issues with Java or Python?

 

[HobbyTrading]

Hello everyone,

I have used the IB API to try to develop a frontend for orders, and add some automation. To be honest, it seems very buggy, and with no documentation. For example to make a limit order, I have a call to the limit order, and then an infinite yes answer to every question the IB API might return (It can be 2-3 times, when I make a limit order, I'm sure I want to make it, I don't want any stupid confirmations).

Do you have this kind of issues with Java or Python?

No. Maybe you can show an example of the kind of messages you receive back from the API after submitting an order.

 

[dholliday]

Hello everyone,

I have used the IB API to try to develop a frontend for orders, and add some automation. To be honest, it seems very buggy, and with no documentation. For example to make a limit order, I have a call to the limit order, and then an infinite yes answer to every question the IB API might return (It can be 2-3 times, when I make a limit order, I'm sure I want to make it, I don't want any stupid confirmations).

Do you have this kind of issues with Java or Python?

Never had a problem with the API in Java. Seems very solid. That said, writing code to buy/sell, short/cover in a robust manner can be a big job, even for programmers.

 

[Aquarians]

Never had a problem with the API in Java. Seems very solid. That said, writing code to buy/sell, short/cover in a robust manner can be a big job, even for programmers.

Precisely. Writing something like "when condition met, trigger orders" is relatively simple. But handling error and marginal cases can get very complicated. Real orders especially large ones can be filled over time at different prices or only partially if the market moves away from your limit price, which requires pretty convoluted logic on what to do in such cases. Then there can be application crashes or just disconnects, so you gotta catch up and reconcile your position with the brokers. Not trivial.