2015/12/15

DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.

11:30

There is a hostile bug stuck between the window panes. It is black, has a red colored thorax with a large black stinger sticking out the back of it. Has six legs too.

11:42

Cannot determine what this bug is.

15:35

The Cache<Foo> instance is not needed once the One or Many are obtained so I can instead get the stuff through a static initializer.

16:12

Having specific interfaces for member, field, and method flags will be a bit easier since unchecked casts would not be required.

17:09

Solving this flag stuff is rather complex.

18:59

But I figured it out.

20:43

Looking at AArch64 it is basically a MIPS64 clone.

21:14

I wonder how I am going to handle bootstrap methods. I suppose the best thing to do would for them to be actual references which may be used by code areas and such. They would be bound on load for example.

21:18

Kind of thinking about it, I could implement a base class in the binary code which is essentially a serializer of sorts for writing class files. Then class formats (currently just the KBF format) will be told the data to write and such and it can do what it desires for example. This way if I ever write a new format output (A Java compiler will need to output class files) I can then just still use that class and still make things simpler. Then doing this I can simplify the code by having less duplicate code. I can also use the DataAccessor in write mode too.

21:22

Yes, that would be much better. Currently my output references the KBF writer directly. This can instead be done through the binary interface. This also solves future problems where stuff is added to the base Bin* interfaces. It will need an additional handler in the base writer class. Having each binary format on its own would make that more difficult because changes could be missed for example. The thing is though is designing this interface to not be bad at all. Another possible thing to do is have it also on the read of data too. So the stuff such as JavaClass no longer has tons of interfaces sort of but relies on a standard reader support for classes. Then it would be possible to offload and share reading code between stuff such as KBFs and Java class files. The Java class file is a rather linear format where the future depends on the past, KBF is directly indexable. So the reader and writer would have to handle such things. The way to code it would be so that there is more stuff shared and where it is not a complete mess to implement support for class files and KBFs. The interfaces should also be simple.

21:31

I suppose the basis would be a payload which contains classes. The payload would have to be loaded with classes which would then essentially write out the file depending on the input. There would have to be support for regions.

All of my Bin* stuff is good and clean. Right now the ugly parts are reading and writing the files. The Cache class made reading Java class files a bit better. However the whole thing could be done better anyway.

21:36

I could however take a BFD approach to things. Basically there is only a single read/write class and stuff such as KBF and Java instead just implement a BFD-like thing for various parts of the file for decoding. Then with a standard possible way of having read/write of structures and such there would be the potential of not even needing a KBF package. Depends on my creativity though. I could parse a text based format to describe everything about a binary at which point the support for class data will essentially be only in a single file. That would require the text file to be parsed however. That would also mean that adding support for new formats or changing them would just need a new text file.

21:40

An alternative from text though and would probably be faster and easier to do would be to have a class which describes the format. At least then I would not have to write a text parser and a text based format for loading. So a class would probably be the simplest route. Then with shared data I can essentially support reading and writing with the same code which saves time writing later readers and writers.

22:57

I should be sleeping. However, the BDF (Binary Data Format) will have to have a kind of sectioning. I must determine the best way to do such things.

Actually I had this rather crazy idea. I can use Proxies. Basically the BDF describes the format, however a proxy over the basic Bin interfaces will handle stuff such as reading. However that might not even be needed at all. However, the proxies can directly use the data when reading for example. That way there will not be any requirement for generated code.

23:02

The Proxy could be wrapped with help from MethodHandles and such to support truly dynamic generation of classes at runtime for reading class data. At least using a InvocationHandler there would be no need to create a bunch of wrapper classes for read/write. There may be a speed impact though, but there would essentially only need to be a few classes rather than a whole slew of implemented interfaces for read/write.

23:08

InvocationHandler also has a single method which makes it a functional interface, which means using lambdas to create proxies is easy and there is no need for a new class just to have a handler.