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
-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.