Substitutable, and no it isn't. Google deliberately broke compatibility with java, its language and its packaging.

From the UI perspective, there is actually a reasonable justification for limiting compatibility - but they went far further than what was reasonable.

They did this to prevent applications executable on any JVM from running on Android.

You seem to be arbitrarily setting the scope for substitutability to Java as a whole, but why? Why can't it be e.g. individual classes, or even methods on them? Two pieces of Java code pretty much never need the entirety of J2SE API to interact.

The JVM itself makes backwards incompatible changes. I have jars that work on earlier VMs, but don't anymore.

Sure, but I'm damned certain that's never happened with the destruction of interoperability being the goal in mind.

The destruction of interoperability wasn't the goal in mind with Android either. Java ME sucked, and SE is somehow even a worse fit for phones. The fundamental process model destroys battery life, hence the switch in Android to that model that'll shut the app down basically at any time and allow it to save state, so it can come back to where it was later. In addition to that, an IPC system was added (which basically doesn't exist in Java ME), and a bunch of support for devices that are only accessible in Java via 3rd party libraries anyway. Oh, and the lack of swing. But come on, even Eclipse doesn't use swing.

Having jars only work with specific oracle JVM versions is not at all unusual.

> Having jars only work with specific oracle JVM versions is not at all unusual.

I think that underscores the point? That even legitimate JVM versions were not substitutable for each other.