5 ms·

> C++ is more portable because it doesn't require the JVM to run Java is portable BECAUSE of the JVM. If a new computer architecture hits the scene, once someo

> C++ is more portable because it doesn't require the JVM to run Java is portable BECAUSE of the JVM. If a new computer architecture hits the scene, once someone writes a JVM for it your .class files will run on it (probably). Your C++ program, however, will definitely not run and you'll need to recompile it with a compiler that targets that new architecture. The same compiled Java code will(should) run on a Mac or a PC or any Linux box, but you need a different executable for each target with a C++ program. The JVM isn't portable. That needs to be recompiled for each new target, but your Java .class files are portable.

AlotOfReading 6y ago
For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.
- jacques_chester 6y ago
  > For a couple decades, x86 was absolutely dominant On the desktop and servers, maybe. But there is more in heaven and embedded than is dreamt of in your philosophy.
  - AlotOfReading 6y ago
    I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes. If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.
    - kllrnohj 6y ago
      > Remember the portability disaster that was symbian and Java ME? Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you can't even assume it has a garbage collector. Among many other limitations.
      - jacques_chester 6y ago
        I had successfully blocked JavaCard. Boo.
kllrnohj 6y ago
> but your Java .class files are portable. No, they aren't, they regularly have non-portable dependencies or assumptions about the environment. For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS - the 3 most popular OS's. You have completely different UI support between Windows & Android, and there's not really any JVM for iOS (there's AOT, but now you're not even pretending to run a .class file) So to make a "portable Java" program you're already stuck compiling it 3 times for the 3 major OS platforms, but without anything helping you to actually specialize for a platform like exists with C++. Making Java less portable in practice than C++. Toss in that other popular platform, web, and the "portability" of Java gets even worse compared to others like C++.
- hota_mazi 6y ago
  > For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS Not only is it possible, it happens all the time. The entire Maven Central repository, which contains tens of thousands of JVM libraries, is usable on all the platforms you just listed. If that's not portability, I don't know what is.
  - kllrnohj 6y ago
    Maven runs on 1 out of the 4 mentioned platforms. There are no Android, iOS, or web builds of Maven. Maven is used to ship dependences for the other platforms, but it is not run itself on those other platforms. Shipping an Android-specific library on Maven isn't magically portable (which is what's common here - OS-specific libraries on Maven). It's still Android-specific.
    - hota_mazi 6y ago
      All Android builds use Gradle and download their dependencies from Maven Central. I have no idea what you're talking about. Let me repeat this: all Windows, macOS, Linux, and Android apps that use Maven or Gradle to build ALL download their dependencies from Maven Central. These are the very same libraries, same bytecode. For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.

AlotOfReading 6y ago

For a couple decades, x86 was absolutely dominant and there were no new architectures of any importance outside specific niches. Once you dealt with the OS specific oddities (which java also helped with), C++ was highly portable.

jacques_chester 6y ago
> For a couple decades, x86 was absolutely dominant On the desktop and servers, maybe. But there is more in heaven and embedded than is dreamt of in your philosophy.
- AlotOfReading 6y ago
  I work in embedded. Embedded Java has always been a huge set of tradeoffs, which is why it never took off outside of application platforms like mobile phones and set-top boxes. If you wanted the full fat SE Sun/Oracle JVM you were pretty much stuck with power or ARM, and even then you had to be careful. Remember the portability disaster that was symbian and Java ME? These ISAs weren't exactly the low end of the embedded market at the time either. The farther away from x86 you got the less portability you could actually take advantage of.
  - kllrnohj 6y ago
    > Remember the portability disaster that was symbian and Java ME? Don't forget Java Card in that list. Which Oracle still tries to claim as a Java portability win, even though it doesn't support basically anything. And I don't mean missing standard libraries, I mean like it doesn't support char, double, float, and long, or multidimensional arrays. Support for int is even optional. Doesn't support exceptions and you can't even assume it has a garbage collector. Among many other limitations.
    - jacques_chester 6y ago
      I had successfully blocked JavaCard. Boo.

kllrnohj 6y ago

> but your Java .class files are portable. No, they aren't, they regularly have non-portable dependencies or assumptions about the environment. For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS - the 3 most popular OS's. You have completely different UI support between Windows & Android, and there's not really any JVM for iOS (there's AOT, but now you're not even pretending to run a .class file) So to make a "portable Java" program you're already stuck compiling it 3 times for the 3 major OS platforms, but without anything helping you to actually specialize for a platform like exists with C++. Making Java less portable in practice than C++. Toss in that other popular platform, web, and the "portability" of Java gets even worse compared to others like C++.

hota_mazi 6y ago
> For example, it's more or less impossible to write a Java program that runs on Windows, Android, and iOS Not only is it possible, it happens all the time. The entire Maven Central repository, which contains tens of thousands of JVM libraries, is usable on all the platforms you just listed. If that's not portability, I don't know what is.
- kllrnohj 6y ago
  Maven runs on 1 out of the 4 mentioned platforms. There are no Android, iOS, or web builds of Maven. Maven is used to ship dependences for the other platforms, but it is not run itself on those other platforms. Shipping an Android-specific library on Maven isn't magically portable (which is what's common here - OS-specific libraries on Maven). It's still Android-specific.
  - hota_mazi 6y ago
    All Android builds use Gradle and download their dependencies from Maven Central. I have no idea what you're talking about. Let me repeat this: all Windows, macOS, Linux, and Android apps that use Maven or Gradle to build ALL download their dependencies from Maven Central. These are the very same libraries, same bytecode. For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.