Java ME Working Group Meeting Minutes for February 15, 2017

Date

Wednesday, February 15, 2017, 9:00 am PST

Location

Teleconference

Agenda

Follow up on action items from last meeting. Review materials submitted by Working Group members.

Attendees

Heather VanCura
Leonardo Lima
Calinel Pasteanu
Hendrik Hoefer
Thomas Lampart
Mike DeNicola
Werner Keil

Minutes

Working Group members shared their technical and non-technical requirements for Java ME.

V2COM:

These are the features I miss in Java ME 8 or Java SE 8 that I wanted in an embedded Java platform:

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
(much of these are provided by OSGi, which we use for our Java SE capable gateways)

Missing in both platforms (but may be available from others, as pointed by Calinel):

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)
Continued support for multi-midlet environments

Non-technical:

For business reasons would like to see as JSRs

Gemalto:

Technical:

Keep Java ME up-to-date (→ JSR maintenance release, Java ME 9)
Evolve Java ME eco system (→ JSRs for device IO, security, ...) times

Non technical:

Similar development concept for Java ME as for Java SE (→ OpenJDK)

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.

I think that the situation could be improved if there was no difference in the language itself and in the class libraries. A class should have the same signature, no matter what runtime it runs on. Features, like class loaders, should be selected by the programmer based on the requirements and available resources. In an ideal world this would work like "make menuconfig" for the Linux Kernel and result in an optimal runtime for the specific application. To some extend this is how it works with C/C++; you link that lib or you don't. The Java 9 module system and to some extend JLink are very promising technologies that could support such an approach.

Startup time is one of the key factors for some embedded application and the jar file format might not be the best choice for this, given that unzip, defineClass() etc are very expensive operations. It is likely that this aspect does not require standardization, but will be left to the implementations - but we may want to think about this.

I also think that most of these requirements are not specific to embedded, but are important for servers as well, when it comes to MicroServices, elastic scaling and containers.

I apologize for being very generic. 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

Fujitsu:

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

Next Steps

Refine lists to publish for discussion at EC meeting.

Next WG Meeting February 22 at 9:00 PST.