Mark Lam's Blog: Community: Embedded Java Archives

I apologize for not writing in a while. I've been trying to get some real work done (i.e. coding and designing solutions to improve the lives of our customers ... or at least, that's my goal). Anyway, two weeks ago, an interesting comment was added to a previous article I wrote on understanding JIT performance. The comment says ...

"Very informative blog!! Is there any information/projection on what % of apps in handheld market is based on and is expected to be written in Java/J2ME? I hear that, since handhelds are very memory constrained, JIT has challenges wrt to space and energy consumption. Is that too high to keep JIT technology in the darkages? How much more memory does JIT add over an interpreted version? Is there any study or white paper on why and how much such an overhead would be for JIT?"

Thanks for the comment (and the compliment), Cochin. I wanted to answer right away, but alas, I needed to gather some facts for it, and my day job also got in the way (needed to get some work done). At this moment, while I'm waiting for my computer to crunch some major compilations, I'll take a few minutes to give you my answer ...

Java and More Embedded Considerations

Posted by mlam on April 22, 2007 at 03:46 AM | Permalink | Comments (0)

Previously, I talked about why an embedded systems developer would choose to develop on the Java platform. If you have read that article and are intrigued by the benefits that the Java platform offers, then the next step is probably to ask some more deep probing questions like ...

Do I really need the Java platform?
Sure, the Java platform offers many benefits. But is it needed for my specific device?

Well, if you want the benefits of a runtime interpreted scripting language (i.e. isolation, upgradeability, etc.), then, as I have explained previously, your best bet is with the Java platform.

You may not need the Java platform if your device has the following characteristics:

static functionality: the software functionality never needs to be upgraded in the field, not even for bug fixes. Or, it is cheaper to replace the device than to replace the software (although this isn't very eco-responsible). Or you can live with the cost of providing the service and infrastructure to completely re-flash the software in deployed devices. Under these conditions, you do not need the Java platform's dynamic class loading/unloading feature.
simple software: the software application is extremely simple. When the number of lines of code is low enough, the complexity of the software may be manageable, and not be overwhelming. Hence, the likelihood of your programmers being able to understand the entire system is higher, and the number of details for them to remember is lower. Under this condition, you can live without the Java platform's isolation property and language features (e.g. protection from stray pointers, automatic garbage collection, structured locking, etc.), and still be able to get a reasonable amount of developer productivity.
I will also talk more about "simple software" from the perspective of performance and footprint below.
small and restricted developer group: if the group of developers is small, then they are easier to manage. The likelihood that their code will accidentally step on each other's code is less. If there is only one developer group for the software and you will never need other groups or third parties to develop software for your device, then there is no risk of their code trampling on your code. Under these circumstances, you may not need the Java platform's isolation property and security features.
software can always be trusted: If there will never be any software deployed on your device that is from an untrusted source (i.e. can perform attacks on or crash your device), then you may not need the Java platform's isolation property and security features. Or alternatively, if you don't care if they attack and crash your device, then you may not need the Java platform.

Generally, if your situation doesn't fit into one of the above profiles, then it is likely that you will benefit from developing on the Java platform.

Why choose Java?

Posted by mlam on April 17, 2007 at 03:09 AM | Permalink | Comments (12)

Or as the lawyers will probably correct me, the question in the title would more accurately be phrased as "Why Choose the Java platform?". If you've been following my blog, you may notice that I haven't written in a while. This is because I've been really busy with my day job. One of the things that the job brought me on recently was a road trip to meet with some customers.

On this trip, I had the pleasure of having a conversation with an esteemed fellow embedded systems developer who was trying to understand the Java platform. He asked, "Why Java?". Such a simple question (simple only in its phrasing), but so pertinent. In his case, he was relatively new to Java, but has been doing embedded systems development for a long time. What he was asking was actually (1) why the Java platform is relevent for his projects (i.e. an embedded systems device), and (2) why he should choose it over available alternatives.

To be honest, I was a little caught off guard by this question. I had to pause for a while to think. On the spot, the only way I could think of to answer his question in the proper context was to tell him my personal story of how I came to choose the Java platform myself. This was the same event that motivated me to learn about the internals of a Java VM which got me hooked, and eventually led me to come work for Sun. I thought that the answer to this question that he asked may also be pertinent and interesting to other embedded systems developers who may not yet know of the advantages of the Java platform. So, I decided to share it with you here.

Powered by
Movable Type 3.01D

java.net RSS Feeds