Posts Tagged ‘java’

Embedded Java Lives!

Wednesday, December 16th, 2009 Michael Barr

Reading the latest embedded software market survey highlights from VDC Research I was surprised to note two data points indicating new upward momentum for Java as an embedded software development language.

First, of those survey respondents using an operating system on their current project 11% indicated that a Java Virtual Machine is required in their product.  Second, Java was selected as the fifth most used language for firmware development at 14% of respondents (behind C, assembly, C++, and Matlab, in that order).

This is an interesting trend.  My regular readers will note that I have written and spoken about Java in embedded systems since 1997 and that I declared Java “dead” in the embedded realm about 18 months ago.

Making Java Real

Saturday, March 30th, 2002 Michael Barr

Embedded processors span a wide range, from tiny 4-bit microcontrollers all the way up to 64-bit current sinks. Both chips and cores find themselves employed in systems with varying degrees of real-time requirements. In the middle of these spectrums, and most typical of today’s embedded designs, are the many soft-real time systems built around 32-bit processors. These are precisely the systems that should benefit from the recent completion of the Real-Time Specification for Java (RTSJ).

Having spent too much time in my career debugging silly typos because of C’s weak syntax rules; porting pieces of code from one RTOS’s threading API to another; keeping track of compiler differences related to the size of primitive data types and the order of bitfields; and trying to learn all the ins and outs of C++’s overly-complex brand of OOP, I was taken with Java right from my first encounter with the language, in 1996. When I attended a discussion about making Java suitable for real-time use about a year later, at the National Institute of Standards and Technology (NIST), I learned I wasn’t the only embedded programmer who’d taken a liking to this new language.

Of course, the reason we were all drawn to that discussion was because Java was decidedly not ready for real-time. As the Java language had moved out of its R&D origins at Sun and become popular with Web and enterprise application developers, its standard libraries had grown appreciably and its basic definition had become far too loose. For example, the built-in priority-based threading API, which should have proved useful as a basis for real-time software, had by then been dumbed down to the point that even those the few scheduling rules weren’t enforced by most JVM (Java Virtual Machine) implementations.

A result of that initial NIST meeting, and several working group sessions that followed, was the consensus document “Requirements for Real-Time Extensions for the Java Platform”. This document captured the opinions of experts at more than fifty companies and organizations (as well as the Department of Defense, which was seeking alternatives to Ada) on the subject of real-time software. It ended by stating a baker’s dozen goals, plus derived requirements, for any eventual real-time Java specification.

Last November, the real-time Java spec we hoped for then became a reality. So many folks wanted to see a real-time version of Java, in fact, that the RTSJ was the very first effort (JSR-001) to come out of the Java Community Process. (Even the language’s creator, James Gosling, signed up to help out.) Led by IBM, the work of the so-called Real-Time Java Experts Group resulted in a specification that describes how a real-time Java Virtual Machine must behave, a reference implementation, and a testing compatibility kit.

Among other things, the RTSJ addresses scheduling, synchronization, and garbage collection. For good measure, it adds a standardized way to peek and poke physical memory (and, thereby, memory-mapped peripheral status and control registers) and high-resolution timers to the Java libraries. By setting only a minimum standard in many areas, it also leaves the door open for advanced/alternative real-time schedulers to be offered by competing implementers.

I want to take this opportunity to thank all of those who have rolled up their sleeves and brought us closer to real-time Java. Your efforts have been worthwhile and the results look promising. Keep up the good work.

Unfortunately, we’re not done yet. The effort to bring Java to a wide range of embedded systems must include developing small (50-100KB) JVM/RTOS combinations that are compatible with RTSJ. Something along the lines of a real-time version of Sun’s KVM ought to do the trick. I’m confident we’re getting close to that final solution.

Embedded Java Update

Tuesday, October 9th, 2001 Michael Barr

I first encountered Java in 1996. At the time, I was working for a company that built satellite telemetry equipment. Parts of this were real-time/embedded—mostly VME boards running VxWorks. But other parts of the data post-processing were done on Sun workstations. I became interested in the language when, pulled aside from my usual embedded programming responsibilities for several months, I was enjoined to help write some workstation software in Java. It was love at first compile.

I was immediately wowed by the Java language. I loved that it’s basic syntax was very like C’s, but that its creators had addressed many of that languages inconsistencies and pitfalls. I was also impressed at how much faster it was to program in Java than C++, a language I’d tried to love but never been able to. At first blush, Java also had some cool features for embedded programmers—things like fixed-width integers, a portable binary format, guaranteed protection from memory leaks, and built-in support for threads and synchronization (no more porting your embedded code from one RTOS API to yet another).

