Java Device

[foodchain]

could you use programmable chips to emplace a Java based operating system in a small computer device, like handheld.

 

My idea was maybe a bit of flash memory that could hold some roms to start up the OS. On the electronics itself start up or the on button would fire the roms into something like a CPU or what not. Then the Java program could start to run.

 

I would think programs could be nothing but sets of nested beans if that is possible, or new stuff and or upgrades to it. I think this could be reflected in the electronics layout also for the same purpose.

 

I would like to think of flash memory for a "bios".

 

Some kind of hardrive hardware also, in which data for individual beans could be held in a different hardware area then files it generates. Not so much a software partition either, just different chips really for the purpose of formating or what not. Files made to support dynamic bean operation over time could be permanently hidden, and regular files like a .txt file or song could just be what is user visible. I think this could help user end programs along with possibly just being able to plug it into a USB for instant internet fix.

 

I just wonder if you can get programmable chips that could improve just a java language environment, plus whatever kind of a board you would have to put together. I know java has massive built in functionality, even for graphics processing.

[Sayonara]

There are plenty of hand-held devices that use Java.

 

Or are you talking about a device which uses Java as an operating system?

[bascule]

could you use programmable chips to emplace a Java based operating system in a small computer device, like handheld.

 

My idea was maybe a bit of flash memory that could hold some roms to start up the OS. On the electronics itself start up or the on button would fire the roms into something like a CPU or what not. Then the Java program could start to run.

 

This has been attempted a few times, for example JavaOS by Sun provided a small microkernel which would start the Java Virtual Machine, so that large portions of the operating system could be written in Java itself. That didn't pan out so great.

[vordhosbn]

Two obstacles - performance and reliability, which by themselves do not come so much from the characteristics of the programming language used, rather by its current use in embedded systems. So you actually have one path to follow - C. It has been proven reliable (in terms of compiler-to-assembly-code robustness over different processor architectures) and is the language of choice behind most commercial embedded solutions.

[bascule]

Two obstacles - performance and reliability, which by themselves do not come so much from the characteristics of the programming language used

 

Performance and reliability are very much tied to the language of implementation, although a bad algorithm in any language is still a bad algorithm...

 

That said, C is riddled with "unsafe" features like pointers, fixed size buffers with no built-in OOB checking, and manual memory allocation. These require constant vigilance on the part of the language's user to ensure programs are correct.

 

Java manages to solve all of these problems with a comparatively small impact on performance, and retaining a largely C++-like development environment.

 

Java could make a good systems programming language.

[foodchain]

I would like to think that at the hardware level it would be possible to maximize a virtual machine running the java environment. This could be selective based on what java tools being used by the device. Basically that the architecture of the machine is designed for java.

 

I would think start up could run a small bios like program that could get it up and running, and from there you could have one class that just loads and unloads beans based on user input, a gui.

 

I just wonder if you could do away with having to make a registry. Instead just having user files, both by system and regular ones. Only the regular ones would be user visible. I would think hooking some usb ports to it, or card readers could improve what you could do with it.

 

The idea is plug and play, for just general internet use, or for that matter being able to play games. Then of course if anything goes wrong the big idea is that formating would be super easy, maybe as easy as just plugging it into the net, possibly with just a different function. Like if you go to turn it on, maybe the switch could be on, off, and system fix. The last one would just format all data save for the beans and the OS. These parts of the software I would like to think could be made inaccessible by any other party.

[vordhosbn]

@bascule

Speaking abstractly - of course. For example - there are compilers under Windows for almost any invented language, but that's not the case for Fujitsu or NEC microcontrollers.

 

It's true, that C is archaic in terms of ease of programming and LOC, but unsafe practices can and are forbidden to use in commercial applications (for example dynamic memory allocation is not used, neither is pointer arithmetic) and there are additional QA mechanisms to ensure reliability and safety - Unit Testing, Code reviews, Integration tests, Validation, Customer validation. The design of the software framework to be used is of great importance too...

 

I was only stating that it's hard to find an actual working, non-experimental compiler for anything other than C for embedded systems.

 

@foodchain

What do you mean by maximizing? Performance? Virtual JM is not particularly known for good performance, and by using it on a microcontroller with limited resources...

However, to make the Java machine functional, you must have not only small bootstart program, but entire OS with drivers, basic task scheduling, etc. - this also takes CPU and memory. So in the end - i think it may be possible to build such a device, but if you wish to use the versatility and portability of Java, you have to trade for it the performance of native code programs.

Edited February 15, 2010 by vordhosbn

[thinkbizom]

Thanks foodchain,

 

This is very helpful article written by you.