 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Java ME Working Group Meeting Minutes for March 26, 2017DateWednesday, March 26, 2017, 9:00 am PDT LocationTeleconference AgendaRefine materials submitted by Working Group members. Attendees
MinutesWe used the session to discuss and refine updates to the Working Document (see below). We will discuss the April 4 EC Meeting.
Java on Embedded Advancing Java on Embedded Devices
OVERVIEWThe JCP EC established the Java ME Working Group to address the concern of EC Members about the current state of Java ME, and this document is its deliverable: a set of use cases and requirements for Java on embedded devices. In the January 2017 JCP EC Face to Face Meeting, V2COM presented their current view of the Java ME platform. When Java ME 8 was launched in 2015, Oracle stated that its goal was to keep Java ME and SE releases synchronized and keep bringing the two versions closer together, regarding functionality and language features. But time has passed and no activity could be seen from Oracle regarding Java ME: content for JavaOne 2016 was high on Java SE 9, Java EE 8 but no word on the next iteration of Java ME. Some minor releases (8.1, 8.2 and 8.3) were made, but as Oracle started filing JSRs and announce Java SE 9, there was no Java ME activity outside Oracle. V2COM started raising concerns about this and requested an update from Oracle, much like what the JCP EC members requested about Java EE 8. While Java EE 8 concern was addressed in EC meetings and JavaOne 2016, no update was give about Java ME for months, until the JCP Chair announced [in December 2016?] that Oracle had changed management on Java ME to Georges Saab and we could come with a guiding document on our set of requirements for Java on embedded devices and feature phones. GOALS
USE CASESThere are many different IoT use cases, with completely different set of technical and business specifications. We are focusing on two different device classes that group some of the desired characteristics, but by no means this is an exhaustive list and a Java embedded platform should be thought as ranging from low power[capability?] and/or low memory platforms such as ARM Cortex M4 with 1MB RAM and 1MB Flash to high power such as Intel Joule SoC with 3 GB RAM and beyond. Specialized DeviceA specialized device is targeted to a specific function, and it runs on specialized hardware. This means that its overall capabilities will not change over its lifetime, but there still is a need for small updates on business logic and bug fixing. These devices are also constrained regarding cost: manufacturers will try to squeeze its costs to as low as possible, for these devices are for mass production and every penny matters. We are considering that these devices do not offer a standalone OS: its firmware is normally a merge of OS and business functionality, and updates are done changing all code at once. They might have external storage memory, but that is not always the case. Regardless, all memory (volatile and storage) is premium and usually there is "just enough" memory for it to work. Gateway DeviceA gateway device has a broader scope of function, when compared to a specialized device. It also has a more generic hardware, with enough I/O and storage to allow it to handle different functions over its lifetime. As its name implies, gateway devices also can serve as a bridge or connector between two device networks, usually between a closed/proprietary/local network and the Internet. Besides bridging the networks, it can run tasks on behalf of these devices, such as report status, and aggregate data for local analysis. TECHNICAL SPECIFICATIONS
PerformanceSpecialized devices are associated with tasks that require fast startup time - such as car infotainment systems. Hence, it is very important that the VM can be started with the least amount of time possible. Specialized devices are also sized to have just enough processing power, to save on costs. This brings the overall capabilities down, and has an impact on start up time as well as other parts of the VM such as garbage collector pauses and multithreading. Special consideration has to be taken on VM level to address this low power devices. Gateway devices normally do not suffer performance penalties, as they normally have hundreds MHz processors and one or more cores. SizeThere are two size constraints on specialized devices: RAM and ROM/Storage. RAM consumption on specialized devices is critical and when working on such code, one has to take extra care on object creation and heap size. And in order to make most memory available to the application, the VM should take as few RAM as possible, with lazy initialization of mostly everything. (It does come to a trade-off between size and performance...). Java SE 8 Compact Profile 1 has a footprint of X MB of used RAM just to print "Hello World", which is too much for specialized devices. ROM (Flash or Disk storage) is also a critical constraint: storage memory on these devices is costly and in many processors, it is built in into the processor. So there is not much space to "waste" on unused features of the VM. Case in point, the Java ME 8.2 release for FDRM-K64F board uses all the 1 MB available in the processor, and requires the user code to be loaded from an external memory. That leads to added BOM cost and hardware development time. For gateway devices, this is not always an issue, but when one considers Over-The-Air Updates of the VM, a 100MB download to update the whole VM can be expensive and even prohibitive. With Java 9 and modularity, we may be able to have a smaller base VM that can try and fit in specialized devices. We are still missing information on how Java SE Embedded 9 package definition differs from current JDK 9, but this might be an area for concern. Something that might be better for specialized devices would be to merge both binaries - VM and User Code, "gutting" the VM and taking out unused classes. This might decharacterize the VM as a Java compatible VM, but that is not important for some use cases: the developer is not trying to sell a VM, but instead want a single binary that is able to fit in a small processor flash memory and run its business code. Java ME/SE Language Level CompatibilityJava ME and Java SE, historically, were too different APIs. But, with the release of Java SE and ME 8, they are converging. Java ME 8/MEEP was a huge step to be more SE like and the SE profiles made SE more like ME when comparing sizes. But what gets out of this is too static. For example, one can either use a very small runtime without JNI or a bigger runtime without some of the ME frameworks. Although ME now supports most of the SE 8 language features, some are still missing. The situation with class libraries is similar. Comparing Java ME to Java SE, these are the following missing pieces that are considered relevant in embedded design. Maybe these can start as separate, optional JSRs for the Java ME platform.
Comparing Java SE to ME (MEEP), basically everything that makes MEEP a relevant framework for IoT:
Native Code SupportOne of the more concrete things missing for embedded development is better operating system/C/C++ integration. Libraries like JNA and Device I/O is a step in the right direction, but these are not part of the Spec or the default platform. IoT Specific or New APIs/JSRsThere are emerging standards for IoT communication that today are supported in Java via JSRs (like JSON) or not (like MQTT and COAP). Java Standardization of such standards can be done to guarantee that the platform support is available for them with the IP protection granted by the JSR process. Such standards are, not exhaustively:
These efforts shall not be done exclusively by Oracle, but other members like V2COM can step up and work to get these as separate JSRs, that can be eventually merged into a future Java Embedded release. As part of this new APIs and JSRs, there is also need to update old JSRs. Updating Old JSRsSome old JSRs need either an update or rework to address evolving technology. JSR 177Security is a critical aspect of IoT, and JSR 177 provides Java ME applications with APIs for security and trust services through the integration of a Security Element. Since its latest maintenance release in 2007, new technologies and needs have emerged, access to TEE (Trusted Execution Environment), SE (Secure Element), services like secure storage and handling of credentials for TLS. JSR 361JSR 361 updates IMP(-NG) to align with state-of-the-art features and current embedded device market requirements. This brought many needed updated, but some use cases are still hard to be address, specifically when considering multi-midlet environments. BUSINESS SPECIFICATIONS
LicensingCurrent business model does not scale. Dated licensing model licensing. Need a frictionless technology onramp and then standardize. Development ModelSimilar development concept for Java ME as for Java SE (→OpenJDK + JSRs). Which implies that everybody can get the source and port it to a target system. For business reasons would like to see as JSRs - standards are important to ensure safety. Development as a JSR protects implementers from litigation. Board Support PackagesAccess to the technology blocks adoption. Downloads not available for broad support package. It is not a box package - need easier download availability. Access will increase demand and adoption. There is a need for a binary to download with porting compatibility. OTHER CONSIDERATIONS
Different Set of RequirementsThere are different set of requirements for every vertical and even use case in IoT. As such, the current way of sharing a single platform/binary that contains the whole JSR specification may be outdated. There is a structured way to get a personalized VM for the current Oracle Java Embedded, where you get the JDK with functionalities that you need. But that is still too coarse. A better way would be a legal and safe method to pick-and-choose the functionalities/classes that we need for our target environment. Low Java ME 8 AdoptionBusiness related aspects contributed to low Java ME adoption immediately following the release. The technology met needs, but the costs to migrate were too high. In the meantime, most of these issues have been resolved. JSR LeadershipDoes Oracle want to lead or allow others to lead? It is possible for others to lead, and others have led JSRs in the Java ME space in the past. Most members on this Working Group would be willing to participate in JSR activity, but not necessarily lead. Eclipse is interested as a potential source for communing members interested in leading JSRs and V2COM is interested in leading some of the JSR efforts. But some JSRs are either touching Oracle IP (such as Device I/O) or are already lead by Oracle (such as JSR 177), so we need a clear position from Oracle on how to resolve such issues. Market DemandJava is the only standardized platform which scales well. Many people are not aware of this. Java as an IoT platform also offers the developer appeal of an end of end technology platform. Not only program servers and backend applications, but also small devices. This is something that no other platform can do. These aspects together can create a business demand for Java as IoT platform. [LJC:] Java ME enabled feature phones are still potentially interesting for the developing work. Presently 44% of the world has access to the Internet. India and China have a population of 1 billion each, Africa 1.2 billion, South America 422 million, Russia 144 for a total of approximately 4 billion people. 4 Billion people are more than half of the global population of 7 billion. Many of these populations are too poor to afford smart phones but can afford inexpensive feature phones. If the average value of engagement per person in these areas were as little as a quarter of a cent, multiplied over 4 billion people it would still be 1 billion dollars. This figure might be generous but it makes the point. The sheer number of people reachable in the developing world could compensate for relatively low revenue per user. In every country in the world there will be banks. Java ME feature phones might well be the primary computer with which users interact. Could JavaME drive a new mobile revolution in the developing world as it did in the 1990's in the developed word? Are banks interested in using this platform to offer online banking to their customers. Without JavaME mobile apps have to be written in handset specific C/C++ which makes supporting multiple feature phones very challenging. Personal interest in this area is for humanitarian and charitable work. Apps that help improve individual users lives or protect them from danger or provide access to education and information. Notes from the state of Java ME on feature phone:
Competing TechnologiesThere are plenty of other technologies that developers can choose from to develop their embedded devices. We want to learn from them and adapt Java to continue its relevance in this market! Some of these technologies are perceived as either less expensive, hip, mainstream and/or accessible. Node.JS (and embedded JavaScript)[How are they using Node JS on IoT?] Android/iOSThere are some de facto developer and runtime environments at Android/iOS, so we do not need Java ME in this area. [BUT, there might still be feature phones around?! See input from LJC.] Android Things"Android Things makes developing connected embedded devices easy by providing the same Android development tools, best-in-class Android framework, and Google APIs that make developers successful on mobile." Link to Android Things: https://developer.android.com/things/sdk/index.html Windows IoTLink to Windows IoT: https://developer.microsoft.com/en-us/windows/iot Ubuntu CoreLink to Ubuntu Core: https://www.ubuntu.com/internet-of-things/gateways While not directly a competitor, it does make using other stuff easier. Eclipse Edje and "small Java VMs"https://www.eclipse.org/community/eclipse_newsletter/2016/september/article1.php mbedOS
OSGiOSGi as a framework to supplement Java SE with Java ME-like services (provisioning, configuration). Why have this as Java and not OSGi, or any other thing running on top of the Java SE JVM. Next StepsRefine to publish for discussion at EC meeting April 4. We will meet again on April 19 to prepare for May EC Meeting. After the April EC meeting, we will incorporate feedback and prepare slides for May EC Meeting. |
