13

J2SE、J2ME、Android などのさまざまな Java プラットフォームで実行されるアプリケーションをコーディングしようとしています。プラットフォームごとにほとんどの UI を書き直す必要があることは既にわかっていますが、コア ロジックを再利用したいと考えています。

このコアの移植性を維持するには、私が知っている 3 つの欠点があります。

  1. 古いJava 1.4 構文を維持し、Java 5.0 の優れた言語機能を使用しない
  2. これらのプラットフォームで動作することがわかっている外部ライブラリのみを使用する (つまり、JNI を使用せず、この規則に違反する他のライブラリに依存しない)
  3. これらすべてのプラットフォームに存在するクラスのみを使用する

（1）を克服する方法を知っています：5.0スタイルのコードを自動的に1.4に変換します（レトロウィーバー-まだ試していませんが、問題ないようです）。

(2)は受け入れるしかない問題だと思います。

今、私は(3)、特に私が最も見逃しているコレクションクラスの最善の回避策を知りたいです。私はそれらを考えることができます：

  • 私が知っているほとんどのプログラマーは、、、などを使用せず、Setプレーンな配列にフォールバックします。これはそもそもコードを醜くすると思います。しかし、私はまた、orの間の正しい選択がパフォーマンスにとって非常に重要であり、常にand 配列を使用することは正しくないことも知っています。MapListVectorTreeSet/HashsetLinkedList/ArrayListVector
  • そのクラスの独自の実装をコーディングできました。これは車輪の再発明のようであり、他の人が行ったほどうまくできなかったと思います.
  • Java はオープン ソースであるため、J2SE Collections フレームワークのソースコードを入手して、J2ME 用にビルドするときにアプリケーションに組み込むことができました。しかし、これが良いアイデアかどうかはわかりません。おそらく、これを行わない正当な理由があります。
  • おそらく、コレクション フレームワークの最も重要な機能を再構築するライブラリが既に存在する可能性がありますが、使用頻度の低い機能を実装しないことにより、ロー エンド システム向けに最適化されています。何でも知ってますか？

あなたの答えと意見をありがとう！

編集：私はついに（複雑だが素晴らしい）解決策を見つけました。私は自分の答えを提供してそれを受け入れることで、解決策が一番上に見えるようになると思いました。しかし逆に言えば、私の答えはまだどん底にある。

4

4 に答える 4

13

J2MEは残忍であり、他のプラットフォームの優れた点をいくつか使わずに、辞任する必要があります。HashtableとVectorに慣れ、それらの上に独自のラッパーを作成します。また、各メーカーのJVMは大きく異なる方法で処理を実行できるため、J2MEが標準であると誤解しないでください。J2MEで正確さを取得するだけで十分な課題があるため、最初はパフォーマンスについてあまり心配しません。私がやったように、J2ME、J2SE、Androidで動作するアプリを作成することは可能ですが、多くの作業が必要です。私が持っている1つの提案は、アプリケーションロジックのコアを記述し、それをjava.lang、java.util、およびjava.ioに厳密に保持することです。プラットフォームと相互作用する可能性のある何かを行う予定の場所ならどこでも、ファイルシステムやネットワークなど、コアアプリケーションコードが相互作用するインターフェイスを作成し、環境ごとに異なる実装を行うことができます。たとえば、HTTPのものをラップし、AndroidでJ2MEおよびjava.net.HttpURLConnectionでjavax.microedition.io.HttpConnectionを使用するインターフェースを持つことができます。面倒ですが、これら3つの環境すべてでアプリを実行し続けたい場合は、そこにたどり着くことができます。幸運を。ただし、これら3つの環境すべてでアプリを実行し続けたい場合は、そこに到達できます。幸運を。ただし、これら3つの環境すべてでアプリを実行し続けたい場合は、そこに到達できます。幸運を。

于 2009-05-15T16:34:23.040 に答える
12

私がこの質問をしてからしばらく経ち、問題のうまく機能する解決策を見つけてからしばらく経ちましたが、それ以来、あなたに話すのを忘れていました。

