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.



Naming units for the most part.


I believe for images, instead of creating a few thousand sprites with various rotations I will use voxels instead. Would require creation of a text based voxel format and editor of the data. This would probably be the simplest route at a slight cost of complexity. The rotations of the voxel data could even be rendered at run-time when a frame is needed.


I suppose editing voxel images will be cube stacking (attaching a cube to another cube with a specific color) and specific splices. The other alternative to voxels is to actually use 3D models. Using 3D models would at least have it where I could have skeletons. However creation of models is a bit complex when it comes to editing them. Voxels would be easier to draw, however 3D models would be more universal. Pre-existing 3D editing tools are a pain to use though due to the varying differences and explicit requirement of things.


It appears my desktop SSD is failing, thus I am going to resume work on my laptops. There is a laptop in plans by a group to make a PowerPC laptop. This would be rather interesting.


I can probably also split the first Java library, but before I do that I must determine the interdependencies of the stuff to figure out how to split the packages. So I suppose I should generate a DOT of the imports declared in packages and such.


Looking at the graph, I can split out...


Well actually, I can explot the boot-built stuff. Since the host will have to be a Java 8 system, I can just move function into its own project and then have it not be boot built. However, the compiler detects when there is a name collision between stuff that is compiled and stuff that is in the classpath. Actually forget that, I had just forgotten package in my small class. So yes I can exploit this fact.


Figured out how the javax.security.auth.login is used. That code is basically just an authenticator. It does not actually do any authentic work. What it can be used for though is say a login screen to start a shell. It can basically run a user authentication setup to determine if a password is valid or not (or request a password) before a login is actually made.


The compact2 profile can also be split around. Although the compact2 will be easier to split, it is essentially in 3 pieces: RMI, SQL, and XML/W3C.


I can also continue the split on compact3. I can also work on splitting the complete remaining API (compact4).


I believe I will start with compact4 first since that contains stuff such as Swing and AWT.


ImageIO depends on AWT. However, for Swing, these three are a concern:

java__awt -> javax__swing__text;
java__awt__im__spi -> javax__swing;
javax__accessibility -> javax__swing__text;

So I should see how dependent javax.swing.text is. And that depends on everything. So far then, awt, swing, accessibility, and print must be together in a gui subpackage.

So this is much more complex.


Actually beans are part of the GUI system.


The default provided PLAFs can also go into their own packages also.


And now to finally split compact3.


The preferences API looks rather interesting and I will most likely use that for my operating system. To think of it, due to the splits I have made of the code I can have other programs use it without requiring the entire compact3 profile to be pulled in. This is exceptionally nice.