I would suppose that each list is unique for every UIList in a way. I could also have the ability to dynamically relist lists just by changing their entire state at once for example however.


I actually never stored BufferedImage into the image cache, so for each image request it recreated a new image always.


Appears that Java generics are Turing complete, however it would be a feature of the compiler for the most part. One thing that is a downfall is that during compilation there is no real way to get the output of the program and it uses an immense amount of memory to calculate.


Having an Iterator for the ClassUnits would require complex locking to be performed with the potential for there to be partial states and such. So I believe it should just return an array so that there is no need to constantly acquire locks to iterate through the units.


It might be best for the Jar provider implementations to also use arrays or similar collections. Collections may be safer however.


Today has been a bit of a slow day.


I should move the program list manager and such to another class rather than having it in the main launcher code and such.


Next would be having a selection callback in the list. If the callback is made on a selected item, a new display is created which shows the many ways that the given program could be launched. Basically it would be another list saying: MIDlet Launch (if it uses a midlet main) or Classic Launch (if it has a main class). Additionally one that will always appear would be a custom launch which basically allows a user to input a class that has a main method to be started for example.


It somewhat feels like the UI code how it is will not work out quite too well. Everything is arbitrated through the manager and bounced off that. Component creation and linkage is done by the manager itself. Instead of using the manager to create components and such, they can just be newed with the display manager to use. Then that has the appropriate communication with the native code and such. So all of the manager createFoo methods would be removed and the UI classes would be instantiated directly by code that uses it. I can however still use a similar model for cleanup and such which would not be affected. The instantiation of components would instead just be done in the UI fragments.


Another issue is the future shared state of display managers. Essentially with the current design, every program that runs would use the same exact display manager. Although there would be a memory reduced shared state, there would be a problem with separation.


So, there would be a display manager which could potentially run in the kernel space which is used by the launcher to run programs. Any vulnerability in the way the manager works and the IPC backends which clients would use to access the display would be quite bad. There still has to be a kind of integration between them however. For example, on limited systems where there is a single screen and all components must be laid out, multiple display managers would have to fight to stay around for the user. Some global resources such as system tray icons would have to cooperate in a native interface and such.


So I need to rethink some things.


I believe I will go back to the compiler, writing some of the UI interfaces and the class unit stuff has given be the information I need for a refactor of that code to fit better with the code I would end up with.