So the executable should provide information on what an executable actually is. However with the design of Java ME, it is possible for executables to be three things: standard JARs (Main-Class), MIDlets, and LIBlets. Of course liblets should be listed last for example mostly because they are not executable, however I would like allow the specification of alternative main entry points for example. So say if a liblet has a test function or some main interface hidden in it, the user should be able to call that main method.


Another consideration is that MIDlets and LIBlets can contain multiple programs within a single binary. So this means multiple executables that point to the same location for example.


I also need to handle JAD files, although I personally would prefer it if the information were just placed into the JAR's manifest.


The kernel will have to interact with the executable system and the executable finder so that push notifications and events can launch other midlets and such.


I believe I will impose a limitation that applications and such may only be found if they are currently active in executable finders. So for example a class path dependency of foo/bar.jar would be illegal and it would attempt to use bar.jar instead in any of the executable finders which exist. All finders have to be used because some libraries could be built-in.


To increase some speed potential and reduce the space needed for compiled applications being stored, JARs should only be compiled and packaged as if they were alone. They would however require a way to detect if a dependency was changed to trigger a recompile. The library fragments would be loaded and linked in as required. Provided I check if dependencies are out of date I can get away with static references and indices to classes. Libraries would have to be compiled first. For each library compiled, it would be given static addresses to classes and such. Then following this, the compilation will flow up to the program being ran which would then use those static references to do more things. This would require a non-looping dependency set however, which is required by the virtual machine anyway. However, what would be a bit complicated however are the three states of executables. If a JAR is a classic application, a MIDLet, and a LIBlet it can have three distinct dependency sets. There are also optional dependencies. Also when it comes to a JIT, it might just take forever to compile every single class that exists in the JAR and its dependencies. On limited systems, the user might just give up if a program is taking forever to start because it is compiling everything for maximum speed. So as I thought of before, I should instead of having extreme optimization of static devise a means where I can still somewhat do it, but be able to detect if a class dependency has changed and such. Calculating SHA-1 sums or similar for class files will be a lengthy operation however. So I just need a nice and faster checksum algorithm that is not an intensive operation. Those do exist. When it comes to verification, it will be done at compile time.


The hashing algorithm to use would likely be MurmurHash since it is fast and is adequite to find some collisions and changes. I could base a class file on its hash and store it in the cache. The cache would need to store the name of the class and its hash. There is a possibility of a class with the same name using different hashes can exist.


The executable interface can provide access to raw resource and class data somewhat. Well, actually instead I need an archive which provides access to resources. I need this for getResourceAsStream and ServiceLoader, where the later looks at multiple service records to find classes to use.


Then instead of executables, I can instead reference executables from archives instead. So if there is a JAR which provides 3 types of programs and say 42 different midlets in it, it would not massively clutter the programs available. This would be good for low memory systems. So basically instead I would have ArchiveFinder provided to the console interface. Then executable finders would be attached to archives and programs would be accessed through archives which as a group would act as a classpath. Native binaries would also be archives but they would instead act as binaries for the most part. However to handle differing things, the archive finder would instead have locateClass and locateResource. Treating class files as resources would be a bit ugly. However, for common cache-ness, ArchiveFinder should be an abstract class instead of an interface so that resource locations and classes could be cached.


On the start of the user interface, the archives could be scanned and cached by the kernel for example. Then each program that is running with its set classpath could instead use archives to reference details and such. This way if 20 programs are running at once and they all share libraries, the libraries only have to be in memory at a single time. However since everything would be a library, I would need to adjust the compiler as before and not overly optimize static values. I would have to backtrack a bit and have it so classes can be compiled without knowing about any other class. Then that information would have to be checked at run-time or with the interpreter. However to remove the duplicate checking code, I can have a common class to check details in the run-time. So basically the NCI will have this checker, however its lookup class will be removed and not used by other places such as the byte code. The byte code representation itself would optimize only if it knows the details against itself. Archives can expose classes as NCIClass for example which could be bound to real class files or native binaries which provide internal details. So say if the CLDC is a native library and the user wants to run a class in an interpreter, the interpreted class must be able to access the native class details. The opposite has to be able to happen also.


Also to maximize memory savings when it comes to the descriptors, I should have bulk caches of them so that multiple descriptors which share similar string values can potentially reduce memory usage and such. There could quite possibly be a few hundred instances of java/lang/Object strings in memory at one time.


And now I have cached symbols, so memory can now be saved when many classes would likely share symbols. Although slightly slower, the decreased memory usage is a bonus. Also means that strings can be thrown away more often. I should also intern NCIUTF also so that it uses a single string set. Note that intern is managed by my own library as a WeakHashMap rather than magical JVM specific stuff for the most part. Although intern checks if the JVM has the string interned already.


Also, to the virtual machine all UTF strings are deemed to be interned anyway.


The Archive class could also manage the manifest which is used to determine which programs an archive provides and such.


What I need is a way to bridge the archive to the kernel. I need actual archive finders now.


Actually, I will need a somewhat better menu interface on the console UI. I suppose first I will list archive finders which are then selected, this would go then into the list of archives that were found. Then when an archive is selected, it will list the available programs.


So currently I just have a simple going up and down a menu without selecting anything at all.


I could probably use a kind of drop thread to a process from the kernel.


Made a number of commits this day, pretty nice. Although I have not made any in the past few hours. Suppose a short break of sorts. I suppose for simplicity the archives would be scanned and stored. Whenever a rescan is done the information is potentially updated as such. This way if a new file is added it can be rescanned and used.


I repaired my glasses rather nicely. Previously they were broken in the middle of the bridge (which makes me quite lucky). The first time they broke I took a paperclip across the bridge and wrapped a few wires of thin copper around it. They initially snapped on 2015/07/10. I wrote this on another project in my notes:

My glasses snapped in half earlier today also, which was not really a good thing. However I repaired them myself after two attempts of which the second succeeding. The center bridge between the lens was split in the middle, so my successful attempt was taking copy wire and wrapping it around the hooks that make part of the nose rest and then looping it around the branch. I did that once and then placed a cut piece of paper clip and wrapped the copper wire around that. I repeated until the center then brought in the other side (with some help as the other held both sides of the glasses). Once I wrapped around the bar on the right side too I then finished it with a loop around the nose rest thing. Continued with a small loop back and then cut the wire. I then soldered a whole bunch around it until it was soldered and one solid piece. My first try soldering it ended up in the lens being shifted so a bit wrong. So luckily once the solder melted again I could adjust the bits as needed. Once I got it good enough I let it solidify. Luckily for me it felt as if the glasses are a single piece. I suppose the solder bound between the copper, the paperclip, and the frame of the glasses to take up a good solid shape. After that ordeal, I wrapped some electrical tape around the solder job so solder and copper bits do not contact my skin. So a good thing is that I always go for metal glasses. And after this, the glasses do not fall off my head as they did before.

So I did essentially the same thing except instead I used thicker tinned copper. After the initial wrapping the glasses were surprisingly sturdy even before being soldered, while before they were shaky and had to be soldered on a very flat surface with hot glue holding the glasses in place. So just the better wire made things much better. I have been holding off repairing my glasses for a month or two though. The copper wires snapped which slowly started to cause the insides to slip around and such. I did not add electrical tape at all though. However, as extra insurance against the pieces breaking off the nose rest supports I wrapped some more wire around the two pieces and soldered those in place. I just hope this soldering job lasts quite awhile similar to my previous job. I forgot when I got these glasses however, I probably got them around 6 years ago so they are still hanging on some. It is difficult to get new pairs of glasses.