Comment Re:Great! (Not) (Score 1) 330
a) Java was DESIGNED for embedded systems, first and foremost. That's why it is hardware-agnostic; because it allows the hardware makers to throw in whatever chips are cheap in bulk at the time, change on a whim, and still push out the same upgrade to everyone. Being cross-platform in the MacOS/Linux/Windows way was just sort of a side-effect. Think about how much this will benefit set-top manufacturers!!
You can argue it was designed for embedded, but I won't. That was its original intention- I don't know about saying it was designed for embedded. Because Java is not open, "your slap Java on any chip" sounds great until you need a VM. Sure, there are nice free attempts, but you still have problems without your slow, memory hogging VM. Might as well screw deterministic memory- something more than necessary with realtime embedded systems. There are some nice attempts though- I've seen a theoretical maximum of 300 ms in some places for "sitting around" which isn't half bad. Show me a embedded device with a Java device driver. What about an unlaughable scheduler? Directly interfacing with interrupts? Anyhow, it's fun to go back and see how Sun at least had an embedded link compared to now. Where's it going?
b) Java isn't interpreted anymore... its just-in-time compiled and then executed as native code. A bit of a start-up pause while the classes compile, that's all.
Maybe JIT moved Java from being fully interpreted, but it's still interpreted and "compiled" at runtime making it theoretically (a.k.a Javaly) and realistically on average always slower and more of a memory hog than unnamed alternatives, that's all. But, sometimes that's ok right? Look at how Java has taken over the desktop application market where that least matters. How many Java desktop applications do you run? Can you tell it's Java? If programming will always be hard, one might wonder what skeletons in the closets Java fanatics have at the price of conformity to an interface. Java version incompatibilities, buggy VMs, oh my.
You can argue it was designed for embedded, but I won't. That was its original intention- I don't know about saying it was designed for embedded. Because Java is not open, "your slap Java on any chip" sounds great until you need a VM. Sure, there are nice free attempts, but you still have problems without your slow, memory hogging VM. Might as well screw deterministic memory- something more than necessary with realtime embedded systems. There are some nice attempts though- I've seen a theoretical maximum of 300 ms in some places for "sitting around" which isn't half bad. Show me a embedded device with a Java device driver. What about an unlaughable scheduler? Directly interfacing with interrupts? Anyhow, it's fun to go back and see how Sun at least had an embedded link compared to now. Where's it going?
b) Java isn't interpreted anymore... its just-in-time compiled and then executed as native code. A bit of a start-up pause while the classes compile, that's all.
Maybe JIT moved Java from being fully interpreted, but it's still interpreted and "compiled" at runtime making it theoretically (a.k.a Javaly) and realistically on average always slower and more of a memory hog than unnamed alternatives, that's all. But, sometimes that's ok right? Look at how Java has taken over the desktop application market where that least matters. How many Java desktop applications do you run? Can you tell it's Java? If programming will always be hard, one might wonder what skeletons in the closets Java fanatics have at the price of conformity to an interface. Java version incompatibilities, buggy VMs, oh my.
