Java for Quant Development?

Java is an all-purpose language. Check out jQuantlib and Marketcetera to get started.
All quant code in banks is in C++ , you will have better chances of a getting a
job if you do. Why software technicians keep asking the same question and always the answering the same things.
Quant job = C++ mastered. Most quants use Python for tools development & C++ for core apps don't kid yourself. Primary focus on performance is applicable to high frequency trading and market making systems.C++ is not always the fastest, in fact its predecessor C wins almost always hands down. Even there the bottle neck is networking and messaging not computation.

C++ code tends to be harder to understand and to express a mathematical problem in. Quants will find it that functional languages such as Haskell let them think about the problem rather than about language syntax.

Not that Java is that much better in this department as it yields verbose code. Java however has a huge advantage existing libraries and of a very robust software development toolbox for unit testing, continuous integration, refactoring and build process. The last one in my particular issue with C/C++. Fighting linker errors and dealing with messy makefiles create so much noise that performance gains pale in comparison.

If anyone here has a proven "system" for working with large code base of C/C++ code including third party libraries please post.

I must be in a bad dream? Or many of you are just confused in general about how things work on Wall St. Many sophisticated quantitative and computational finance work done today by the top buy side firms who are trading proprietary capital use C++ for core systems development. C++ will usually make up a bulk of the code base at these shops. Think stat/arb desks and market making firms. I can't think of any arb desk or MM firms today who has built their core systems on Java that is actually profitable.

Many algos developed at many firms for client facing order flow like DMA, dark pools, smart order routing etc.. Are usually developed in Java, C#, .NET etc.. and many of the tools and GUi around these systems. There are many reasons for this like better interoperability between GUI and back-end systems, larger pool of lower quality developers, client facing tools usually require much more customizations and rapid changes for client needs speed usually isn't the #1 priority compared to feature set.

Many firms today employ the same people an everyone is using very similar models in the end it's all about speed.

Plain and simple C++ allows a skilled programmer to squeeze much more optomizations out of his code than he could if using Java or C#.

Rodrick what you say is correct but is biased toward electronic markets like equities, futures etc. If you venture a little bit out of there into OTC traded fixed income and fixed income derivatives speed does not matter nearly as much. Sweet dreams.

Definition (wiki): "A quantitative analyst is a person who works in finance using numerical or quantitative techniques."

There is life outside Wall St(US) ;-). Also, there is front end, back end, trading, risk management, quants working for hedge funds, for trader, for rating agencies, for insurance companies, from high frequency to macro-economics, from research to day-to-day business and so on.

I don't understand this quant == trading (front end) + C++

Besides, all the statements without facts make discussion complicated. (E.g. Java is faster than C++, ok but the actual questions is how much).

Rodrick, again, if performance is the 'Key' for making money why you don't use assembler ? why C++ ?

In reality, JAVA or C# has capable to substitute C/C++, but since on Wall St. many sophisticated quantitative and computational finance application were written by C/C++(as Rodrick mentioned as well), therefore, it isn't necessary to spend money to convert all codes into JAVA or C#. JAVA is essential designed for web-application, C# inherited lots of new feature both of C++ and JAVA have(Initially for MSFT want to give a capability for all other type code converted into) . Look into JAVA & C#, they are just similar as C/C++ but adding some more features only.
If you pay attention to today's financial application, you might be able to find out certain new financial application's baseline code is done through C#.

Answering various questions:
David, you are right to ask the % difference, and as someone who used to review programming language implementations for PC Magazine, I can tell you with some authority that you cant get a good simple number.

The problem is that it's a differential equation with boundary conditions, and subjective.

In almost all cases, Java could be faster than C++
It isn't because the people who build the compilers and JVMs don't really take performance all that seriously.
This is unintuitive I believe ?
Fact is that C++ compilers waste a lot of clock cycles because they cannot know the nature of the machine they will run on. In fact you have to tell it what processor at compilation, and subtleties down to various numbers and cores / CPU cache can only be expressed by unpleasant code.

JVMs *could* do this because they know the machine they are running on.
But they don't.

The maths comes in because we have two time terms here.
Time to develop the code and time to run it.

Most code is simply irrelevant to the execution time, so if you free up the programmer from certain tasks which consume his effort, he has time to write faster code.

That I think answers the assembler vs C++ question, I believe the CQF is the only finance course that covers x86 assembler at all, and even we don't do al that much.

But.of course I can stick bits of assembler into my C++, which is something I do very sparingly, and if you find that a headhunter is writing code that goes several times faster than yours, consider despair or more education :)

So to test Java vs C++ properly you'd have to apply a time constraint to the development teams. Also you'd need to have equivalent skill in the teams.

Although Java has some features that some feel make it easier to develop, there is a surprising lack of objective evidence.

Partly I think this is because most of Java's "easier" features can seriously get in the way when you really care about speed. When I delete an object, I want the fucker dead *now*. At the limit I want to be able to tell the compiler how to translate my code, and if necessary I want to access useful operating system features.

Another factor is of course that hardware is typically cheaper than programmer time, meaning that a few cores can do more for you than changing language.

