Java: The once and future king of Internet programming

What is Java to you? A programming language you learned in college? The lingua francaof corporate IT? Would you believe that Java is poised to dominate the next explosion of the Internet? Built for embedded computing and streamlined for real-time applications, here's why Java is the language for IoT.

The years from 1969 to present saw networked devices balloon from four university computers connected via the ARPANET to about two billion humans frequently accessing the Internet today. In the near future that number will exponentially multiply again, from a couple billion networked devices to tens of billions of embedded processors. Every aspect of our lives will be connected by networked devices: homes, workplaces, vehicles, appliances, tools, toys --you name it.

Java for embedded systems

Nineteen years ago David L. Ripps wrote a JavaWorld introduction to Java for embedded systems. Ripps' article is still good reading today, especially if you want to understand how embedded systems programming interacts with connected mobile devices and the Internet of Things.

While chatter about the Internet of Things (IoT) includes a component of fashionable hype, the underlying reality is that imminent changes in Internet growth will make previous generations of computing look trivial by comparison. IoT is not only here to stay; it's here to change everything. Consider the following timeline, which shows previous tipping points for the Internet as we have known it:

• 1982-1989: Birth of the TCP/IP internet.
• 1985-1989: Commercialization of the Internet begins.
• 1990-1991: Advent of the World Wide Web.
• 1990-1998: Conventional desktop computers re-engineered as intrinsicallynetworked devices.
• 1996-present: Slowly but surely, we enter the age of global domination by mobile networked devices (aka IoT).

Complementary technologies that enable IoT are coming online now. HTTP/2 is a crucial networking protocol that has been updated, in part, to accommodate machine-to-machine communications. Thingsee is an example of a developer kit for the kind of hardware that IoT will demand.

Silicon Valley sage Tim O'Reilly has emphasized that the result will not be just the usual caricature of pointless connections from coffee machines or refrigerators to the 'Net at large. With enough sensors and automation, IoT is really about human augmentation. Java will be a workhorse in that coming disruption.

How IoT works

In September 2014, Andrew C. Oliver wrote that at an implementation level IoT is about teamwork. In this case, the teamwork involves both humans and computers.

As devices communicate not just with human consumers, but with other devices, fundamentally new capabilities emerge. It's not only that your refrigerator will know you have run out of tomatoes, but that it can place an order for more on your behalf. The success of pervasive computing will be that it recedes into the background, working out facts and events and remedies with other connected devices. Only executive-level results will be communicated to human consumers. The triumph of IoT will be in all the things that we no longer have to think about, even as they are seamlessly done for us.

The most mundane examples are the most telling. Leave aside just-in-time agricultural pest treatments, miniaturized bomb-sniffers, improved medical diagnostic technology, or similarly impressive applications of IoT in recent news. Think instead of the humble vending machine -- one that's properly stocked, well maintained, and always silently awaiting your command.

When you place your bills in a vending machine and push buttons to indicate your purchase, several mechanisms interact to ensure the satisfaction of your hunger. You don't have to understand or agree with all the details of implementation; your stomach is just happy with the results. Now, we have IoT-enabled vending machines. When you make a purchase from an IoT-enabled vending machine, your purchase triggers actions spanning the globe to keep inventory in balance and parts well-maintained, at a total cost 30 percent lower than the pre-IoT model.

Java for embedded computing

Few people today realize that Java began as a language for embedded computing. Its earliest versions specifically targeted home appliances such as television set-top interfaces. Communication between devices was central to James Gosling's original vision for Java, and he envisioned it being used for not only device-to-consumer but device-to-device communication. Twenty years later, those original design strengths are ready to support the Internet of Things.

Java's ubiquity also makes it a good fit for IoT. Massive resources worldwide are invested in transmitting Java to a new generation of programmers and ensuring that it is maintained to support all the production systems that rely on it. Hundreds of thousands of successful applications and systems already attest to Java's capabilities.

For developers exploring embedded programming it is important to distinguish the parts of the Java platform. Nothing about how you code or read programs needs to change for embedded programming: good Java programmers can read embedded source code just as easily as they do the source for typical desktop enterprise applications. The libraries, and especially the development (and testing) environments, are specialized for embedded Java programming, however. Just be sure that you have the right toolchain for the embedded environment you target.

Isn't Java too big for embedded systems?

Java wasn't always a viable first choice for embedded systems, mainly because embedded devices are often stingy on computing resources. Assembler, C, and even Python have fared better in systems with constrained memory, CPU power, or other hardware issues. This objection has largely faded away in the past few years, however, as the average size of an embedded environment has grown. Resource requirements have also shrunk with the introduction of new techniques for compiling Java for embedded environments.

