Embedded Systems Programming using Java [closed]

Question

Is Java good-to-learn-next language for an embedded software engineer who mainly develops firmwares and drivers? If not so useful, why?

Which language is more for that purpose, C++ or Java? I read on a lot of websites, that Java is the most payed programming language nowadays, but also that C++ mixed with C is very used in embedded software development.

I want to hear from some embedded software engineers on what programming language (C++ or Java) to pay attention for purpose I wrote above?

I think that just C is not enough and want to go in right direction, and not to learn something I will not use in embedded systems.

Thanks.

Answer 1

I always use C programming language to program many embedded modules and microcontrollers. I have wroked on Atmel's PIC's STM controllers and programming them using C works fine always. Apart from this if you are planning to make UI interface for your embedded design and you are in windows, you can do it with C++/C# in visual studio or if you are in linux you can do it using gtk/glade which can be done in C. So if you want to design firmware or want to write drivers, you can use C. No need of java. I have never heard someone using java to make driver or firmware

So I think C is enough to start with any embedded design.

Answer 2

I guess it depends on the size of the embedded system which language will actually be usable and useful.

For small devices I just can't see Java running at all on them. Oracle says that with 11MB you can run Java SE embedded on the device (1). There is the smaller Java ME embedded, which is quoted to need 1MB of ROM and 128kB of RAM (2). So Java is (for me) not a very scalable language in the downward direction. I can't tell how pleasurable it is to program Java on embedded devices as all of my projects were smaller than the minimum for Java ME.

On the other hand, C++ offers a lot of features you might want to use. It isn't that much of a difference performance and code size wise. If you don't use RTTI and exceptions, the code will grow by a few kilobytes without gaining much at first sight. The C++ runtime environment will be a bit bigger, there are some embedded C++ variants which bring these overheads down to barely visible numbers but prevent even more C++ constructs like templates.

But C++ offers you the ability to implement classes and inheritance, all the good OOP stuff basically. You can write hardware drivers completely in C++, so there is no need to go back to C at any point in your system, even the startup code can be written in C++.

I'd say in embedded systems you won't be able to play all the strong cards from C++ as some features aren't usable or allowed to be used. As example: dynamic instantiation is forbidden for safety critical applications (at least in my environment). Templates are also a debatable topic for safety critical applications as test are a bit of a hassle as they get dynamically created for each data type and you have to prove that your tests cover every data type used.

From a source code perspective, I find C++ creates a clearer concept of who does what and a clearer structure and is preferable over C.

Though if you are running on the really really small devices, you probably end up switching back to C or assembler alltogether.