Back when I had the chance to get input into the new version of Excel, I fumbled the case for making VBA multi threaded, sorry. The reason I cared is that VBA is the 2nd most important quant language after C++, and although Excel >= 2007 is threaded, you only have one VBA instance :(

I believe the fact that VBA is #2 supports my case rather well. One can quickly knock together some code that mostly does what you want in an acceptable time. It interfaces nicely with spreadsheets (something Java doesn't), and can talk to every data source on the planet.

But Java programmers are cheaper, hard to quantify this is precisely, since on average they are less skilled and experienced, but a three year experienced Java programmer may easily be on 1/4 that of the C++ guy.

If anything, that ratio is increasing

This alters the economics. Tasks that do not require advanced techniques or high performance can be done as well in Java / C# as in C++, but more cheaply.

This is why banks use packs of cheap Indian programmers for housekeeping IT.

I didn't mention I used to be a CIO did I ?

I mention this because there is a clear division in the advice I give here.

Firstly, if you are a CIO, using Java allows you to buy cheap, medium quality programming time overseas. It also provides a good blame sink for the inevitable screw ups.

As a CIO you have no interest whatever in providing efficient reliable systems, indeed the techniques necessary to do so will hurt your political position.

But if you are writing code, Java is your enemy.
The function (supply, demand, substitability) = bad.price

10 things all JAVA developers should know

1. Remember the basic of JAVA language and OOP paradigm.
Most experience developers seem to forget the theory behind the language. I am not saying that they are not good at their job but can they explain to junior developers why they have used interfaces instead of abstract classes or why implement a pattern over another one? As a programmer, you become very arrogant as you believe that you write the best code but in the real world, people work in teams with different skill set and experiences. It is important that you can backup your actions/ codes. A very simple question such as; when should I use a String object instead of a StringBuilder/ StringBuffer? You might take this question lightly but can you actually tell someone else the difference?

2. Know your technology stack
All developers have to know their technology stack. What does it mean? JAVA is not like other languages; JAVA has subsets such J2ME and superset such as Java EE. We have our own area of expertise but it is important to know the differences between the various sets of JAVA. Some basic questions such as the differences between SWING, Applet, Servlets, EJBs and JAVAFX will boost your confidence. Most developers do not know how to tweak the JVM and the differences between the JRE and the SDK environment. Do you know why you need the SDK to be installed to run Tomcat but you only need the JRE to run an application?

3. Experiment with various Java EE framework
I am not asking you to be an expert in every single Java EE framework but it will make the difference if you are familiar with Spring and EJB. That should actually be the de facto framework that should be on every developers CV. Developers should know the difference between Java EE 5 (soon 6) and Spring. Hibernate is also brilliant and it's used for data access but all developers should have moved to JPA by now. Hibernate also comply with JPA therefore there is no more excuses.

4. Know a scripting language
JAVA can be heavyweight for some simple tasks which can be implemented using a simple dynamic language such as Python, Perl(?) and others. I would also recommend to developers to learn shell scripting on their target OS.

5. Know how to develop web services
The network is the computer, therefore it is important to know the different web services framework available. Data are integrated through web services and opening your services to the "cloud". SWING developers will probably not develop web services but I am sure that they will be connecting to data through web services clients. Understanding the difference between the standardised SOAP and non-standardised ReST will help you choose which is best to implement your services.

6. Know how and when to multithread your application
I have to put that in there. Developers should know when and why to multithread an application, thread inter-communication and monitoring. All developers, junior or not, should know how to write a multi-threaded application.

7. Database development using JDBC and JPA
This should be a development law. All developers should know how to write SQL queries and how to create databases. All enterprise applications store data in some sort of relational database systems and it is therefore imperative that this knowledge should be of second nature. Java EE 5 introduced JPA (JDO was there before) but it is not applicable to all situation. Hence, knowing the difference and when to implement one instead of the other is important.

8. Know a client side scripting language and what is AJAX
The network is the computer and Internet is the deployment platform. Java EE and its various framework are server side executiong which can put extra "load" on the server. If you are looking to move a cloud based system where the providers charges you per resources used, it might be wise to move some of the execution to the client side. AJAX has been buzzing the scene for the last 3 years and more. This is not a technology but a new way of doing something that already existed. There are numerous JAVA AJAX framework such as GWT and DWR which makes it easy to develop AJAX based application which are compiled to JavaScript. Developers should also know what is the AJAX theories.

9. Know your competitors and do not take part on "what is the best IDE" discussion
JAVA is not the only language that can do what it does. I think that JAVA is more mature and complete as opposed to other languages. Knowing the difference between JAVA and .NET or JAVA and Ruby is a good asset to have. You also need to know when and why to use one instead of the other. Please please please, do not get into "my IDE is better than x because..." discussion as it is good for the JAVA community to have multiple IDEs and framework available to use. Every tools have their place as for example JDeveloper is better than x if you are going to solely develop on an Oracle stack and etc...

10. Know ANT (MAVEN?), TOMCAT and any other mainstrean application server
ANT is the de facto build script for JAVA and its IDE-based development. Maven is becoming popular and soon can be as popular as ANT (not sure of its popularity in the financial sector). TOMCAT should be immortalised as the based servlet container that all developers should be familiar with.

There are alot more to add but this is just some of the basics that I think all developers should have in their repertoire. Feel free to add to this list in the comments box. If I could had another one to this, would be; all developers not just JAVA, should know how to search the web and Google is your best friends.