New day today.


I should make it so that JVMClass can temporarily be mutable (when it is partially loaded) then once I am done constructing it, it can be made immutable. I could then remove some data locks when accessing classes for example. I could also split off instance related information and have an instance state in the virtual machine also. Instead of having the interpreter bits built into the JVM code, I can branch it off and have a base engine for it. So essentially, I would be forking the code so to speak. Thus, what I have now with the compiler bits will go into its own project. There would only be things needed for loading classes and such, stuff which the compiler can use but not what the interpreter should use. The compiler generally is not going to need to create new instances of strings and create arrays and threads for example, it just wants to pass through the code. This would also act as separation which would be good too. If the interpreter engine needs to be rewritten then there is no need to worry about interfering with the code that is part of the compiler.


Also my list of errors is getting a bit cumbersome, so I need a better way to store the dictionary of sorts. At least when moving the code over I will potentially have to reassociate all of the error codes and prune them as needed. However, the most likely case is that most parts of the current interpreter namespace become part of the compiler base. Thus, performing these changes should result in cleaner and better to maintain code. For the mutable and immutable JVMClass variants, I will have a base class for classes and then derive a partial and complete from them. The compiler will just know about loaded classes, the interpreter would keep a cache of the classes as they are loaded into memory (one which the virtual machine would expect).


When it comes to the error codes, I can use special JavaDoc tags and put the error codes in the method description where the error is thrown. Then I can write a script which reads source code and then extracts those error codes and places them into a list.


Would also have to do the same thing with class members too, so that they are mutable and can be partially loaded also.


I would suppose that the class loading code should be part of the base code.


Looks like Java 9 will be released later this year. But regardless of that, it is refactoring time.


Also instead of java-interpreter and java-interpreter-local it will just be the former with the base class stuff split off as required.


I can also split off the code parser and the compiler core (the program stuff) from the base class loading stuff.


Now that the code has been moved, I just need to fix it all up with my new plan that I have written earlier today. The first hurdle would be to fixup the class file handler since it has at least 100 errors. However once the basic layout is fixed and such, it should be better. When it comes to programs the class file handler will just not touch that at all. Thus the program and the class file support would essentially be standalone except the program needs stuff such as the constant pool for example when the byte code and other things are parsed. CFClass will be immutable and the class file parser will just build it instead. The eventual fixup of the interpreter will have its own notion of the class and its state. This way the class file code and the program parser code remain cleaner and simpler.


This means the class file parser does not need locks at all.