Java – Cross-compiling Java app to run directly on ARM

armjavajvmoperating systemsreal time

Please note: although I am using ARM SAM3X8E in this example, I'm just using that as a concrete example, and the answer to this question could easily be given using any other MCU such as AVR, etc.

I have a crazy question. In reality, its more about confirming my knowledge of low-level computer architecture than anything else, and is not necessarily something that I'm going to endeavour to actually do.

I am interested in understanding the process and tooling involved with writing a Java app on, say, a Linux or Windows machine, and then cross-compiling that app into an image that can be directly flashed to an MCU, such as the ARM SAM3X8E. I know, crazy.

Why would I ever want to do this, would be a sane person's first response. Again:

This question is more about confirming/clarifying my understanding of low-level programming/computer architecture than anything else; but
One possible reason to do this would be in a scenario where I have to have an MCU/ARM chip running an application (not a Linux box or anything else), but the application is so complicated that to write it in C and then maintain it would be a monumental undertaking. But, in Java, with its powerful syntax, data structure and massive ecosystem of 3rd party libraries/OSS components that can be leveraged, writing the app is many order of magnitude easier.

Even if you're still not convinced of my use case above (which, I'd be interested as to why), I am still interested in seeing how such a solution could be brute forced to work.

If I had to whip together a solution without any help/guidance, here's what I would do:

Implement my own JVM in C (lol)
Ultimately a Java app is fed into a JVM as input data (bytecode); and so the source code of this custom JVM would need to be hardcoded to look for a specific input file and read bytecode out of, we'll call this input file bytecode_input.c.
I would need some kind of a cross compiler that took Java bytecode (produced by javac) and converted it into bytecode_input.c. This way, when compiling my custom JVM, the bytecode of my app gets integrated into the resultant JVM executable.
Writing my custom JVM would also require implementation of certain system calls in C code, so that when an application uses FileWriter to write to a file, the JVM knows what system calls to make
Now I would just need to make sure that whatever is the output of the JVM's compilation is something that can be flashed to the MCU

Unless I'm missing anything (again, understanding that the steps above are by no means trivial and each of them are probably several man-years in the making), I believe that's all one would need. Basically, I write my app in Java, compile it to bytecode, run it through the bytecode_file_generator, turning it into a C file named bytecode_input.c. That C file then gets compiled with the rest of my JVM (which contains everything a standard JVM has, GC, memory management, bytecode verifier, classloader, etc.), which produces some executable/image that can be flashed to the MCU.

If bytecode_input.c seems mysterious and vague, here's some C pseudo-code for what I mean:

// This C file simply defines a variable called 'bytecode'
// which contains a static/hardcoded table of all the app's bytecode:
int[] BYTECODE = new int[SIZE_OF_CLASS_FILE] {
    103, 1929, 1939, 549, 9939,
    3949, 3949, 20304, 28, 238
};

The JVM then reads BYTECODE as hardcoded input instead of at runtime like a normal JVM.

Typically JVMs run on top of an OS. I don't have to worry about OSes because MCUs run programs bare metal, and if I have the need for RTOS-like functionality, I could just build that into the custom JVM.

I could (I suppose) just craft a very clever cross-compiler that converted my app's Java source into C, and skip involving a custom JVM altogether. But then I'd be losing out on all the good things the JVM provides: GC, memory management, etc.

So my question: assuming you can push the magical "Ok, I'll accept this as a valid use case for now…" button, is my approach here fundamentally wrong? Am I overlooking any major steps/processes?

Best Answer

You can compile Java to binary for a target using LLVM. A quick look at the docs shows support for many ARM variants.

https://llvm.org/svn/llvm-project/java/trunk/docs/java-frontend.txt

Also another stack-overflow style answer in this vein at

https://stackoverflow.com/questions/10804280/is-there-a-llvm-java-front-end-that-converts-java-source-to-llvms-intermediate

Related Solutions

Java MVC – Using MVC in a Java Application

This is all very subjective as multiple different technologies will be able to serve your needs.

Like others, I'll probably just recommend the technology I'd personally prefer for such a project, which would be JavaFX.

Reasons I would recommend JavaFX are:

In-built properties and binding make it easy to wire up parts of your GUI for automatic updates.
Quality graphical design tool.
Separation of UI component layout from control logic using FXML.
High quality, hardware accelerated, platform independent rendering architecture.
Wide variety of supported platforms and systems.
Support for touch interaction.
Separation of style from code using CSS.
SceneGraph based retained rendering model rather than a direct draw model.
Quality documentation and support forums plus help available via StackOverflow and a web blogging community.
Wide variety of quality pre-built controls.
Media support.
Modern, performant HTML5 engine.
Embeddable in Swing applications if needed, so you can still make use of Swing based frameworks.
Embeddable in SWT applications if needed, so you can still make us of SWT based frameworks.
Ability to support immediate mode rendering if required.
Effects framework.
Animation framework.
Graphing framework.
Open source development.
Excellent sample program.
Public issue tracker and responsive developers, doing active, on-going development so that new features and bugs get addressed in a timely way.
Backing of a major company prepared to invest considerable resources to make the project successful.
Deployable via native platform installers and executables.
Able to utilize all of the features of the massive JDK and java based libraries and projects.
Can be used from a variety of programming languages, such as Scala, Groovy and Ruby.
Nice interactive development and debugging utilities as well as the ability to use a standard Java debugger to debug your program.
Quality layout managers.
JavaFX has been designed to take advantage of Java 8 lambdas.
JavaFX applications are deployable to commercial app stores.
JavaFX can be programmed using the best IDEs in the world.
Strong concurrency utilities.

