12:11
One thing I will need to consider is garbage collection. I want a good and simple garbage collector, but one which does not add complication and is not slow. I also want to potentially avoid having safe zones for threads to park when GC is happening. I want to avoid reference counting. I also want to avoid scanning the stack and register values for objects.
17:03
The non-bootstrap JARs in the target should be in their own directory. This would have far better results because I could potentially add third party JARs and such.
17:49
I do wonder how I will implement the StreamProcessor along with the
supporting the helper classes needed for inflating compressed data.
18:07
I will need a simple but efficient stream processor.
18:09
I suppose a direct approach will work. Basically the StreamProcessor reads
input bytes and stores them somewhere after they are processed. So the class
then will just purely be for reading. The output stream can just be mapped
similarly.
18:21
Actually, from StreamProcessor and StreamProcessorInputStream I am going
to have the same code or just wrapped code. Read from some source and do stuff
with it.
19:01
Ok so I have been thinking, StreamProcessor is a bad idea. It will just
complicate things and right now only two classes will use it, for inflate and
deflate. Also in the most common cases, one will never OutputStream inflate
and InputStream deflate. So there is not much point in having these classes
at all. The stream processing is just over engineered and will just complicate
the implementation greatly.