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.

> 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.

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.

> 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.

I had successfully blocked JavaCard. Boo.

> 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++.

> 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.

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.

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.

When you build Android you're not building it on Android, you're building it on Windows, MacOS, or Linux. Maven itself is not being run on Android or iOS.

The Java code that powers Maven isn't portable. The AndroidX code hosted on Maven that everyone is pulling down for Android isn't portable, either.

Your claim would be like saying that PHP is portable because every platform has a web browser that can talk to the server running modphp. That's not what portability means.

> For example, do you use Mockito? You will download that exact same library from Maven Central regardless of the platform you are building on.

Mockito only runs on 2 of the 4 platforms (doesn't run on iOS or web).

Who cares about Maven-the-app, we are talking about the portability of the JVM bytecode.

There are gigs of JVM bytecodes stored on Maven Central and these bytecodes are being downloaded and run on macOS, Windows, Linux, and Android on a daily basis without a single change. The very same libraries. Unchanged.

That's the very definition of portability.

I don't understand why you keep shifting topics by bringing up irrelevant observations.

Any libraries in the Maven repos that rely on JNI have to include platform-specific native libraries for each platform. For example, anything that uses Unix-domain sockets, which weren't supported in Java until this very release.

There's no portability requirement to being on Maven Central. Maven Central regularly hosts non-portable bytecode - like every AndroidX library.

And, again, none of those libraries run on Windows, Android, iOS, and web - the 4 major platforms by market share. At best you get half of those, but typically you don't even get that, and that's still only libraries. None of them are portable applications.

It's trivial to write semi-portable C++ snippets, too, that's not a major achievement.

Now you're being intentionally obtuse and moving the goal posts from your original claims just to score points.

You're not arguing in good faith.

Feel free to stick with your invalid views on portability, the rest of us JVM developers will keep enjoying the portability that this wonderful technology provides us.

Me: You can't write a portable Java app that runs on the 4 major platforms (windows, android, ios, web)

You: But <thing that doesn't do that>!

Me: But it doesn't do that?

You: moving goalposts! obtuse!

When people call .class files portable, they mean between platforms that have a JVM available and can pass the TCK.

Platforms that do not aim to do that are not really relevant.

That's like saying C++ exe's are portable if you just ignore all platforms that don't have an NT kernel.

Market share determines a platform's relevance to portability claims, not its intention towards the JVM.

I see that your goalposts in this discussion are also highly portable.