Kodumaro :: The great VM Misconception

Released on March 17th, 2019
The shadows behind the code.

There’s a well accepted idea that the best multiplatform development approach can be no other than virtual machine. If you disagree, you’re probably out of your mind. But the truth may be quite different.

Back in the 90’s, the Sun Microsystems was spending a lot of marketing on its technologies in order to convince people it had taken the right path, while everyone else would be on the wrong one – of course. Its marketing has been betting in the assumed VM approach advantage ever since.

Thus, according to the Sun evangelism, programming for VM would take the need to deal with different platform nuances away from developers, and they could hence focus on the business. They also could deploy their application to the most different targets painlessly.

Obviously the only viable VM supplying all those features was the JVM (Java Virtual Machine).

Aiming at endorsing that vision, the Sun Microsystems was releasing its JVM for every coeval platform it could.

That created a false sense of verity, which has lived up to this days.

But the facts are much worse than the Sun’s fiction.

There can be only one

Everything looked great while only one company was ruling the market – which per se should sound creepy for you, development company, if you were thinking clearly: all your business code infrastructure relying on another company, possibly a rival.

Think about it: all the codes of every single development company relying on only one company alone. Does it sound familiar?

Well… let’s set that aside for another day’s talk…

One, Two, and Many More JVMs

Then came other JVMs (and the chaos).

First an IBM’ JVM, yet in 90’s, thereafter lots of them from many different companies, remarkably the OpenJDK.

But the shit hit the fan when the Google released its first Dalvik VM for Android KitKat in 2013.

The Android programming language remained Java (until Kotlin arrived leastwise), but the VM has no longer being JVM, but the Dalvik, something quite else.

It revealed defenceless the VM approach’s jugular.

The today’s deed has been that the developers must deal with platform issues while developing the business code.

You cannot use this package, ’cause it’s not supported by the Dalvik; you cannot use that package, ’cause it’s not supported by the Oracle JVM; and so on. Your multiplatform code must take care of platform concerns.

That’s not a C/C++ trouble!!

When you’re developing on a truly compiled development platform, like C/C++, Go, Rust, Haskell, and OCaml, for example, you have to deal with platform issues only on compile-time (probably cross-compiling). However coding, you must take care of business issues alone. You’re able to focus on business on truly compiled platforms.

This is what VM promises, but doesn’t supply. In fact, the dead horse Sun has beaten is just who does.

Aftermath

If you’re thinking of JVM for multiplatform, think twice and consider cross-compiling.


Also in Medium.

Career | Concept | Java

DEV Profile 👩‍💻👨‍💻