Internet of Thingsに向けたJava MEの現状と未来

はじめに

昨日掲載した「Internet of Things(IoT)市場を攻略しようとするARMの構想について思うこと」の続きです。

Internet of Things(IoT)に力を入れているのはARMとIntelだけではありません。その上で動作するソフトウェアのベンダーも力を入れています。ここではOracleがどのようなJavaを投入してIoTデバイスへの採用を狙っているのかを、IoTデバイスに搭載されるJava MEの現在と将来から見てみたいと思います。

ARMアーキテクチャとJavaの関係

Oracleが提示する、ARMアーキテクチャ上でサポートされている、組み込みJavaの状況を以下に示します:

Java Embedded Supported Platforms
Supported ARM Platforms and Corresponding Java Releases

Processor Operating System FPU Java Version
ARMv7-M(Cortex-M3/STM32F207) RTX Java ME 3.3
ARMv5(ARM926/QSC6270T) BrewMP Soft Float Java ME 3.4
ARMv6(ARM11/BCM2835) Linux VPU Hard Float Java ME 3.3
ARMv5 Linux Soft Float Java SE Embedded 7u45
ARMv6/v7 Linux VFP Soft Float Java SE Embedded 7u45
ARMv6/v7 Linux VFP Hard Float Java SE Embedded 7u45
ARMv8 Linux TBD Java SE Embedded H1 2015

出典:Oracleの資料を引用した後藤さんの連載記事からの孫引き

このように、現在リリース済みの6種の中では、半分がJava ME、半分がJava SE Embeddedときれいに半分ずつになっています。Java SEは通常版のJavaであり、特に説明は必要ないと思いますので、残るJava MEについて説明を続けたいと思います。

現在のJava ME

先ほどの表にはJava ME 3.3と同3.4が掲載されていますが、動作対象のプラットフォームが異なるだけですので、アプリケーションソフトウェアの開発者にとって両者は同一とみなして問題ありません。本稿でも個別のプラットフォームに言及することはありませんので、同一視します。

Java ME Embedded 3.3/3.4

このJava ME Embedded 3.3/3.4は、Oracleが提供するJava MEの組み込み用の実装です。

NTTドコモのiアプリやJCP標準のMIDP(MIDlet)などでおなじみのCLDC 1.1(JSR 139)によるプラットフォーム(コンフィグレーション)に、従来の総合的なプロファイルであるMIDP 2.0(JSR 118)ではなく、個別のサービスに特化した各種APIを載せたものです。構成は以下のようになっています:

参照実装API

この2つのAPIセットは必須となるものです。

  • JSR 139: Connected Limited Device Configuration 1.1

    Java MEとしてのプラットフォームを担います。Java仮想マシンとして専用のKVM(Kilo-byte Virtual Machine)を採用しています。仕様はJava 2 Platform, Standard Edition 1.3から派生しており、同SDKの言語仕様に準じますが、搭載されるAPIは実行環境に合わせて「Javaとして必要最低限(java.langjava.iojava.utilパッケージの一部と、KVM専用に追加されたGeneric Connection Framework用のjavax.microedition.ioパッケージのみ)」のものに限定されており、ネットワークやGUIなどはすべて存在しません。これらの除去された部分は、その実行環境で必要となるものに合わせて、個別に「プロファイル」と呼ばれるパッケージを組み合わせることで使用できるようにします。

  • JSR 228: Information Module Profile – Next Generation (IMP-NG)

    MIDP(JSR 118)から「情報機器」として必須な部分のみを抽出した小型のプロファイルです。グラフィックスやGUIに関する部分は省略されていますが、他のAPIに関してはそのまま残されています(背景には、MIDPのGUIやグラフィックスのモデルが携帯電話に特化しすぎていて使いづらいという意向があったようです)。なお、このプロファイルはMIDP由来のグラフィックスやGUIを加えることを妨げるものではありません。

オプションのAPIパッケージ

前述の必須となるAPIセットにオプション(任意)で加えて使用できるAPIパッケージです。

  • JSR 75: PDA Optional Packages for the J2ME™ Platform

    ファイルシステムを使用して、ファイルの作成、削除、読み取り、書き込み、リネームを行うためのパッケージです。ディレクトリーをサポートしており、WindowsやLinuxのような階層構造を使用することができます。また、書き込み可否や隠しファイルなどの属性を扱うことができます。

  • JSR 120: Wireless Messaging API

    いわゆるSMS(CBS(Cell Broadcast Service)を含む)を扱うAPIです。Generic Connection Frameworkを用いたメッセージの送信および受信に関するAPIを定義しており、メッセージ(テキストメッセージとバイナリーメッセージ)を扱うことができます。

  • JSR 172: J2ME™ Web Services Specification

    SOAP/XMLベースのWebサービスを使用するための規格です。XMLを扱うためにJAXP(Java APIs for XML Processing) APIのサブセットを含んでいます。

  • JSR 177: Security and Trust Services API for J2ME™

    Java MEのためのセキュリティとトラストサービスに関するAPIです。Java CardやSIM/USIMなどの物理的な認証関連や公開カギ暗号関係のAPIセット、ネットワーク上の認証関連およびそのために必要なAPIセットなどを含んでいます。

  • JSR 179: Location API for J2ME™

    住所、緯度・経度・高度、ランドマーク(例えば国会議事堂や東京タワーなどの著名な目印となるポイント)、方位などの情報を扱う位置情報に関するAPIです。浮動小数点数を使用するためCLDC 1.0では使用できません。

  • JSR 280: XML API for Java™ ME

    Java MEのためのXML APIです。SAX(Simple API for XML)、JAXP(Java API for XML Processing)、StAX(Streaming API for XML)、DOM(Document Object Model)のサブセット仕様を含みます。

