J2MEに対応したIoCコンテナーのハントが開始されました！

Question

私はBlackberry / J2MEプロジェクトの初期段階にいます-この素晴らしいプラットフォームに付随する他の制限とともに、リフレクションと1.3言語レベルのサポートの欠如は、既存のIoCコンテナーの大部分が使用できません。 （GoogleにはAOPのないGuice for Androidがありますが、それでも注釈のサポートが必要です。）

したがって、J2ME上のIoCコンテナーのスペースはかなり限られています。私の注意を引いたフレームワークは Signal Framework と呼ばれ、かなり有望です。 Spring FrameworkのIoCに概念的に近づき、その機能の小さなサブセットを実装しようとし、バイトコード変更に依存したり、ランタイムxml解析を引き起こしたりすることなく実装します。代わりに、ビルド時に構成XMLを処理して、このIoC機能を実装するJavaコードを生成します。

一般的に、ビルド時のコード生成は、モバイルアプリケーションにとって非常に賢明なアプローチのように思えます。また、ユーザーのデバイスでアプリがより少ないXML解析を行う必要がある場合、それも素晴らしいことです！

では、J2ME / CLDCでIoCを実装した経験はどのようなものでしたか？また、口の中の苦味をどのように消すことができましたか？

Answer 1

Signal Framework です。

更新：残念ながら、Signalは現在非常に不十分です。そのため、を使用します。 Israfil IOC にカスタム追加。

Answer 2

TomTomで Spring ME を使用しました。かなりうまくいきました。

Answer 3

J2MEでは、jarファイルのサイズを減らすために、使用するクラスの数をできるだけ減らす必要があります。これにより、多くの設計上の妥協がもたらされますが、その中でも特に柔軟性が重要です。

OOについて学んだこと（そして高く評価すること）を窓から追い出さなければならないとき、J2ME開発に適応するのは簡単ではありません。真実は、広範囲の電話で実行できるアプリが必要な場合、デバイスの制約に非常に敏感である必要があるということです。

このように、IoCフレームワークはJ2ME開発に対する多くの人々のニーズに合うとは思いません。

Answer 4

FallME のチェックアウトに興味があるかもしれません。個人的に使用したことはありませんが、J2MEプラットフォーム専用に構築されたナンセンスなフレームワークではないようです。

Answer 5

オランダのJUG会議で Spring ME に出会いました（まったく経験がありません）。