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.
Just woke up, now to get some work doen hopefully. As noted previously I need to work on RFCJsonISR.
And now that such class is done (was simple to implement), the next piece of work to move into I am not sure of yet. I suppose continuation of the build plugin and package management stuff so that I can get an eventual build of packages.
Now I am able to start work into my compiler, I thought about using the host compiler in BuildPackage (with -host) but I changed that to use the host libraries instead. Now begins the long trek to work on a compiler. Then at least with that I can compiler Java 1.8 code and target 1.5 or whichever version the host is running. I will need a clean compiler, most likely plugin based like how I have my package manager (it works well for what it is). Will need to have my shell scripts handle services.
Appears GIJ/GCJ supports ServiceLoader, I knew the class existed before but in this case it actually works.
I will need a good programmatic API to the compiler, which would be used by the command line version and the javax.tools stuff. The main part will be translated to and from abstract tree format.
Will need a good intermediate language also. Based on Wikipedia the three address code type format seems nice and simple to use. It is mostly just operative math and such. However, I need something a bit more complex in regards to memory operations and such.
Thought about having a ZipBeacon which would allow me to at least read from ZIP files to support for the possible decompilation of class files.
I am very much excited, however I cannot code because of it and I feel a bit sick from it.
I need a type of flow for compilation, to determine what is put in and what is put out, with the compiler. A pipeline of sorts, where there are specific stages of translation.
I am going to need an list of files contained within a beacon so that it would be easier to determine which files need compiling and which files are to be put in the output jar file.
Ok, my beacon code works and I do know it works. However perhaps instead I should do something more elaborate and implement an actual filesystem of sorts so that way I can use the same code later for my kernel file systems. Then that would mean I would only have to write things very few times. It would be like FUSE in a way except a bit better and more advanced. My utilties would then be capable of using all of the filesystem code to check, create, and do all kinds of stuff with them. Since the compiler would use the host filesystem I could then write a wrapper filesystem which uses actual Java APIs to access files on the disk. Then with all of the filesystem code I can just compile to and from the filesystem directory, whether it is synthetic or exists as a partition of sorts. For disk images, I would have to use a sort of random access for the base file and to overwrite bits on the inside of it, otherwise using block based imagry I would have to read the entire filesystem and write the entire filesystem in one go, which is not feasable. I have never used such a portion of the Java library however in terms of this kind of file usage, has mostly been file streams and such (InputStream and OutputStream). Now if Java is capable of overwriting the middle of the file then good things will occur since that is expected behavior. Seems RandomAccessFile would do what I need to do such as it acting like a buffer. It does use 64-bit pointers which is a good thing, because being limited to 4GiB is nasty. Intead of using basic stuff I can use the NIO channels instead, since they would be simply been seen as channels, and using the new NIO code would be a bit leaner. Although I would have to limit part of my code to stuff only available in Java 1.5. 1.7 has the FileSystem class however, so I would not want to write duplicate code in multiple places. At least the filesystems stuff is in the compact1 profile. However, there is SeekableByteChannel but that only appears in 1.7 and up. Perhaps I am worrying about such things a bit prematurely, as this is just a compiler and such result would end up be insanely complex. I would not want to shelve off the compiler to write this filesystem stuff. Now that I think of it the beacon stuff is nice, but it kind of complicates things sort of. I can store files temporarily in memory with MemoryBeacon and read files with FileBeacon, but it kind of gets complicated. The compiler would probably work best using RandomAccessFiles for everything.