Why are you so concerned about speed? Do you know right now that you'll have difficulty meeting a performance target on reasonable hardware?

Depending on what you're doing, Python may very well be faster than Java. I've done a lot of work with NumPy and found it to be both faster and safer than third rate roll your own numeric libraries that so Java programmers like to write. I've also had good success with Pyrex/Cython.

Assuming that run time performance won't be the determinative factor, your decision will probably come down to libraries and aesthetics more than anything else. I'd go with Python since I think it would allow you to iterate faster, but that's a very subjective decision.

As I see it the difference is that Python is a scripting language which can be used to corral functions in shared libraries. Java is a programming language with a edit-compile-debug loop. You should get things working faster in Python but get a bit more speed with Java - eventually.

I have chosen Python for a similar large, complex, evolving application - in constant use whilst under development. The key is the speed with which I can write working, tested code. With an earlier (different) project using Java, I found the APIs and debugging being a huge drag on productivity.

Surprisingly I have found performance mostly acceptable. A small number of bottlenecks were addressed by rewriting specific modules as services in C and calling them.

As it is said: "Premature optimisation is the root of all cumbersome system designs". Get the data structures right first, then implement clean algorithms. Only when you can prove that there is a bottleneck and you can't speed it up sufficiently by throwing more hardware at it, only then do you rewrite as little as possible in C/C++.

Second Michael's opinion... Some really good python libraries out there besides NumPy and SciPy. Pandas comes to mind http://code.google.com/p/pandas/ Pretty good for data analysis. Besides this, I think there was a talk on Python for the Finance world in this year's PyCon, possibly worth a look too...

If you're worried about this, you should use Jython. It gives you access to the JVM optimizer (which is awesome) and all 10,000,000 existing java libs with interop.

Native Java libraries on the JVM accessed from Jython are unlikely to be any faster than C libraries accessed from CPython. Of course, YMMV.

Java's performance is generally significantly better than Python's (although that doesn't necessarily mean you should use it, as MichaelSalib said).

Forgive me if I'm repeating things people already know, I figure someone will find this useful -

One could of course ask... Python and Java on what platforms?

Python at this point is a language specification - it has a multitude of runtimes. Java is technically a language spec as well, it just happens to USUALLY be seen executing on it's "native" runtime (Sun's JVM).

CPython is what many people think of when they think "Python" but is by no means the only Python anymore. One could (and many do - I hedge my opinion as there are good things and bad things about the GIL) argue that CPython's achilles heel is the Global Interpreter Lock (GIL): http://wiki.python.org/moin/GlobalInterpreterLock

The GIL prevents multiple threads from executing in CPython concurrently - what you actually get is a whole lot of context switching and it vastly limits your performance ceiling on multicore boxes.

However - there is Jython and IronPython. Neither suffers from the GIL limitations, and can take full advantage of concurrent threads and multiple cores.

Jython (http://jython.org/) is a Python implementation on the JVM - it's had a few development lags and only currently implements the Python 2.5 spec as far as compatibility. It is however a 13 year old project and heavily used - IBM embeds it in a few of their application servers as I recall. You also get to take advantage of the multitude of existing Java libraries. I happen to think these days the best way to parse Excel files, for example, is Jython. Use Python, but take advantage of Apache's POI Java libraries to do it ;)

There is also IronPython (http://ironpython.net/) of which I am admittedly enamored. IronPython is a project from Microsoft (who sponsors development and employs, last I checked, the core team) which implements Python in C# executing on the CLR. It also runs on Mono, and Silverlight - allowing you to run Python in the browser. See the Gestalt project (http://visitmix.com/labs/gestalt/faqs/) for examples of using IronPython + Silverlight to replace Javascript for arbitrary browser scripting. IronPython has done a good job of keeping up with the Python spec and at the moment provides full 2.6.x compatibility.

For those who want to stick with a "C" Runtime there is also Stackless Python (http://www.stackless.com/) but beware, as I'm of the understanding that it diverges from CPython significantly, where Jython and IRonPython strive for full compatibility with CPython apart from native platform libraries (This may be incorrect, I'd appreciate if someone could correct me if this statement is in error). It does however avoid the GIL by using Green Threads & MicroThreads, and Stackless Python powers much of the core programming for the Eve Online MMO.

PyPy I believe can run on any runtime so this doesn't apply to it (It's python hosted in python so any runtime that can run python should be able to run PyPy).

Utilizing Jython or IronPython would provide you a GIL-free platform for concurrency, and because the code is compiled down to VM bytecode you get a lot of free JIT help as needed.

Given you're talking about trading, being able to execute multiple threads is probably a crucial feature. The performance profile of Python depends a LOT on what you need to do and how you deploy it.

For maintainability and sanity I'm hard pressed to recommend Java, but if you wanted to go that direction you may also want to evaluate Scala which provides a lot of scalability oriented functionality on the JVM. Syntactically it should appear very "familiar" to Java and Python developers... I find it to be a bit hybrid as far as common keywords between the two.