私の主な焦点は、java.utilパッケージの一部であるJavaコレクションフレームワークでした。

私はついにSunsJava6.0のソースコードを取得し、Collectionsフレームワークに属するすべてのクラスを自分のプロジェクトにコピーしました。これはJava6.0プロジェクトでしたが、クラスパスとしてJ2MEのjarファイルを使用しました。私がコピーしたクラスのほとんどは他のJ2SEクラスに依存しているため、依存関係が壊れています。とにかく、シリアル化（私にとっては優先事項ではありません）といくつかの小さな調整を扱うすべてのものを除外することで、これらの依存関係を減らすのは非常に簡単でした。

すべてをJava6コンパイラでコンパイルし、retrotranslatorを使用して結果のバイトコードをJava1.2に移植しました。

次の問題はパッケージ名です。J2MEアプリケーションでクラスを配信してロードすることはできないためですjava.util。ブートストラップクラスローダーはアプリケーションのjarファイルを調べず、他のブートローダーはそのパッケージで何かをロードすることを許可されていません。名前、およびJ2MEでは、カスタムクラスローダーを定義できません。Retrotranslatorは、バイトコードを変換するだけでなく、既存のバイトコードの名前参照を変更するのにも役立ちます。プロジェクト内のすべてのクラスを移動して名前を変更する必要がありました。たとえば、にjava.util.TreeMapなりましmy.company.backport.java.util.TreeMap_た。

私は実際のJ2MEアプリケーションを通常を参照する2番目のJava6.0プロジェクトで記述java.util.TreeMapし、一般的な構文を使用してタイプセーフなコレクションを作成し、そのアプリをJava 6.0バイトコードにコンパイルし、retrotranslatorを介して実行してJava1.2コードを作成することができました。これで参照されmy.company.backport.java.util.TreeMap_ます。これTreeMapは単なる例であり、実際にはコレクションフレームワーク全体で機能し、そのフレームワークを参照するサードパーティのJ2SEJarでも機能することに注意してください。

作成されたアプリは、jarファイルとjadファイルとしてパッケージ化でき、J2MEエミュレーターと実際のデバイス（Sony Ericsson W880iでテスト済み）の両方で正常に実行されます。

プロセス全体はかなり複雑に見えますが、ビルドの自動化にAntを使用し、とにかく再トランスレーターが必要だったため、コレクションフレームワークのバックポートをセットアップするためのオーバーヘッドは1回だけでした。

上で述べたように、私はこれをほぼ1年前に行い、これを主に頭のてっぺんから書いているので、エラーがないことを願っています。詳細に興味があれば、コメントを残してください。そのプロセスに関するドイツ語のドキュメントが数ページありますが、必要に応じて提供できます。

于 2010-07-04T18:47:37.107 に答える
3

We faced exactly this situation in developing zxing. If J2ME is in your list of targets, this is your limiting factor by far. We targeted MIDP 2.0 / CLDC 1.1. If you have a similar requirement, you need to stick to Java 1.2. Java 1.4 language features are definitely not present (like assert) and in general you won't find anything after 1.2 in J2ME.

We did not use external libraries, but, you could package them into your deployed .jar file with little trouble. It would make the resulting .jar bigger, and that could be an issue. (Then you can try optimizers/shrinkers like ProGuard to mitigate that.)

I did end up reimplementing something like Collections.sort() and Comparator since we needed them and they are not in J2ME. So yeah you might consider doing this in cases, though only where necessary.

We used Vector and Hashtable and arrays since there is no other choice, really, in J2ME. I would just use them unless you have a reason not to, and that would be performance I guess. In theory JVM makers are already optimizing their implementation but that doesn't mean you couldn't make a better one... I guess I would be surprised if it is worth it in the vast majority of cases. Just make sure you really need to do this before putting in the effort.

于 2009-05-15T01:02:05.793 に答える
2

あなたの質問の一部に答えるために、別のコレクションライブラリはj2me用に構築できるJavolutionです。

于 2009-05-14T11:23:24.873 に答える