The title says it: we're putting Java on the new Luminary Micro boards equipped with the ARMv7 Cortex-M3 processor.
(Unfortunately, by "we" I mostly mean "I", and by "I" I mean an intern with only two more weeks to go. But by then I believe I'll have a good foundation for others to continue the process—and with any luck, the core Squawk J2ME VM will be running too.)
Suffice to say, these past few weeks have been a bit of a grind. And I'm beginning to appreciate Java more and more.
After installing all the tools and getting them to work together (which honestly took a few days in its own right), and after brushing up on my C, and getting the example demos to compile, link, deploy, and run (another few days), I made a sample project of my own inside the standard build area, then moved it out to a remote location to get a good understanding of the required files and dependencies.
Now I'm taking a stab at getting Squawk to build using the StellarWare + CodeSourcery G++ tool chain. First attempts: a few hundred lines of compile errors. A couple days later, those are all resolved—well, if you count stubs as resolutions. I'll work on getting it to build first, then worry about getting it to actually run.
Finally, I figured out that last compilation error. Which was promptly replaced with around 800 lines of linker errors. Delightful.
A few more days pass, and now I'm down to three linker errors (hopefully no more will crop up in the meantime): something about two sections overlapping (probably an error somewhere in the linker script I'm using); a function that should exist but doesn't (strsignal, may have to implement that one myself); and an undefined reference to some "_fini", which has turned out to be very difficult to find out any useful information on.
With regards to that last one, _fini, it seems like it may be involved with
some vector/array allocation, and maybe should be defined in some linker script; I'm not sure. For that matter, I'm not even sure if it is in fact a variable or a function.
Thus far, the only comment I've seen in direct regards to it said approximately, "Can't figure it out. Workaround: just cut things
until it's not called any more." Honestly, a day spent trying to find a better solution, and right now I myself am falling back on that plan for now, if only to get an idea for what it does. Or stub it for now and see what breaks later.
(Oh, it appears to be some function that's called on a shutdown process for additional clean-up: a do-nothing stub will apparently suffice. Whew.)
And so I am reminded of the good days programming in Java, and why we're going through all the trouble to stick it on such a small, resource-constrained device. In short: so that other developers don't have to go through all the headache I am. With Java's interfaces and abstract classes, when a library fails because it's referencing a function that has not yet been defined, the result is an error in your code, not the library itself (and you don't need to figure out what was calling the darn thing in the first place, say by digging through all their source that they didn't give you). Moreover, the libraries are standardized and well-documented (the javadoc tool makes that easy), so instead of spending most of my time researching the implementations for common (or especially rarely-used) functions on the internet to copy and paste, I have everything right at my fingertips. Automatic memory management, and no assembly. And, let's not forget: no naked pointers, or for that matter, pointers in general. Yea, that's nice (even if I have to do a few extra bit shifts).
Sure, maybe you're awesome and like to do all that low-level stuff yourself—go have fun writing in C. This is for all of us who like to be able to quickly and painlessly put together a quality implementation that works.
—Java on Cortex M3—
