• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Java ME Working Group Meeting Minutes for March 1, 2017

Date

Wednesday, March 1, 2017, 9:00 am PST

Location

Teleconference

Agenda

Discuss and assimilate materials submitted by Working Group members.

Attendees

• Heather VanCura
• Leonardo Lima
• Calinel Pasteanu
• Thomas Lampart
• Mike DeNicola
• Mike Milinkovich

Minutes

We used the session to incorporate meeting materials into a proposal to discuss at a future EC Meeting (April 4 is target date).

Java [ME].Next (Embedded World)

Advancing Java on Embedded Devices

OVERVIEW

Java as an IoT platform. Goals and requirements for Java ME, technical and non-technical, including business aspects, market demand and what is preventing adoption of current Java ME platform, Java ME 8. Why would a Java ME 9 do better in adoption than Java ME 8.

We discussed different options today and what have members done with Java ME. What are the differences between Java SE 9 and Java ME and why Java SE 9 might not meet requirements of this market and why Java ME is important. Is there a need for new JSRs? Calinel agreed that there is one gap, and a "low version" is needed, API and semantic parity is needed. There are two possible ways of doing that: new from scratch, or update Java ME. V2COM uses older version, Gemalto doesn't use Java ME 8. Why the Java ME licensees haven't upgraded to Java ME 8. From the IoT side/libraries, there's no explicit need of platform support, no need to have a JSR for the protocols, it's already available from Oracle for download from the website.

Thomas confirmed that Java ME 3 is proven and stable, clients like it. There's no market demand for Java ME 8, but that might change in the future - clients don't want to have two code-bases and so continuing the convergence of java ME/SE is a good thing. There's no indication of new Java ME work, so using Java ME 8 seems not future-proof. If there's a Java 9 in the works, continuity would improve perception. Java ME 8 adoption issues for Gemalto are just non-technical, technically it is good and everything they wanted is in there. What kept Gemalto from using Java ME 8 were non-technical business reasons. A model like SE development would help Java ME development and adoption, as no one can do any work but Oracle - all others would have to start from scratch.

We discussed Java as an IoT platform. Hendrik discussed that we need a version of Java for ow processing power systems. The name is not important, not GUI, but a very small run time would be needed. This version have to be something that is in line with SE, feature wise - gave an example of different String file. Java 9 with its module system might be a better solution; a fork of Java is not a good solution. Requirements: fast startup time, low cost. JAR File format is an aggressor to startup time, for example. There's no currently suitable solution for 32-bit, 200MHz processors - they go to C/C++. As an alternative to evolving Java ME, can we take Java 9 and make it fit in Java ME specs. Java ME adoption might not be great because of its licensing model. Look at the requirements: why SE 9 does or does not meet the requirements, and look into the future for Java 10. It's a lot harder to sell embedded runtime, there's a need to recompile and conform to processor specs.

GOALS

1. Describe technical and non-technical requirements for Java to be relevant and useful in embedded devices and IoT.
2. Provide grounds for discussion with Java leadership within Oracle on how to improve Java ME, or the next version of Java for Micro devices.

USE CASES

There's different set of requirements for each IoT / embedded use cases.

Specialized Device

(constrained device, specialized hardware)

Gateway-class Device

(less-constrained device, has an OS)

TECHNICAL SPECIFICATIONS

Performance

[Microdoc: Startup time]

[Low core/speed processors]

Size

[Total size of VM + application code can important, using Java SE 9 might result in a big VM for lots of environments, <<describe environments>>

[RAM consumption by Java SE x Java Me]

[Werner Keil]

In Java 9 the java.base module seems much too big for Embedded or ME:

http://download.java.net/java/jdk9/docs/api/java.base-summary.html

Shows it contains both java.util with Date/Time and the "new" Date/Time API which Spec Leads claim is too big for ME and modularity wasn't a requirement.

Does the java.base module look different in Java SE Embedded 9 or is it identical?

Could a smaller "base" module be found that's small enough for Java ME?

Java ME/SE Language Level Compatibility

[Microdoc] ME and SE are converging. ME 8/MEEP did a huge step to be more SE like and the SE profiles made SE more like ME. Still I think, that what we get out of this is too static. 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.

[Some classes like String are different in Java ME and SE]

[V2COM]

Comparing Java ME to Java SE:

Continue to close the gap between the languages:

Stream support would be great

Reflection

Runtime Annotations

Concurrency Utilities

Collections and Math APIs

(these could be implemented as separate, optional JSRs?)

Comparing Java SE to ME (MEEP):

Basically everything that makes MEEP:

Software Provisioning

Software Management

Application Concurrency (MVM)

Inter-application Communication (IMC)

Events

Service Provider/Consumer Pattern

Native Code Support

[Microdoc mentioned about JNI:]

One of the more concrete things I am missing is a better operating system/C/C++ integration, like JNA [1]: Device I/O is a step in the right direction. https://github.com/java-native-access/jna#readme

IoT Specific or New APIs/JSRs

[V2COM:]

Support for Emerging Standards

REST Client

Communication Protocols such as MQTT and/or COAP

Expansion of the Device IO Capabilities

Expansion of the OTA for new Networks and Protocols (such as MQTT/COAP)

[Gemalto]

* Evolve Java ME eco system (->JSRs for device IO, security, ...) times

Updating Old JSRs

Gemalto/Thomas expanded on more technical items to evolve the Java ME ecosystem (->JSRs for device IO, security, ...).

JSR177

Update/rework of JSR 177: Address topics like access to TEE (Trusted Execution Environment), SE (Secure Element), services like secure storage, handling of credentials for TLS

JSR for MEEP

Continued support for multi-midlet environments

BUSINESS SPECIFICATIONS

Licensing

Current business model does not scale. Dated licensing model licensing. Need a frictionless technology onramp and then standardize.

Development Model

Similar development concept for Java ME as for Java SE (->OpenJDK + JSRs)

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 Packages

Access 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 Requirements

JSR Leadership

Does Oracle want to lead or allow others to lead? It is possible, and others have led JSRs in the JavaME space in the past. Most members are the call would be happy to participate in JSR activity, but not necessarily lead. Mike offered Eclipse as a potential source for communing members interested in leading JSRs.

Market Demand

[Is there a business demand for Java as IoT platform? Why have this as Java and not OSGi, or any other thing running on top of the Java SE JVM]

Competing Technologies

There is competition from embedded JavaScript, Android and Node.js - perceived as less expensive, hip, mainstream and accessible. [How are they using Node JS on IoT?]

[AndroidThings wants to be Java ME]

[Windows IoT]

[Ubuntu Snap framework]

There are some de facto developer and runtime environments at Android/iOS, so we do not need Java ME in this area.

OSGi as a framework to supplement Java SE with Java ME-like services (provisioning, configuration)

Next Steps

Refine to publish for discussion at EC meeting.

Next WG Meeting March 8 at 9:00 PST.