Apache IoTDB 1.0 Released As An "Internet of Things Database"

[phoronix]

Phoronix: Apache IoTDB 1.0 Released As An "Internet of Things Database"

The newest Apache software project hitting the version 1.0 milestone is the Apache IoTDB as a time-series database focused on serving as a database to the Internet of Things (IoT)...

https://www.phoronix.com/news/Apache-IoTDB-1.0-Released

[Raka555]

It seems to be written in Java, so I assume the "lightweight" part is features and not resources ...

[Ironmask]

IoT and Java. Surely nothing security-related can go wrong here.

[Jumbotron]

As much as I loath all things Java, what would anyone otherwise suggest when dealing with the enormous amount of "things" that will compose and are already composing the "Internet of Things" each with their own version of a SoC from various manufacturers each running a different ISA or variant of an ISA ?

[Ironmask]

As much as I loath all things Java, what would anyone otherwise suggest when dealing with the enormous amount of "things" that will compose and are already composing the "Internet of Things" each with their own version of a SoC from various manufacturers each running a different ISA or variant of an ISA ?

... Anything?
C was literally made for that. And while that used to be a clunky process, modern cross-compilers, better tooling and newer languages have made it seamless. It's practically an automated process.
Don't drink Sun/Oracle's koolaid, "write once run everywhere" is not only just a marketing campaign but factually incorrect, Java is just as platform-dependent as any other C program, because it is a C program. Just like any other VM/JIT language.

[NobodyXu]

... Anything?
C was literally made for that. And while that used to be a clunky process, modern cross-compilers, better tooling and newer languages have made it seamless. It's practically an automated process.
Don't drink Sun/Oracle's koolaid, "write once run everywhere" is not only just a marketing campaign but factually incorrect, Java is just as platform-dependent as any other C program, because it is a C program. Just like any other VM/JIT language.

JVM itself indeed needs to be implemented for every platform, but Java program does not need to.
That's literally the point of it.

Java provides platform independent APIs that encapsulate the capabilities of the platform and implement as efficient as possible.
For anything not in std, there're third-party packages that provides the functionalities (or write a small one yourself if none exists).

And the compile once run anywhere makes developing much easier.
You compile it once, test it once, and then it can run everywhere.

That's also why Python program can be platform independent.

[stormcrow]

JVM itself indeed needs to be implemented for every platform, but Java program does not need to.
That's literally the point of it.

Java provides platform independent APIs that encapsulate the capabilities of the platform and implement as efficient as possible.
For anything not in std, there're third-party packages that provides the functionalities (or write a small one yourself if none exists).

And the compile once run anywhere makes developing much easier.
You compile it once, test it once, and then it can run everywhere.

That's also why Python program can be platform independent.

That's the marketing byline, not the practicality of the matter in complex systems. It's also not entirely true of Python in the real world on functional complex systems that also need to interface with the OS and hardware. In both cases, those systems find they can't easily move from one version of the runtime to a newer one because of incompatibilities (or even between hardware/OS platforms because of differences in methods of interface like between Linux and Windows or RTOS, etc). I've hit this with Java and Python both, and not just because of the Python 2 to 3 problem, but between Python 3 versions, and don't even get me started on trying to move Java 8 based systems to 11 or 17.

No. The reason why it was written in Java is familiarity and culture. Java is used in embedded spaces because of the ubiquity of understanding with programmers of a certain age. For Gen X and earlier the common language has been assembly/C/C++. For those that were educated in the late 90s and 00s the language many picked up and learned was Java due in large part with Sun's popularity at the time in the industry - and that's what the University CS and industry specific programming courses taught (now it's mostly Python, I just graduated with a degree though I'm an Xer myself). Many embedded frameworks were originated in this environment, notably Android, but many others as well. Those frameworks survive today. Had any other language been introduced in that period and gained the same notoriety, this project likely would have been written in it instead. It's likely in 20 years those frameworks will give away to Python (edit to add: Or Rust given the current changing trends in multi level security & robustness in the FOSS space) once the current generation starts making its mark in the embedded space.

There are a great many embedded device systems written in Java, but there's quite a bit more written in C/C++ (like Arduino) which is also ostensibly 'portable' if you know how to write it that way. The problem with embedded devices is less the ISAs, which are often de-facto standards in any given industry (ARM or MIPS based or some widely available and cheap microcontroller and relatively uniform between major versions) and more how you bring a board from cold core to runtime since there are no standards for doing so, unlike bigger systems that have standardized around UEFI in the past few years.

Edit to further add: Don't conflate the language with the runtime environment. Java the language does change between environments. For example between environments based on the various implementations of the Java virtual machine: Bellsoft, Oracle, embedded VMs from various makers, IBM, OpenJDK, they all have gotchas if you try to move between them especially once you start needing to use other Java based packages in your project. That also doesn't include any changes between major versions of theoretically canonical Java from Oracle or OpenJDK. Python has the same issue. Which Python are we talking about? Python.org? ActiveState? PyPY? Pyston? Stackless? 2 or 3? Though most people use canonical Python from Python.org's repository, that's not always the case - especially in constrained environments.

[NobodyXu]

stormcrow Thanks for the great writeup, I am aware of the problem involves python and Java (e.g. Grallvm).

My mindset seems to a little bit of different: I was thinking about arm/mips that runs linux or other unix based embedded system so I thought Java/Python is not an unreasonable choice for this, though memory usage of Java is indeed insane compared to compiled PLs.

[Raka555]

stormcrow Thanks for the great writeup, I am aware of the problem involves python and Java (e.g. Grallvm).

My mindset seems to a little bit of different: I was thinking about arm/mips that runs linux or other unix based embedded system so I thought Java/Python is not an unreasonable choice for this, though memory usage of Java is indeed insane compared to compiled PLs.

The JVM sometimes lacks features on some less popular platforms.
Yes, the program will probably run, but it often would not have JIT compilation or sometimes even garbage collection(I once worked on a system where it was impossible to free anything, because java do not have manual memory management and if GC is not implemented on that version of the JVM, then that is that.)

[Ironmask]

JVM itself indeed needs to be implemented for every platform, but Java program does not need to.
That's literally the point of it.

Java provides platform independent APIs that encapsulate the capabilities of the platform and implement as efficient as possible.
For anything not in std, there're third-party packages that provides the functionalities (or write a small one yourself if none exists).

And the compile once run anywhere makes developing much easier.
You compile it once, test it once, and then it can run everywhere.

That's also why Python program can be platform independent.

Except when you need FFI, which many programs do. All you need is one platform-specific dependency and then your Java or Python program is absolutely no different than any other native binary. That's why the concept is a joke, because it falls apart in the real world.
Also, most natively compiled languages already have tons of libraries that abstract the underlying platform. You don't need a VM to do that.
VMs are not magic, especially in the embedded world. All they are is a tradeoff between the various pros and cons of JIT versus native binary. There's pros to using a VM, but they certainly don't include hoping that your code magically works everywhere, certainly if it's a non-trivial program.