Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this questionSure the Java SE HashMap has an "expensive" hashing function and its variable size could potentially cause out of memory errors but what about a constant size Map with a simple hashing relative to its constant size?
RAM/EEPROM resources are very limited on a smartcard (or were very limited during the lifetime of Javacard 2.x version range even if now things are better, were few KB of RAM and tens...couples of hundreds KB for OS, javacard libs and customer application and data). Javacard 2.1 was there in 1999...
So the Javacard APIs are focused on giving access to smartcard's main features: communication, transactions, crypto, app management etc. and all this higher level concepts like maps were left out for minimizing memory consumption for code, for data static or runtime.
Also you cannot fix easily bugs on smartcard OS and javacard standard libs (most of them were in ROM in early 200Xs). More gadget APIs = increase risk of issues and cost of deployment & test.
BTW found in Javacard 222 VM spec, section 21:
""" Why a Subset is Needed
It would be ideal if programs for smart cards could be written using all of the Java programming language, but a full implementation of the Java virtual machine is far too large to fit on even the most advanced resource-constrained devices available today.
A typical resource-constrained device has on the order of 1.2K of RAM, 16K of nonvolatile memory (EEPROM or flash) and 32K-48K of ROM. The code for implementing string manipulation, single and double-precision floating point arithmetic, and thread management would be larger than the ROM space on such a device. Even if it could be made to fit, there would be no space left over for class libraries or application code. RAM resources are also very limited. The only workable option is to implement Java Card technology as a subset of the Java platform."""
精彩评论