You mean to tell me that Oracle think that embedded devices will run Java? Heavens, I'm shocked.
"Embedded devices" is such a broad term now, that they need to scope it a little better. An ATM running Windows is considered embedded by some definition, which is kind of what I suspect they're talking about here - not resource-constrained devices like Arduino boards, as inferred by the image at the top of the article.
It gets even funnier when they mention 'security considerations' as a major benefit of using Java for said 'intelligent embedded devices', and that Java was 'originally designed and conceived to run in embedded devices [and] was precisely focused on the portability and productivity problems faced by embedded developers'.
Last few times I read about widespread cross-platform malware that affected Windows, Linux, OS X and even Android, sometimes all at the same time, these exploits were based on Java security holes :-S
And WHY are we still quoting “analysts” in articles? When whatever conclusions they have apparently arrived at are so obviously sponsored by corporate interests?
Instead of making snippy comments can someone please explain why java will not be used on embedded devices? There is big demand for java interfaces on wireless sensor networks for instance
Some M2M will be in higher-end devices (cars, vending machines, gas pumps) that will have lots of available power. Those will be just fine on Java or Java/Android or whatever.
But a lot more devices will be running off battery power or scavenged power (solar, ambient, thermal, etc). These systems are going to wake up quickly, take a measurement or send out a message, and get back to sleep even quicker. These devices will need to consume idle power in the nanoamp range if they're going to survive their lifetime on a battery.
A JVM is just not the direction these systems are taking. They're being written low-level to get the data and get out. Even reading in pages of code from NAND flash consumes way too much power to survive.
It's difficult enough getting many embedded engineers to go to C over assembly. In the ARM world, C is the standard for programming, but for lots of other devices, such as the MSP430, efficiency and deterministic behaviour is really important. Flash and SRAM sizes are very small in some cases and Java would simply be impossible.
For bigger devices, RTOS's and C work pretty well, but you can't be liberal code wise given the amount of clocks available. And you conserve those as a necessity usually.
For networked devices, where you don't care so much about power or battery drain, then I guess there's an argument to be had. NXP LPC43xx with its dual processor m4 and m0 running at 204mHz for example could just about manage it. But for devices doing work like data acquisition most designers would balk at the idea. Especially as regards memory allocation.
That's hilarious. There's hardly anyone who runs java on a Raspberry Pi and popular platforms like Arduino don't even support it. The dream of cheap devices that run Java natively never really materialised and now that embedded devices are becoming hot again, there are plenty of other languages available. Arduino has a Java/C-like language that compiles to machine code for its micro-controller and most tutorials for programming on the Raspberry Pi are in Python or Ruby.
Maybe for high end, non battery powered and non mission critical stuff. Java is completely inappropriate for stuff that has to run predictably and reliably, mostly because of the memory management model.
And it's a resource hog in the domain of sub-MMU chips (like Cortex-M), so it's out of the question for cheap or very low power stuff.
And the embedded focus on hardware interfaces means these program won't be portable, either.
It's bullshit. Clearly, embedded software has to catch on with times, but this is not the way.
Over a nibble ago, when I was going through my Java love affair I remember a book I was reading, it prophesied Java in taosters. I Believed it back then because I was 11.
22 comments
[ 1.6 ms ] story [ 68.5 ms ] thread"Embedded devices" is such a broad term now, that they need to scope it a little better. An ATM running Windows is considered embedded by some definition, which is kind of what I suspect they're talking about here - not resource-constrained devices like Arduino boards, as inferred by the image at the top of the article.
lol
Last few times I read about widespread cross-platform malware that affected Windows, Linux, OS X and even Android, sometimes all at the same time, these exploits were based on Java security holes :-S
Knock knock? Who's there? [thirty second pause] Java.
Some M2M will be in higher-end devices (cars, vending machines, gas pumps) that will have lots of available power. Those will be just fine on Java or Java/Android or whatever.
But a lot more devices will be running off battery power or scavenged power (solar, ambient, thermal, etc). These systems are going to wake up quickly, take a measurement or send out a message, and get back to sleep even quicker. These devices will need to consume idle power in the nanoamp range if they're going to survive their lifetime on a battery.
A JVM is just not the direction these systems are taking. They're being written low-level to get the data and get out. Even reading in pages of code from NAND flash consumes way too much power to survive.
For bigger devices, RTOS's and C work pretty well, but you can't be liberal code wise given the amount of clocks available. And you conserve those as a necessity usually.
For networked devices, where you don't care so much about power or battery drain, then I guess there's an argument to be had. NXP LPC43xx with its dual processor m4 and m0 running at 204mHz for example could just about manage it. But for devices doing work like data acquisition most designers would balk at the idea. Especially as regards memory allocation.
Set top boxes.
It needs a special kernel with (slower) floating point ABI operations, called soft-float [1].
This article is poorly disguised PR paid by Oracle to get its foot back in the closing door of embedded systems market.
[1]http://www.raspberrypi.org/downloads
And it's a resource hog in the domain of sub-MMU chips (like Cortex-M), so it's out of the question for cheap or very low power stuff.
And the embedded focus on hardware interfaces means these program won't be portable, either.
It's bullshit. Clearly, embedded software has to catch on with times, but this is not the way.