Artifact ee6025e722ae554741a4c9f4e995b7e26759a0c1:
- File compatibility.mkd — part of check-in [6ab585cc0e] at 2018-12-22 17:55:35 on branch trunk — Compatibility document updates. (user: stephanie.gawroriski size: 2155)
# Compatibility SquirrelJME aims to be compatible with most programs however there are situations and rare edge cases where there will be no compatibility. This is to make the implementation easier. ## `Flushable` Interface The interface `Flushable` does not exist in Java ME and as such it does not exist in SquirrelJME. ## LCDUI Display Input Only the first display (index zero) supports input events such as keyboard, buttons, mice, and touchscreen. Any secondary displays which are attached will not have events handled for them at all. This is to make it easier to implement. ## `Reader`'s `lock` is initialized to `null` instead of `this` Since SquirrelJME uses a reference counted garbage collector the `Reader`'s `lock` object in the default constructor is set to `null` instead of `this`. This is so that readers do not remain in memory unable to be freed because objects still refer to them and such. ## `SUPER` is always assumed to be set. In all clases the `SUPER` flag is assumed to be set, this flag just modifies the behavior of `invokespecial`. When it is not set then that instruction can invoke nearly every method directly (it was called before `invokenonvirtual`). However, the Java compiler since Java 1.1 always set the flag for classes it compiled. Since CLDC 1.0 was released well after Java 2 was and is defined as a Java 2 virtual machine all code written for J2ME should have classes where this flag is set. As such instead of supporting the logic to handle cases where it is not set, the flag will just be ignored and assumed to be set. ## Supported Encodings Only the following character encodings are supported: * _ASCII_ * _IBM037_ * _ISO-8859-1_ * _UTF-8_ Note that UTF codepoints above U+FFFF are not fully supported and are not available in Java ME. Surrogate pairs in UTF-16 will be encoded in UTF-8 as six bytes. Additionally when decoding, if a sequence that is above U+FFFF is read then it will decode to the replacement character. This may cause a loss of or mutation of data when processing files. See: * <https://unicode.org/faq/utf_bom.html#utf8-4> * <https://www.unicode.org/reports/tr26/>