The standard methods could add system properties, then I can have an adding of standard system properties.


This can also be used to determine which profiles are set and packages that are available. I just need a way to back into the package list and have it so that properties can properly be mapped and such.


Slow day today, however now I need to work on the emulator/interpreter engine. Then once the stuff can be loaded and initialized I can continue with the JIT output. Then parse that as I go along. I would suppose that the binary would use the standard Java stuff (aka -jar and -D) otherwise input arguments would be completely ignored. Since you cannot run individual classes anyway, -jar would be the way to go. I would suppose this would be passed to the launcher which initially starts, then that would start the actual program passed in the command line. I would have to parse the midlet information and handle it that way. But initially I just want the initial JVM to print a very basic message. Once it prints out that message I will create a video alpha video. At that point, the main library can be implemented and such.


All emulators should be capable of being used for TAS of games which would be handy for debugging. As such, there should be a unified input system from the console for example and unified output. There should be an emulation core which can be used to give unknowns to the target and be used for resuming previous recording sessions.


I will need to make use of CRC (simpler and faster than MD5) to determine if files have changed.


The only problem is that I cannot have console input, because Java ME cannot have that. The interpreter test will essentially be run-only. However the emulator that is ran by the interpreter should pretty much just run tests for the most part or at least give it that option. So then I would say that emulator arguments are to be removed and just have a headless test runner of sorts which is able to read the output of the emulator.