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.
Need to figure out how to name classes in regards to the cache, they need a checksum to determine if their registered base has changed. Class files are usually in JAR files, so the cache information will have to store said information on that because multiple differing classpaths may have the same names for classes and packages. Such a thing would be problematic. So the cache area will need to have sourcing information. The kernel when given a classpath will need to keep each group completely separated linked within its own cache. Each class that gets recompiled into C code must be independent and not rely on the state of other classes. So there will have to be a way to identify say a JAR in the classpath uniquely. I could use the Aha-1 sum of the JAR and then keep an index managed and such. The manager also needs to be separated so that it could be used by the recompilation system. That way the recompilation system can just run through all the classes and just cache everything on the disk like the operating system would do itself.
I suppose for clarity, dynamically generated classes or ones that pop up out of nowhere with no defined classpath (say with ClassLoader.define()), will probably not be cached at all.
Well, the classes could be cached and they would obviously have a one time use set for them. The main thing everything will use is the ClassLoader, which has a define class. defineClass would obviously be native. And that would interact directly with the class manager system. Since each class file is itself a class file, I could just read the defined bytes and then calculate a hashsum (such as sha-1) on the class then look at the disc to see if such a file exists. That would be the bulk of the operations. So in reality, there is no such thing as a classpath. The classpath is just a faux concept in Java which is managed by the ClassLoader and such. The "system" classloader could just may as well be a URLClassLoader. This simplifies the cache system however. I have to choose a good hash algorithm otherwise collisions will occur, but so far for sha-1 no collisions are known. Of course I will need a keying system to determine when a class was last used and such and how "important" it is.
Ok so repository view and master repository are not required a single bit. This leaves just one class then which provides a repository interface. Since it is used by the kernel and the build system, but more the kernel, it should perhaps just be in the kernel and then I can just depend on it in the build system. Main kernel classes cannot really be called however due to the fact that there would be native methods and k8 specific things inside of it. The cache manager would at least be abstract and use NIO to do things at least. The cache manager as I would run it, would be a sub-process anyway that interacts deeply with the kernel anyway.
Actually, I cannot use base64 for my cache filenames because the cache could be on a case-insensitive filesystem such as Windows, which means there is an extra chance of collision and building the kernel may fail on such systems. The same applies to ISOs also, which would make having root be an ISO very bad.
I decided on base16, although it will result in longer names. Or I could just use BigInteger, however that needs padding but that is not much of an issue. And with that, I can use base36 which is even more compact.