Hacker News new | past | comments | ask | show | jobs | submit login

J2ME is nowhere near being hard real-time. Minimal Java ME Embedded configuration: 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM. This is close to border where systems have MMU and is considered very "big" configuration in realm of embedded systems. 10-20 kB RAM/64kB flash is a lot for many many applications. Rust seems to be on a good path to be the real C competitor in general bare-metal development. Right now Cortex-M* family support is on level when you can start writing some apps in it. I'm not considering Ada to be mainstream.



J2ME is not the only game in town for embedded Java, check Aonix and Aicas offerings instead.

As another example, MicroEJ is targeted at Cortex-M CPUs.

And there is also Astrobe selling Oberon-07 compilers for M3 and M4 processors.

> 32-bit MCU, 130 KB RAM, 350 KB Flash/ROM

Anything less than this is most certainly some kind of PIC, not everyone is using them for embedded real-time deployments.


Correct me if I'm wrong: Aonix is not existing - it was bought by PTC. Their real time Java is now targeting only x64/x86 systems.

You are wrong about "anything less" Anything less is probably 90% of market. You will find 130kB RAM, 350kB flash only in high end products from NXP(LCP family), Kinetis(KL family) or STI( STM family). You only need so much RAM for JAVA :)


I believe his point was they implemented hard-real-time, embedded Java with GC on some components that was fielded successfully. That refutes any objection to whether it can be done. At that point, we're talking whether the new project can pull that off on what kind of hardware with what constraints.

EDIT to clear up two sub-conversations here: what Aonix pulled off for hard-real-time Java; that there's also hard-real-time GC's for embedded. Example of latter.

http://michaelrbernste.in/2013/06/03/real-time-garbage-colle...


Yes, they were bought by PTC.

However I don't know what they have done with the PicoJava offerings, since PTC isn't as friendly as Aonix regarding the making the documentation available.

As for the market, it depends on which one the products built with those CPUs are actually being sold to.

My Cisco phone and the Ricoh printer around the corner both are running some form of embedded Java.

Maybe you think they are part of the remaining 10%, however Cisco and Ricoh though it was worthwhile for their sales.


I believe we have different definition of embedded system. There are a lot of them, for me simplest definition is CPU/uC system without MMU. Those Cisco Ricoh gear have Linux running inside (at least for phone I have it's some 200MHz MIPS)


"I believe we have different definition of embedded system. "

Counterpoint:

http://www.atmel.com/Images/45107A-Choosing-a-MCU-Fredriksen...

The 32-bit market was at $6 billion by 2014 per Amtel's report. There's also a huge amount of sales for Windows Embedded and embedded Linux's. That represents a significant chunk of a massive market. So, it's quite worthwhile to call even a 32-bit-targeted, hard-real-time GC useful for "embedded" systems. As he said, it's part of the standard definition used in the embedded sector. The 32-bit side is going up rapidly, too, due to decreasing cost and power usage.

EDIT: The specs on them are also starting to look like the desktops of old. Actually, started to do that quite a while ago.

https://cache.freescale.com/files/32bit/doc/fact_sheet/IMX7S...


My definition is the market definition, it doesn't single out to one specific architecture design.

The market goes all the way from something like the PIC10 to something ARM v8 64 bit.

It is all a matter of what a company is targeting as customer market, and how much it is willing to spend.

Just because a given language is not able to target 100% of the market, it doesn't make it invalid to such market.

If that was the case, C wouldn't be a valid language for embedded development as well, given that many CPU/uC aren't able to cope with straigh ANSI C compliant compilers and require either a C dialect or pure Assembly.


J2ME is nowhere near being hard real-time.

...and?

Believe it or not, not every embedded application has a hard real-time requirement.

You're just moving the OP's goalposts to make a point, here.


No, he's making the point that the latency introduced by a GC is most important in the case of a hard real-time system. If J2ME isn't one, then using it as an example is specious.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: