This page provides details of current issues/limitations with the leJOS Virtual Machine. It does not list issues with the class libraries or with hardware support.
The leJOS VM uses a thread id that is a single byte. One value (0x0) is reserved for use as a "no owner" id. This means that there is a maximum of 255 active threads. The problem is that currently there is no way to track which ids are in use. This means that once 255 threads have been created within a program run then ids will begin to be re-used and duplicates may occur. This is a bad thing!
Object finalization is not currently supported.
There is currently no support for weak references to objects.
The JLS specifies that string constants should be interned so that the following:
String s1 = "A String"; String s2 = "A String"; assert s1 == s2;
Should not throw an assertion error. In leJOS this is not the case. In leJOS each use of a string literal will create a new String Object. One possible fix for this would be to modify the way that string literals are stored in flash to make them Java Objects (in the same way that class objects are). This would allow us to simply use a reference to the constant. However because the Object would be read only it would not be possible to synchronize on the Object (unless we added extra RAM based synchronization structures (objSync) as we have done for class objects.
The following are some of the known limits of the leJOS VM
MAX_CLASSES = 256; MAX_FIELDS = 255; MAX_METHODS = 255; MAX_PARAMETER_WORDS = 16; MAX_SIGNATURES = 4096; MAX_OPERANDS = 255; MAX_LOCALS = 255; MAX_EXCEPTION_HANDLERS = 255; MAX_CODE = 0xFFFF; MAX_CONSTANTS = 1024; MAX_STATICS = 1024; MAX_FIELD_OFFSET = 4095; MAX_STRING_CONSTANT_LENGTH = 255; MAX_DIMS = 7;
The leJOS VM does not implement any memory defragmenation. So it may happen, that memory allocation for large arrays or large object fails, even though the overall free memory seems to be enough.