08:45
Actually, I need to use FileChannel because I need random access to the class
files and such. However JavaME's FileChannel is rather light. I however can
just make a wrapper interface of sorts though. Or the alternative when reading
from a SeekableByteChannel would be to lock it, perform the read, then unlock
at a slight speed reduction. I cannot extend FileChannel because that would
end up with an incompatible class.
10:22
The DIO API does not support block devices. It does however have memory mapped IO, so perhaps I can use that to simulate block devices. For example say if one wants direct access to the bytes contains within the VMU of a Dreamcast, I can provide a block based interface for that.
10:25
Actually, it might just be useable under GenericBufferIODevice. That allows
reading and writing and also has optional buffer operations.
10:29
I should actually see if the buffer classes in this library are package private or not. The device IO API has its own buffer stuff which may be mapped by devices and such. However the standard API lacks memory mapped I/O support and the standard Java library has the Buffer classes package private. Also on a side note, my build system is not cleaning temp files.
10:35
Ok, so Buffer has no constructor. Also none of the others buffers that extend
off it have constructors. This is from the CLDC library however, which
basically just returns null and 0 everywhere however. Looking at other
code, it does not appear there are any specified constructors at all. Class
lacks one, but it is final. I must search elsewhere to determine how such
things would work. So I suppose the only way to be sure would be to just
install the ME environment onto a Raspberry Pi (the only available choice) and
see if my code can just extend it (if it cannot it would toss an Error about
an incompatible class). However, I need a 4GiB SD Card, which I do have to
install Raspbian onto. Since I lack a TCK and this is the only other device
I actually have (the other is some other developer board.
10:46
Well actually there should be an emulator, however I need a x86 system to use it and I just have PowerPC. So the only choice to use it would be to install it on my router/file server.
11:54
Well lets see, the buffer classes magically have no constructors, so I cannot even compile them with the SDK, I have to use one of the wrappers. So I do wonder how the device IO APIs work when they use ByteBuffers.
11:58
So this means for that, I will need magically classes and such to provide
ByteBuffers which are mapped to specific memory addresses. Will be fun.
13:09
Ok so here are the numbers:
- CLDC 1.8: 111 classes
- MEEP 8 : 62 classes
- GCF : 41 classes
This means for an absolute minimum required stuff I need to write a maximum of 214 class. More stuff is optional in this, but having all of it would be the most useful. However, I will probably force CLDC 1.8 to be maximum while MEEP and GCF can be split off into sub-packages. This way not everything is needed. There are also the device IO APIs which can be split also.
- DIO 1.1 : 125 classes
13:37
I should probably split the CLDC and keep it modular so that I can actually have optional bits to it. That is I have the very core of it and then I have stuff added on top of it.
As stated in the documentation:
- CLDC Full APIs:
- Java runtime classes (java.lang)
- annotations (java.lang.annotation)
- weak references (java.lang.ref)
- collections, service loader, and utility classes (java.util)
- Security (java.security)
- I/O Streams and Readers (java.io)
- Network exceptions (java.net)
- NIO Buffers (java.nio)
- NIO Channels (java.nio.channels)
- NIO Files (java.nio.file and java.nio.file.attribute)
- and Logging (java.util.logging)
- CLDC Compact APIs:
- Java runtime classes (java.lang)
- annotations (java.lang.annotation)
- weak references (java.lang.ref)
- collections, service loader, and utility classes (java.util)
- Security (java.security)
- I/O Streams and Readers (java.io)
- and Network exceptions (java.net)
So I basically need to split off all of the NIO stuff and logging, then I have a truly compact API.
13:43
That is 88 classes. Also the original count for CLDC is incorrect because the JAR is missing logging.
13:45
Ok, so the true base library fully contains 216 classes. Removing the stuff to make it compact turns it into 158 classes.
13:51
However, the very small number of Java ME classes will definitely be better on my sanity and time compared to implementing the entire Java library from scratch. Plus this ME environment will be more interesting for me since I could try and cram it into small devices where the only use it could have is for fun.
14:04
Ok so now the entire library is split, which was quite simple to perform. Although right now I do not see how it will end up working for smaller platforms. Possibly when it comes to native compilation I will have a stripped minimal set for binary creation. That is, compile a single application for a specific target if it for example has no real purpose executing in a full virtual machine state. Essentially, this could allow binaries to be compiled for very limited platforms such as a Z8F6421 or a Dreamcast VMU. In both of these cases, I could not see a filesystem with an actual interpreter being used. So essentially such systems would be AOT only and are fixed to which classes they support.
14:38
So the first part of the interpreter which must be written is the class loader.
17:01
I would say that for cooperatively tasked systems, running threads will have to
call Thread.yield(), call Thread.sleep(), block on a lock, or block on IO
if they want another thread to start running.
22:54
According to the running of the run-time, primitive types are considered to be in the default nameless package. Arrays are in the package of their component type.