• 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 February 22, 2017

Date

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

Location

Teleconference

Agenda

Discuss non-technical materials submitted by Working Group members.

Attendees

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

Minutes

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

We discussed the non-technical factors contributing to low adoption of Java ME 8 and the requirements for further evolution of Java ME.

Non-technical:

• For business reasons would like to see as JSRs - standards are important to ensure safety.
• Development as a JSR protects implementors from litigation.
• 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.
• Similar development concept for Java ME as for Java SE (→OpenJDK)
• Current business model does not scale. Dated licensing model licensing. Need a frictionless technology onramp and then standardize.
• There is competition from embedded JavaScript, Android and Node.js - perceived as less expensive, hip, mainstream and accessible.
• Fujitsu: There are some de facto developer and runtime environments at Android/iOS, so we do not need Java ME in this area.
• Gemalto/Thomas expanded on more technical items to evolve the Java ME ecosystem (→JSRs for device IO, security, ...). 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 Other potential JSRs: IoT protocols: LWM2M, CoAP, MQTT, ...

We discussed the question: 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 to check with Eclipse IoT Working Group for interest in Java ME JSRs.

Next Steps

Refine lists to publish for discussion at EC meeting.

Next WG Meeting March 1 at 9:00 PST.