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.

Limited Network Interface Support

The Generic Connection Framework (GCF) has API to provide access to various system interfaces, WiFi devices, 3GPP/CDMA (Mobile data), and dial-up connections. Since supporting all of these are complicated, support for these across systems will be limited to an as needed basis.

Reader's lock Is null

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 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/

ScritchUI Graphics Serialization

All graphics operations in ScritchUI are serialized and any draw operations are hard forced to occur in the graphics drawing thread. Unlike traditional APIs for operating systems where this is intended to be done by the developer, SquirrelJME forces this paradigm to be used. This generally fixes and stabilizes software that performs locking and/or game logic in Canvas.paint() methods, or similar.

This allows software such as Gradius NEO on DoJa to run, and for the framerate of Ratchet and Clank on MIDP to be stable and not run absurdly fast.

Configuration/Platform Version Differences

SquirrelJME will auto-detect the version of the configuration and platform from the manifest or a set of other indicators. This is used to determine the version of said specific standard or device that software is made for. Without this, the subtle changes that occur due to breaking API updates will cause software to change behavior.

MEEP/MIDP Version Differences

• >= 3.0: The Canvas by default is wiped with a background color by default unless setPaintMode() changes this, previously no implicit clearing was performed and all pixels must be drawn. Otherwise, an effect called the "hall-of-mirrors" would occur, a type of smearing.
• < 3.0: The alpha channel is not supported, therefor the method Graphics.setAlphaColor() will always set the color to be fully opaque. Accordingly, Graphics.getAlpha() and related will always have the alpha channel always set to be fully-opaque.
• < 8.0: RecordStore does not support IDs that are recycled and as such all new records will always have a higher value ID regardless. MEEP 8 however, recycles old IDs as records no longer need to be accessed purely by IDs, as there are named aliases and tags.

DoJa Version Differences

• >= 5.0: Adds support for looped MLDs and emits AUDIO_LOOPED, otherwise they will not be emitted at all. The END_EVENT is considered to be the looping point. Otherwise, if there is no end event and the media reaches the end, or DoJa is not new enough, AUDIO_COMPLETE will be emitted. If EVENT_LOOP is hit, the MLD will jump to position zero.
• < 2.0: AudioPresenter priority does not exist, thus all new sounds will always replace the already playing sound.
• < 3.0: AudioPresenter does not support setting the volume level, thus all volume will be at 100%.
• >= 3.0: AudioPresenter.setSound() requires that any set sounds be use()ed first, otherwise it will fail.
• < 3.0: AudioPresenter only supports a single sound at once, therefor SquirrelJME's dynamic port cycling will not take effect and always choose the first port.
• < 3.5: AudioPresenter supports multiple ports, however when requesting the default port it will always a non-specific default port to mimic the behavior of < 3.0.
• < 4.0: The alpha channel and alpha blending does not exist and all values will be stripped and forced to be fully opaque regardless of their input values or drawing mode.
• < 4.0: Due to the lack of alpha channel and alpha blending, the values returned by Graphics.getColorOfName() and Graphics.getColorOfRGB() will always return with the uppermost bits set to zero. This must be considered as fully-opaque as normally a value of zero means fully-transparent. Otherwise, the values returned will have their uppermost bits set to one.
• >= 2.0: Disposing of graphics is supported, which frees associated resources accordingly.
• < 3.0: Application suspension is not supported, thus the in-the-background multitasking that is provided by MIDP 3 will always result it in being reported as not supported. However, SquirrelJME will still be able to background tasks, despite the application being unable to receive those events nor determine if it is running in the background. This may cause performance issues if an application continues executing when it should not be doing more work than usual while the user is not using it.

Configuration Settings That May Be Used For Compatibility

These settings may be used for compatibility purposes if needed:

• cc.squirreljme.frame=WxH -- Set the default resolution of SquirrelJME.

  • This should be used if SquirrelJME is unable to determine the actual resolution that an application should use and there otherwise are graphical glitches or other anomalies due to this.

• cc.squirreljme.keymap=vendor -- Use a vendor's keys in SquirrelJME.

  • This should be used if an application requires a specific vendor's keycodes in order to function properly. This is often the case with applications developed for Nokia, Siemens, among others.

Compatibility Check IDs

Compatibility flags which violate Java ME standards and are very specific to single sets of devices and/or applications. These options should rarely, if ever, be used and are always disabled by default. Any use of these flags indicates a defect in the application you are using, it is recommended to contact the vendor of that application and request a fix.

New IDs are always incremental and not a bit-field, due to the large number of potential devices, applications, and flags.

• 1 (KONAMI_DEMO_CHECK) -- Some Konami demos perform some checks to ensure that they are running only on specific Konami demo devices. If enabled, this enables support for those checks.
• 2 (FORCE_LCDUI_BUFFER) -- Some titles violate the LCDUI specification by illegally storing the Graphics context when they should not, this forces a buffer to be used.

SecurityManager

Since Java SE 17, SecurityManager has been deprecated and since Java SE 24 it has been permanently disabled. Considering that this is software userspace defined security that only works with well-behaved applications, SquirrelJME will only contain a minimal legacy interface on an as needed basis so that legacy applications still run. If you rely on a secure infrastructure, it is recommended to investigate a more secure environment setup such as signing software, encrypting memory, and writing secure code.