WouldYouUseJavaOnEmbeddedDevices

Continued from JustAnotherLanguage? --- OliBye suggests PutItToAVote.

Would you use java on embedded devices: 1. ...because it was the language you used last time? 1. ...because it's fantastically memory efficient ? 1. ...because it's "write once, run everywhere" ? 1. ...because it's flavour of the month? 1. ...because it makes excellent use of limited processing power? 1. ...because it allows developers to deliver business benefit more quickly? 1. ...because it has a larger population of competent developers from which to draw development effort? 1. ...because it's good enough for the job in hand?

And having answer that, WouldYouUseJavaOnEmbeddedDevicesAgain? ---

TimBacon believes that these questions are irrelevant in an XP environment. If you're writing software for an embedded device, and that device has Java support, and you're comfortable with writing, testing, building and deploying Java applications, then why not use Java? Try it for an iteration, see how many of the UserStories you can deliver, then sit back, examine your navel and consider if another approach would work better for the next iteration. (Per the YouReachedTheEnd thread.)

You also have to remember that there are JVMs are there are JVMs. On the Palm for example there is SuperWaba? and there is MIDP: the first is smaller and faster but has limited device support and comes with fewer class libraries. So there is no single 'best' option. And the same is true of programming languages -- which is why I started the JustAnotherProgrammingLanguage thread, yes I was that anonymous person ;-)

Life is full of tradeoffs, and we can't escape them. More than that, the nature of the tradeoffs changes over time... and that's where XP comes in. Programmers often have a very black and white view of the world, in which all questions have a single answer. This is clearly naive. The correct answer to "WouldYouUseJavaOnEmbeddedDevicesAgain??" is "That depends..." ---

This was OliBye's point, i.e. I doubt KeithB's use of Java on EPOC has much to do with the choices mention in JustAnotherProgrammingLanguage at all. There are too many reasons why certain things are, and are not. My personal experience is that the XP practisces will bring you through these things. I'm not afraid of BeingWrong as I've done it so often. XP says that BeingWrong is ok, which is a cunning sales pitch.

KeithB here. As it happens, we don't make much use of Java on EPOC. We mostly use C++ on EPOC--we use it to impement Java APIs (hehehehe!)

To answer your question, thought, if I had the task of writing some random application for an EPOC device then I'd seriously consider using Java, at least for the GUI. I'd probably then look for any performance problems that weren't for example, network bound, and do some JNI to get those bits to go fast in C++. After all, I can't guess that Java won't perform well enough, right? Might need some JNI anyway to get access to useful stuff outwith the java APIs. This decision would indeed be based on my past experience of EPOC C++ (it's highly capable, but a horror story to work in) and Java, MIDP/CLDC specifically--especially if it's our MIDP--on EPOC (it's not nearly so clunky as you might think). This is called an "engineering tradeoff". And, indeed, we make exactly this sort of decision all the time when working some part of the Java library: will we implement such and so a feature in Java, or in C++? We have even be known to change our minds about this later!

Bear in mind that "EPOC device" includes some pretty beefy kit these days (in hand-held terms, anyway), and geting bigger all the time. Java is indeed flavour of the month, and that makes it more likely that the theoretical customer will want the Java box ticked, but not neccesarily that they will insist that the pure java box is ticked. If they did, well it's their funeral. As you say, there are many reasons why things are the way they are, but that has little bearing on the discussion in JustAnotherProgrammingLanguage, which does not seek to answer the question can you make decisions about what programming language to use on some random project, but rather, if you could, would it be worth bothering?

And I strongly agree that if, for whatever reason, you can't make such a decision then the XP practices will do a lot to stop that being a major difficulty.

I'll keep you posted as and when we win some work that needs any significant server-side brains. I'll be strenuously arguing (albeit briefly ;) that any such brains should be written in either Smalltalk or a functional language.

OliBye never did find the references in the press about what you're up to. I'm intrigued.

You know exactly what we're up to, we're doing a kick-arse MIDP/CLDC implementation for an EPOC device.

Who's device? What else will it do? When will you be able to buy one? That's a different matter all together ;-)