2 ms·

I can't use Java for most things I do. Can't create loadable libraries in Java (.so, .dll, .dylib, etc.). Can't write kernel drivers in Java. Impractical for mo

• lmm 11y ago
  > Can't create loadable libraries in Java (.so, .dll, .dylib, etc.) You can do loadable plugins in Java very nicely. If you're using Java for everything then the calling code is also Java and it works great. > Can't write kernel drivers in Java. Not if you need them to run in-process in an existing non-Java kernel, no - but that goes back to "use the same language for everything you do". (And IME drivers rarely actually need to be in-kernel). > Impractical for most embedded applications. People told me this six years ago when I was developing for a low-power ARM, and when I actually tried it I found it was complete nonsense - a lot of embedded CPUs had more than enough power back then to run Java, and they've only got faster since. > Despite its many flaws, C/C++ is something you can use everywhere. You can write same piece of code to run on practically all possible platforms. Any mobile device, desktop environment, microcontroller, it's even possible to compile it to run on a web browser. Sure, that's an advantage. But how often does it apply in practice? I'd far rather have low-defect-rate code that I can run on the platforms I care about than buggier code that can also run on some more obscure platforms. > Sure, you could use RPC or use JNI. But those solutions are completely impractical. Depends entirely on what you're doing. For many use cases they're perfectly adequate.
  • vardump 11y ago
    > You can do loadable plugins in Java very nicely. If you're using Java for everything then the calling code is also Java and it works great. JVM classloader based libraries generate a lock-in effect. Those libraries you write are destined to be used almost exclusively from another JVM bytecode blob. > People told me this six years ago when I was developing for a low-power ARM, and when I actually tried it I found it was complete nonsense - a lot of embedded CPUs had more than enough power back then to run Java, and they've only got faster since. I'd like to see how a Java based IRQ handler looks like. Or (gather/scatter) DMA and memory mapped I/O. Can Java have same realtime characteristics AND same or lower memory RAM/flash overhead as a C/C++ based solution? Cost per unit matters. > ...I'd far rather have low-defect-rate code that I can run on the platforms I care about than buggier code that can also run on some more obscure platforms. This is why I have high hopes in Rust. If you can't run on those "obscure" platforms you're required to run, then you need to write the code twice. How's that a good thing? >> Sure, you could use RPC or use JNI. But those solutions are completely impractical. > Depends entirely on what you're doing. For many use cases they're perfectly adequate. Well, now you're not just shipping a 200 kB dll, but also a JVM bridge of some sort (RPC or whatever), plus you need to vendor whole JRE in your installation package. 100 MB+, much higher runtime memory consumption and debugging challenges the bridge causes. How's this better?
    • lmm 11y ago
      > JVM classloader based libraries generate a lock-in effect. Those libraries you write are destined to be used almost exclusively from another JVM bytecode blob. Sure, but it's the same for C, or any other platform. (I mean, many languages have FFIs into C libraries, but they generally have APIs that are not at all natural for that language). > I'd like to see how a Java based IRQ handler looks like. Or (gather/scatter) DMA and memory mapped I/O. Can Java have same realtime characteristics AND same or lower memory RAM/flash overhead as a C/C++ based solution? None of that sounds impossible, or even necessarily much harder than it is in C. It won't look much like mainstream idiomatic Java, and it will involve a lot more bookkeeping - but so would doing it in C. > Cost per unit matters. It does, but so do development time and defect rate. > If you can't run on those "obscure" platforms you're required to run, then you need to write the code twice. How's that a good thing? I'm not advocating writing the code twice. If your code needs to run on a particular platform, you choose a language that you can find a way to make run on that platform. It's just that in my experience of the business circumstances (which are specific to my field, sure), "I might one day have to port this to a platform that you can't run Java on" is a long long way down the list of risk factors. >Well, now you're not just shipping a 200 kB dll, but also a JVM bridge of some sort (RPC or whatever), plus you need to vendor whole JRE in your installation package. 100 MB+, much higher runtime memory consumption and debugging challenges the bridge causes. How's this better? Those aspects are not better, but they're often an insignificant cost compared to the quality benefit you get from Java.