why java?

Alan.raceQs said:

I wonder why Garmin is using java as the runtime environment for the Monkey-C development environment, and where it fits in to the framework. 

As opposed to what, tho?

What languages: C, C++, C#, rust, go, scala, kotlin, javascript/typescript or python?

And what frameworks: node.js, electron, react native, QT, .NET/mono?

Some of those things did not exist (or were not widely used) back in 2015 when Connect IQ was released.

Alan.raceQs said:

why

Probably because it makes it easier for them to support multiple development platforms (Windows, Mac, and linux), as opposed to writing native code for each platform.

Also maybe because this decision was made 10+ years ago. It's kinda like asking "why does CIQ use so much XML for configuration?" Yeah, if CIQ were designed from scratch today, maybe they would've chosen json or maybe yaml.

But even today, I've seen Java used for backend stuff at modern companies. Funnily enough, java is often chosen for stuff which requires high performance, since it blows trendier languages like python and typescript/javascript out of the water. (The irony is java is one of the slowest choices compared to other non-interpreted languages like C, C++, rust and Go.)

Alan.raceQs said:

where it fits in to the framework. 

idk if I'm stating the obvious, but:

- the compiler and era reporter are definitely java (they exist as jar files)

- I'm guessing all the other SDK binaries are written in java: e.g. simulator, SDK manager, monkeygraph, monkeymotion

EDIT: actually the simulator is C++

monkeygraph is not java (probably C++)

the SDK manager is not java (probably C++)

- the new language server which provides instant errors/warnings and other language features is java (this is also a jar file)

- the Monkey C VS Code extension has to be written in typescript or javascript (or the part of it that interacts with the VS Code API)

So to me it seems that everything in the SDK which can be java, is java.

[The old Eclipse plug-in was java, too]

Thanks for that. It all makes sense - the legacy aspect and platform independence are probably the primary drivers.

Does that suggest that the distributed .prg files are java bytecode that is processed by a JVM on the watch?

They are bytecode, but not java bytecodes.  CIQ uses its own VM

Alan.raceQs said:

Does that suggest that the distributed .prg files are java bytecode that is processed by a JVM on the watch?

No, as jim_m_58 said, CIQ has its own VM. Sorry I didn't make that clear, I thought it was understood.

I think Java is far too bloated to run on Garmin devices with limited resources. As far as resources go, it's arguable that Garmin is pushing things by having its own VM in the first place. There's endless discussions about the battery impact of CIQ watchfaces vs built-in watchfaces, for example. And I think it's noticeable that CIQ apps have been a little less responsiveness than native apps (especially on older devices).

I'm not sure, but I'd guess one of the reasons to use a VM for CIQ in the first place is for security (e.g. so CIQ apps can't directly access native functions or memory.)

I don't want to get too technical, as this is probably way out of my depth, but I'm curious about the underlying structure. Just to confirm, when I test my code in the simulator on my Mac, is the sim processing the same bytecode that the watch uses?

Alan.raceQs said:

Just to confirm, when I test my code in the simulator on my Mac, is the sim processing the same bytecode that the watch uses?

Yeah.

When you build a PRG and run it in the sim, that's the same PRG that would run on a real device.

Of course, the simulator isn't the same as a real device, so you may see certain quirks / bugs on a real device that you don't see in the sim, and vice versa.

So, has Garmin developed distinct virtual machines, or runtime environments, tailored for macOS, Windows, Linux, and their proprietary device operating system?

Alan.raceQs said:

So, has Garmin developed distinct virtual machines, or runtime environments, tailored for macOS, Windows, Linux, and their proprietary device operating system?

If I had to guess, I would say there's 2 possibilities:

A) There's 2 versions of the VM / runtime / interpreter:

- one that's written in Java (so it works on all the development platforms)

- one that's written in C/C++ and runs on the devices

B) There's 1 version of the VM / runtime / interpreter:

- it's written in C/C++ for the devices, then ported to the various dev platforms

--

This is complete speculation on my part, though. That is a great question and I wish i knew the answer.

EDIT: based on below, it's likely B)

I am running my watchApp in the sim, launched from VSC, have closed VSCode  and have terminated the java process, and the app is still running in the sim - (it's processing a track file as if it were receiving the data from a GPS).

The sim is running in a process named "Connect IQ Device Simulator" but as there's no java process running, I don't think the sim is written in java.