確かに、Java SE HashMap には「高価な」ハッシュ関数があり、その可変サイズは潜在的にメモリ不足エラーを引き起こす可能性がありますが、定数サイズに関連する単純なハッシュを持つ定数サイズ Map はどうでしょうか?
1 に答える
スマートカードの RAM/EEPROM リソースは非常に限られています (または、Javacard 2.x バージョン範囲の存続期間中は非常に制限されていましたが、現在は改善されていて、RAM が数 KB で、OS の場合は数百 KB でした)、javacardライブラリと顧客のアプリケーションとデータ)。Javacard 2.1 は 1999 年にありました...
そのため、Javacard API はスマートカードの主な機能 (通信、トランザクション、暗号化、アプリ管理など) へのアクセスを提供することに重点を置いており、コード、データの静的または実行時のメモリ消費を最小限に抑えるために、マップなどのこの高レベルの概念はすべて除外されました。
また、スマートカード OS と javacard 標準ライブラリのバグを簡単に修正することはできません (それらのほとんどは 200X の初期には ROM にありました)。ガジェット API が増えると、問題のリスクが高まり、展開とテストのコストが増加します。
ところで、Javacard 222 VM 仕様のセクション 21 に記載されています。
""" サブセットが必要な理由
スマート カード用のプログラムをすべての Java プログラミング言語を使用して作成できれば理想的ですが、Java 仮想マシンの完全な実装は大きすぎて、現在入手可能な最も高度なリソースに制約のあるデバイスにさえ収まりません。
リソースに制約のある一般的なデバイスには、1.2K の RAM、16K の不揮発性メモリ (EEPROM またはフラッシュ)、および 32K ~ 48K の ROM があります。文字列操作、単精度および倍精度の浮動小数点演算、スレッド管理を実装するためのコードは、そのようなデバイスの ROM スペースよりも大きくなります。収まるように作成できたとしても、クラス ライブラリやアプリケーション コードを格納するスペースはありません。RAM リソースも非常に限られています。唯一の実行可能なオプションは、Java Card テクノロジを Java プラットフォームのサブセットとして実装することです。"""