Java embedded programming in 2015

Java already had the right stuff to make embedded programming possible in 1996, but it lacked momentum. Today that momentum is gathering fast, and an ecosystem of Java standards and tools for embedded programming is ready to leverage it.

Between 2000 and 2010, it was generally true that Java-based embedded or "micro" computing centered on J2ME (Jave 2 Platform, Micro Edition). Now, Java Platform, Micro Edition, or Java ME, is the standard runtime environment for embedded applications. While Java ME and its concepts --especially profiles and configurations --remain crucial, mobile Java developers tend to focus more on Android, and HTML5 for user interfaces. Cellular telephone handsets are the most visible embedded computers, and roughly four out of five mobiles sold now are based on Android. (Although Android supports Java ME, the two have different product lifecycles, and it's not entirely clear who will decide what the next generation of application environments for practical embedded devices will be.)

Profiles and configurations are crucial concepts in embedded programming. Anembedded profile such as MIDP is a collection of APIs supported on devices of interest. A configuration is a framework specification. While not strictly true it can be useful to think of profiles as belonging to configurations, including most prominently the CLDC or Connected Limited Device Configuration. (Also see "Jim Connors' Weblog" to learn more about profiles and configurations applicable to IoT.)

In addition to Java ME's profiles and configurations, a handful of enterprise Java technologies hold potential for embedded development. Java Management Extensions (JMX) is used for distributed resource management and monitoring and could one day complement embedded definitions neatly. Real-time Java also holds an important place in embedded programming for IoT.

Java's real-time model and tools

Embedded applications connected to sensors and effectors in medical, transportation, manufacturing, and other domains often have important real-time requirements. Predictable, correct results from heart pacemakers, engine controllers, pipeline valves, and so on are matters of life and death, not just annoying stack tracebacks.

While James Gosling intended Java to fulfill common real-time requirements, real-time computations weren't a strength of Java in its early years. In particular, many Java runtimes had a reputation for unreliability, or at least inconsistency in how they handled garbage collection. Real-Time Specification for Java (RTSJ) and related standards addressed temporal indeterminacy with support for periodic and sporadic task scheduling, task deadlines and CPU time budgets, garbage-collecting threads, and allowances that enable certain tasks to avoid garbage collection delays. RTSJ was approved in 2002 and has been implemented for a number of Java VMs.

Although RTSJ was officially listed as dormant in the Java Community Process until February 2015, specification experts have been actively at work refining and updating it throughout the last decade. As an example, JamaicaVM is an RTSJ implementation supported by aicas GmbH, available at no charge for educational and other non-commercial use.

Real-time's timeline

Embedded and especially real-time standards generally progress on a much longer timeline than is typical for consumer software. While a successful mobile app might peak and fade away in six months, software embedded in medical devices, automobiles, and factories often needs to run reliably for decades. Published standards that impact these applications take correspondingly longer to draft.

More recently, Oracle has promoted Java SE for real-time systems, suggesting that Java SE has been enhanced sufficiently to meet soft real-time requirements. Softhere has at least two distinct related meanings. One is that requirements have to do with average behavior; for instance, it's good enough that an average bank transaction will post within 300 milliseconds. This is in contrast to hard real-time requirements, such as the requirement that a particular locomotive-switching solenoid close at worst within one-and-a-quarter seconds of the application receiving a specific alarm. The most important requirement for hard real-time systems, in this sense, is that the worst case must be predictable.

Soft real-time is good enough for many embedded and IoT applications. For applications that require hard real-time support, Java developers largely turn to JSR-302: Safety Critical Java Technology. This spec is a subset of the Real-Time Specification for Java, and parts of it depend on the CLDC. Among other features, Safety-Critical Java defines its own concurrency model and real-time threads. The Open Group industry consortium originally began work on Safety-Critical Java in 2003. Asked about the spec's status, JSR-302 specification lead Doug Locke estimated that its long gestation will lead to an approved specification this spring, with a reference implementation possible by early May 2015.

Next up in Java embedded

Java holds much promise for embedded programming, and there is work to be done in order to enable it to meet the coming explosion of demand and possibility in IoT.Tens of billions of Java-capable devices will go into use as part of the IoT network over the next few years. My next article on this topic will feature specific examples of programming for embedded Java environments in both hobbyist and commercial contexts, along with a deeper explanation of why RTSJ 2.0 will impact Java far beyond traditional domains for real-time programming.

Courtesy:-JAVAWORLD