OK, I guess the above is a bit of a tangent, but I like to promote JavaFX ;-)

Anyway, to address the specific points in your question:

JavaFX is a cross-platform GUI framework (currently Mac/Windows/Linux).
JavaFX has inbuilt, high quality multiple threading support (the core framework itself is single-threaded as is just about every other GUI platform out there, but you can define your own tasks to be executed concurrently off the GUI thread so that the GUI thread remains responsive).
A well written JavaFX program should have no issues performing well enough to visualize fairly large quantities of data. Here is a sample JavaFX project which does that.
The ability to style the application via css, make use of visual effects and animation, allows you to work with designers to make your app look great or do it yourself if you have the skills.
JavaFX has a TableView and a TreeView you can use. There is also a combined TreeTable control which has been developed in preparation for the Java 8 release.
The custom figure drawing widget could use scene graph shapes or a direct draw canvas - it's really just a matter of coding style and preference.
JavaFX's properties and binding facilities coupled with it's event listener frameworks makes it trivial to modify data using one control and have the changes immediately reflected in other controls.
For MVC style development, you can write your model using plain java objects, define your view using the FXML markup language (created using the SceneBuilder graphical layout tool if desired) and define your control logic in Java (or another scripting language if you prefer), plus you should separate your style from your logic by using CSS.
As you have limited exposure to Java, the learning curve will be significant. There are excellent Java tutorials in addition to the JavaFX tutorials I linked to earlier which can help with this. JavaFX core code uses only facilities available in the JDK, so to use JavaFX you don't need to learn a lot of additional libraries and frameworks (as you would if you were learning JavaEE for instance). So those two tuotorial sites provide most information you need to get up to speed.
For app organization, if you have a complex application and need the backing of a complete, proven client application framework and don't mind doing a lot of extra learning, then you can embed JavaFX in the Eclipse RCP or NetBeans RCP, which, according to their pages could save you years of development time. I'd only advise looking at such platforms if your needs justify it though, because for small to medium size projects, it will probably be simpler to code the stuff up directly in JavaFX without the complex client platform frameworks such as Eclipse and NetBeans.
As to whether you should use Swing or JavaFX, I'm not really the most objective person to answer that. JavaFX definitely has shortcomings which would become apparent to you as you start to use it (as does Swing).
For online tutorials, I've linked to most relevant ones. There is a nice tutorial set for a complete app.
The books Pro JavaFX 2 and JavaFX 2.0 Introduction by Example are highly rated.

RTOS vs Bare Metal – Benefits for MCU Programming

Microcontroller programs consist of a number of tasks. Let's say you wanted to make a computer-controlled telescope mount. The tasks would be:

Retrieve a new byte of input from the USB serial buffer.
Check if we've received a complete command.
If so, execute that command.
Read the sensors for the current telescope position.
Set the proper output to control the next step of the motors.

This is a fairly typical set of tasks for something you would use a microcontroller for, and are pretty easy to manage with an infinite loop, like:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

If you keep adding and adding features, you eventually start coming across common problems you want to create abstractions for, like:

Your buffer is overflowing, so you want to make sure that task can interrupt other tasks before it overflows.
You want to save battery by sleeping when nothing is needed.
You want to make sure all tasks get a fair shot. If readSensors takes too long, you want to be able to interrupt it and come back to it later.
You want to be able to just reset one task without affecting others.
You want a memory leak or other bug in one task to not take out the other tasks.
You want to be able to give different tasks different priorities.
You want to be able to sandbox an untrusted task.
You want to be able to execute tasks at different rates. Perhaps your sensors can only be read 10 times per second, but you want to execute a motor step 100 times per second.

One or two of these items can be handled manually relatively easily. If you have enough of these kinds of problems frequently enough that you start generalizing them into libraries, you've basically reinvented an RTOS. If your program's task management is complex enough, even if you don't use an off-the-shelf RTOS, you will eventually end up reinventing one poorly.

However, in my experience, the line where you want an RTOS is very close to the line where you want a microprocessor instead of a microcontroller. If you anticipate your firmware getting that complex, it's usually better to go the microprocessor route from the beginning.

Best Answer

Related Solutions

Java MVC – Using MVC in a Java Application

RTOS vs Bare Metal – Benefits for MCU Programming

Related Topic