The only problem was that I loved embedded programming more—I still do. So I’ve been on a five-year odyssey of hope; wanting to use Java in my embedded programming, but never having the opportunity to do anything more than experiment. I’m still convinced the language is awesome and that embedded programmers using C++ would benefit heavily from switching over to it. However, the priority in our field is always on shipping a product vs. hoping some new language or tool will make the process easier.

To find out where things stand with embedded Java today, I organized and moderated a panel called “Is Java Ready for Embedded Use?”, which took place last night at the Embedded Systems Conference in Boston. The panel consisted of two real-time Java gurus and four embedded programmers who’d recently used Java technologies from Wind River, Newmonics, aJile, and other vendors. Here’s what I and the other attendees learned from the panelists.

The most important thing we learned was that people are now building real systems (and even shipping some of them!) with Java. Of course, the Real-Time Specification for Java (RTSJ) is still several months away from having a complete reference implementation (RI) and testing compatibility kit (TCK), so today’s embedded Java users are mostly from the “no-real-time” side of the house.

A common current use for Java is as a user interface engine. In other words, the real-time and device-specific stuff is still being done in C. A Java Virtual Machine is simply added to the system as a mechanism for executing complex, and perhaps field-upgradable, user interface threads. The big advantages are that: (1) any competent Java programmer can be enlisted to produce that part of the embedded software, and (2) feedback from marketing and target customers can be sought and incorporated long before the actual hardware is complete. Wind River says that about 10% of its RTOS customers are also licensing a JVM from them and using it for such purposes.

Another option is to base your system design on a Java processor and write all of the firmware in Java. The processors from aJile Systems, in particular, support many of the features recommended by the draft RTSJ spec. This means that real-time programming in Java is available today, in quantity. And aJile has already stated they’ll conform their technology to the final spec, as soon as the RI and TCK are available.

It should be extremely interesting to watch the embedded Java space over the next one to two year period and to see how an increasing number of users will take advantage of its many great features.

Open Source Embedded Software

Wednesday, September 12th, 2001 Michael Barr

Magazines like Embedded Systems Programming are founded on the ideal that the free flow of information between technological peers, even at competing organizations, benefits everyone. This is a view shared by the proponents of open source software. Whether it’s an operating system, a memory test suite, or simply a useful design paradigm, why should any one of us reinvent what has already been invented (and tested) by others in our profession?

Certainly, there are exceptional projects with exceptional needs. In such cases, invention of new techniques and technologies cannot be avoided. We can’t always combine existing components into a useful whole. However, such exceptional cases are rare. To take an example from childhood, you can build quite a lot of neat things with a basic set of Lego’s, but a “spaceship windshield” is a one-of-a-kind part for one-of-a-kind projects.

Most of the time, though, we’re all using the same basic components. Processors, operating systems, device drivers, and other building blocks are transferable from one company or project to another. Once developed, a technology or technique is, in fact, most valuable when it is shared with others. This benefits the creators too, as others may strengthen the component by finding and fixing flaws. This is the academic model of development, transferred to the commercial marketplace.

Unfortunately, there are many roadblocks to such openness. I recently ran into one of these when I tried to arrange a new point/counterpoint discussion. As envisioned, the debate would have addressed the differences in thinking and approach between two competing groups working toward real-time Java. A technological leader of each group was willing to participate and both thought this open debate would be a good way to uncover any flaws in one or both approaches. It might even have helped to bring the two groups together, if they found a high degree of overlap.

Plans for the debate were put on hold, though, after non-technical people on both sides expressed concern. It seems both groups are jockeying for position in the marketplace; both hope their approach will become the de facto standard for real-time Java. Though both groups acknowledge the need for open debate in the discussion of technology that could risk human lives and are conducting their own meetings publicly, they remain unwilling to debate each other.

In addition to the feeling of frustration at the intrusion of non-technical issues and people into what should have been a purely technical discussion, I also have a feeling of dread. I suspect that progress toward a real-time Java standard will be slowed (or doomed to failure) as a result of the lack of discussion. How can either of two competing solutions to the same problem be adopted as a standard without such a debate occurring first? What are those of us outside the two groups to think if these two large self-proclaimed “expert groups” cannot achieve a common standard on their own?

As the open-source movement has caught on in recent years, there have been more and more attempts to create semi-proprietary “open” standards groups. Sun’s Java Community Process, which is behind one of the two real-time Java groups, is a prime example. But it’s not at all clear that today’s “open” standards groups are anything more than the old proprietary standards, disguised.

NOTE: this article originally published on 12/6/00.