SquirrelJME/SquirrelJME

# 2016/03/01

## 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.