3 ms·

Look what they need to mimic even a fraction of C#'s power :)

pjmlp 3y ago
C#'s power can always be worked around with JNI, for those that don't have issues with polyglot codebases. Also lets not forget that Java (even if in a different flavour), powers 80% of mobile phone market, that power alone wasn't enough to keep Windows Phone going, mostly written in C++ anyway (COM/WinRT). Or the real time Java implementations used by the military, like PTC.
- neonsunset 3y ago
  It takes some degree of ignorance to claim that Java can be used in scenarios which require proper structs and object interior pointers. JNI is an abomination and a cautionary tale for everyone implementing interop facilities into their language.
  - pjmlp 3y ago
    My ignorance takes me to places you can only wonder about. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/ And to 80% market share in mobile OS market, full of JNI all over the place.
    - neonsunset 3y ago
      That's a rather damning prospect, that the mobile OS market has. Luckily, it's not all Android and I will be happily calling Swift directly out of .NET with upcoming interop changes and never have to touch this embarrassment of an API again that is JNI.
      - pjmlp 3y ago
        At which point better use Swift, a language designed as C, C++ and Objective-C replacement from the ground up.
        neonsunset 3y ago
        Not until its performance improves (why yes, I too was surprised to find it being slower than C# in many situations).
        pjmlp 3y ago
        As if calling into iOS APIs, some of which written in Swift, via an additional layer would be faster. By the way, MAUI folks had to rewrite plenty of stuff in Java/Kotlin and Swift, to improve MAUI performance.
        neonsunset 3y ago
        The reason why parts of the code had to be rewritten in Java was to work around inherent inadequacy of JNI. This is a sad reality all non-JVM languages have to deal with when targeting Android.
        pjmlp 3y ago
        You missed the "and Swift".
        neonsunset 3y ago
        If you're mentioning it, I would expect you to know that motivation behind writing Swift helpers was entirely different. Not that it matters in the long run because there will be even better way to do it. If you don't, then the comment is speculative, pointless and driven by bias.
        3y ago

C#'s power can always be worked around with JNI, for those that don't have issues with polyglot codebases. Also lets not forget that Java (even if in a different flavour), powers 80% of mobile phone market, that power alone wasn't enough to keep Windows Phone going, mostly written in C++ anyway (COM/WinRT). Or the real time Java implementations used by the military, like PTC.

neonsunset 3y ago
It takes some degree of ignorance to claim that Java can be used in scenarios which require proper structs and object interior pointers. JNI is an abomination and a cautionary tale for everyone implementing interop facilities into their language.
- pjmlp 3y ago
  My ignorance takes me to places you can only wonder about. https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/wp/products-services/jamaicavm/ https://www.aicas.com/wp/products-services/jamaicavm/ https://www.microej.com/ https://www.microej.com/ And to 80% market share in mobile OS market, full of JNI all over the place.
  - neonsunset 3y ago
    That's a rather damning prospect, that the mobile OS market has. Luckily, it's not all Android and I will be happily calling Swift directly out of .NET with upcoming interop changes and never have to touch this embarrassment of an API again that is JNI.
    - pjmlp 3y ago
      At which point better use Swift, a language designed as C, C++ and Objective-C replacement from the ground up.
      - neonsunset 3y ago
        Not until its performance improves (why yes, I too was surprised to find it being slower than C# in many situations).
        pjmlp 3y ago
        As if calling into iOS APIs, some of which written in Swift, via an additional layer would be faster. By the way, MAUI folks had to rewrite plenty of stuff in Java/Kotlin and Swift, to improve MAUI performance.
        neonsunset 3y ago
        The reason why parts of the code had to be rewritten in Java was to work around inherent inadequacy of JNI. This is a sad reality all non-JVM languages have to deal with when targeting Android.
        pjmlp 3y ago
        You missed the "and Swift".
        neonsunset 3y ago
        If you're mentioning it, I would expect you to know that motivation behind writing Swift helpers was entirely different. Not that it matters in the long run because there will be even better way to do it. If you don't, then the comment is speculative, pointless and driven by bias.
        3y ago