Oracle Java ME Embedded実装固有API

ここに分類されるAPIは、Oracleの提供するJava ME Embedded実装に固有のAPIであり、Javaとして規格化されたものではありません。

  • Device Access API – Version B

    一般的なマイコンボードに搭載されている入出力デバイスや各種機能に対応するAPIセットを提供します:

    • GPIO(General Purpose Input/Output)
    • I²C(Inter-Integrated Circuit Bus)
    • SPI(Serial Peripheral Interface Bus)
    • ADC(Analog to Digital Converter)
    • DAC(Digital to Analog Converter)
    • UART(Universal Asynchronous Receiver/Transmitter)
    • MMIO(Memory-Mapped Input/Output)
    • ATコマンドデバイス(モデムなど)
    • ウォッチドッグタイマー
    • パルスカウンター
    • 一般的なデバイス用
    • パワーマネージメント

     
    このほかに将来の拡張としていくつかの追加の要素が提供されることがあります。

  • Logging API

    書式化およびレベル、フィルターを指定してのログ出力制御を行うAPIです。

  • AMS API

    AMS(Application Management Software※1)による制御のJava ME側の受け口を担当するAPIです。

  • AccessPoint (Oracle Mobile Developer) API

    Bluetooth、CSD(Circuit Switched Data)、Ethernet、モバイル接続(GPRS、W-CDMAなど)、Wi-Fi、WiMaxによる接続における、プライベートネットワーク、パブリックネットワーク、オペレーター(キャリア)定義のサービスをサポートするAPIです。

未来のJava ME

従来のJava MEは、Java 2 Platform, Standard Editonの1.3(CLDC 1.1の場合)あるいは1.4(CDC 1.0の場合)をベースとしており、現在の最新版であるJava 7や次世代のJava 8までに拡張された文法(ジェネリクスやアノテーションなど)を受け入れることができません。これを言語仕様レベルでの整合性を持たせ、Java SEとJava MEの間の乖離を縮小する方向で策定されている規格が、この新たなJava MEです:

Java ME Embedded 8 Early Access Release

この製品は現在はまだ正式版ではありません。

基本的にはJava ME Embedded 3.3/3.4を最新のJava仕様に合わせるために拡張したものであり、従来コードを新たなプラットフォームで動作させることができる、後方互換を意識したものとなっています。ただし、柔軟性を優先したようであり、必ずしも完全な後方互換とはなっていないことに注意が必要です。

参照実装API

  • JSR 360: Connected Limited Device Configuration 8(CLDC 8)

    この規格は現在はまだプレビュー状態であり、正式なものではありません。

    従来のCLDCを最新の言語仕様に合うように拡張したものです。含まれるAPIセットはJava 8として最低限必要となるもののみを含み(従来はオプションであったログ出力機能もJava SEから縮小化したものを含む)、それ以外はプロファイルとして構成されたものを使用します。Java仮想マシンは従来と同様にKVMをベースとするものを使用します。また、プリベリファイ(予備検証/事前検証)を必要とするプロセスに変更はありません。

  • JSR 361: Java™ ME Embedded Profile(MEEP 8)

    この規格は現在はまだプレビュー状態であり、正式なものではありません。

    IMP-NGに代わって、Java MEアプリケーションとして必要となる要素を持つプロファイルです。APIセットのほとんどがオプショナルであり、必要に応じて構成を変更するようになっています。従来のJava MEが特定の機器、例えば携帯電話を見据えて互換性を維持してアプリケーションを構築できるようにするものでしたが、このプロファイルはJava MEの枠組みの基本を提示するものの、互換性のあるアプリケーションを構築できるようにすることをバイナリーレベルでは意識しないものとなっています。

オプションのAPIパッケージ

この部分のAPIパッケージはJava ME Embedded 3.3/3.4と同一です。

Oracle Java ME Embedded実装固有API

ここに分類されるAPIは、Oracleの提供するJava ME Embedded実装に固有のAPIであり、Javaとして規格化されたものではありません。ログ出力関係についてはCLDC 8自体に取り込まれたため、この分類のAPIからは取り除かれました。

  • Generic Connection Framework API

    CLDC 8に含まれる、GCF8(Generic Connection Framework, Version 8)に対応する実装を提供します。

  • Device Access API – Version 8

    従来のDevice Access APIと比較して、以下の変更点があります:

    • Java ME 8の言語仕様に合わせたAPIの変更を含む
    • PWM(Pulse Width Modulation)ジェネレーターに対応する機能追加

まとめ

このように、IoT向けのJava MEは、携帯電話向けのJave MEとは異なり、同じアプリケーションが多くの機器で同様に使用できるというものではなくなっています。必要に応じて特化したプログラムをC言語やC++言語ではなく、Java言語で記述することができるという点を目的にしているといってよいようです。

一方で、従来のOTA(Over The Air : 無線越しでのダウンロード、認証、インストール)を完全に否定しているわけでもありません(必須でもありません)。Java MEを機器に取り込む実装者に多くの権限をゆだねているのが特徴です。

これは、JSR 118(Mobile Information Device Profile 2.0)での思想※2とは異なるものであり、この思想に慣れている従来のJava ME開発者には、多少の違和感がある点かもしれません。

IoTが現実のものとなり、ある程度の共通項が見つかれば、それ用のプロファイルが定義されるのかもしれませんが、現状ではそうなっていない、というのが正しい現状認識なのかもしれません。

関連記事


  • 「Application Management System」の略であるという誤りが散見されますが、正しいのは「Application Management Software」です。このことは「Mobile Information Device Profile 2.0(JSR 118)」の記述内容で確認することができます。
  • 原則として、すべてのMIDP 2.0向けアプリケーションがすべてのMIDP 2.0実装機器で動作することを前提とする思想。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です