3 ms·

As a counter-argument, why NOT use Java? You have multiple free and open source implementations to choose from, and there’s a library on Maven Central for almos

As a counter-argument, why NOT use Java? You have multiple free and open source implementations to choose from, and there’s a library on Maven Central for almost anything you’d ever want - and if you don’t like the language itself there are many alternatives to choose from.

kodablah 9y ago
> You have multiple free and open source implementations to choose from Can you list them? By "implementations" I assume you mean a JVM and a stdlib? I am struggling to find non-OpenJDK ones that Java compliant (i.e. passed the TCK and give me confidence in switching).
- snuxoll 9y ago
  Yeah, I goofed a little here - there is a fair amount of OpenJDK derivatives but any of the non-hotspot implementations currently maintained are proprietary (IBM JVM, Azul Zing) or useless for what one is likely looking for (Dalvik).
tannhaeuser 9y ago
Where I'd recommend Java - fat backends for eCommerce, eGovernance, etc. with deep business logic - when developing on Windows and deploying on Linux (though I'm personally much more productive with Unix/Linux) eg. pjmpl's point Where Java isn't great IMHO: - must carry around a JVM and must have a JVM for the platform in the first place (so no deployment on the BSDs with first party support) - desktop GUI apps - web apps where you want to share front-end and back-end code - environments where garbage-collected execution isn't desired (such as realtime apps or performance-oriented apps with special memory layout requirements) - asynchronous, evented I/O (though Java has libs for it as well, yet not in mainstream Java APIs) - environments where JITing isn't desired for security reasons (NoExecute segment bits) - environments where single address space apps aren't desired (security isolation) - realtime apps including high-frequency trading apps - OP's point of becoming dependent on a potentially rogue party without necessity
- kimi 9y ago
  Not an expert, but I thought that nearly all of high-frequency trading (and finance in general) was Java. They spend handsomely on huge heaps and controlled-allocation data structures.
  - tannhaeuser 9y ago
    I'm not an expert in HFT either, but know personally someone who's developing HFT apps in C++. I guess if your profit depends on milliseconds and lower, there's no point in taking chances with Java. But Java is of course huge in all kind of financial apps, including settlement of HFT deals (eg. not on a critical code path).

kodablah 9y ago

> You have multiple free and open source implementations to choose from Can you list them? By "implementations" I assume you mean a JVM and a stdlib? I am struggling to find non-OpenJDK ones that Java compliant (i.e. passed the TCK and give me confidence in switching).

snuxoll 9y ago
Yeah, I goofed a little here - there is a fair amount of OpenJDK derivatives but any of the non-hotspot implementations currently maintained are proprietary (IBM JVM, Azul Zing) or useless for what one is likely looking for (Dalvik).

tannhaeuser 9y ago

Where I'd recommend Java - fat backends for eCommerce, eGovernance, etc. with deep business logic - when developing on Windows and deploying on Linux (though I'm personally much more productive with Unix/Linux) eg. pjmpl's point Where Java isn't great IMHO: - must carry around a JVM and must have a JVM for the platform in the first place (so no deployment on the BSDs with first party support) - desktop GUI apps - web apps where you want to share front-end and back-end code - environments where garbage-collected execution isn't desired (such as realtime apps or performance-oriented apps with special memory layout requirements) - asynchronous, evented I/O (though Java has libs for it as well, yet not in mainstream Java APIs) - environments where JITing isn't desired for security reasons (NoExecute segment bits) - environments where single address space apps aren't desired (security isolation) - realtime apps including high-frequency trading apps - OP's point of becoming dependent on a potentially rogue party without necessity

kimi 9y ago
Not an expert, but I thought that nearly all of high-frequency trading (and finance in general) was Java. They spend handsomely on huge heaps and controlled-allocation data structures.
- tannhaeuser 9y ago
  I'm not an expert in HFT either, but know personally someone who's developing HFT apps in C++. I guess if your profit depends on milliseconds and lower, there's no point in taking chances with Java. But Java is of course huge in all kind of financial apps, including settlement of HFT deals (eg. not on a critical code path).