5 ms·

>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of compu

>That is provably the wrong yardstick. Java has never been the best choice for a browser, even while being by far the most used language in the history of computing. I should have been clearer about what I think browsers are a good yardstick for. They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum. Browsers are an interesting instance of such a product, because they need complex in-memory data structures, they use a ton of memory, they need low level access to hardware and they are soft realtime systems. But that's by no means a contradiction to Java (and very similar languages) being the most popular language on earth. I see no reason why that should change any time soon. The only thing that the JVM really lacks compared to C#, Go and Swift is value types. If that's being worked on, I hope it's being worked on fast because it is a big deal.

pron 10y ago
> They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum. Absolutely. HotSpot is indeed the wrong platform for memory constrained environments, as are most GCed runtimes (although JVMs, including versions of HotSpot are used in embedded devices quite a lot, for applications that don't require the best possible use of resources). I myself have used a real-time version of HotSpot (realtime Java -- RTSJ -- has support for scoped and nested arena-allocated memory) in a hard-realtime, safety-critical missile defense system. It ran on large servers, but current work on RTSJ also targets embedded devices (see https://www.aicas.com/cms/en/rtsj https://www.aicas.com/cms/en/rtsj). I don't think this would be a great hit, but there aren't great hits in that market, anyway. > If that's being worked on, I hope it's being worked on fast because it is a big deal. Most of the HotSpot team (and not just them) are dedicated to value types as part of Project Valhalla[1], and some resources are directed towards Project Panama[2], that's supposed to be a fast bridge between JVM and native code (essentially replacing JNI with something that's both faster and much easier to write). Java 9 is already feature-complete, but value types are scheduled for Java 10 (maybe panama, too). [1]: http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/ [2]: http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/

pron 10y ago

> They are a yardstick for choosing a language that is viable if your product can only succeed if it uses computing resources within a very narrow margin of the optimum. Absolutely. HotSpot is indeed the wrong platform for memory constrained environments, as are most GCed runtimes (although JVMs, including versions of HotSpot are used in embedded devices quite a lot, for applications that don't require the best possible use of resources). I myself have used a real-time version of HotSpot (realtime Java -- RTSJ -- has support for scoped and nested arena-allocated memory) in a hard-realtime, safety-critical missile defense system. It ran on large servers, but current work on RTSJ also targets embedded devices (see https://www.aicas.com/cms/en/rtsj https://www.aicas.com/cms/en/rtsj). I don't think this would be a great hit, but there aren't great hits in that market, anyway. > If that's being worked on, I hope it's being worked on fast because it is a big deal. Most of the HotSpot team (and not just them) are dedicated to value types as part of Project Valhalla[1], and some resources are directed towards Project Panama[2], that's supposed to be a fast bridge between JVM and native code (essentially replacing JNI with something that's both faster and much easier to write). Java 9 is already feature-complete, but value types are scheduled for Java 10 (maybe panama, too). [1]: http://openjdk.java.net/projects/valhalla/ http://openjdk.java.net/projects/valhalla/ [2]: http://openjdk.java.net/projects/panama/ http://openjdk.java.net/projects/panama/