Unless the "reserved" areas in the structures are used to send extra information to the JVM itself. Otherwise how would it be known what the boot strap class path is?


No, so then how is the bootstrap classpath actually sent to the JVM? Is it built into the binary, are there any symbols which are linkable that give this information, is it magically passed into the JVM?


JAVA_HOME is not set at all.


JamVM to set the Java home directory just uses dladdr which is non-POSIX specific to find the location of the Java home directory.


I installed an old version of OpenJDK 8 with JamVM so that I can use it in development of SquirrelJME so I do not have to wait 5-10 minutes for Zero to run when JamVM takes up to 3 minutes.


I believe I will unify directory handling, sort of. Or perhaps just make it more checked. For each binary JAR there has to be "X-SquirrelJME-BinaryName" for it to be considered a binary project. Otherwise it will be considered source and the other property must not exist. If neither property is set then it will be treated as an "imported" JAR (if it has a manifest that is). Another thing I can do is split off ProjectInfo to have a binary form and another with a source form, then extend a base class. This way there is no two state sharing between binaries and sources.


Then I can also have a BinaryProjectManifest which provides higher level access to the binary information. This manifest could be generated by source projects (i.e. a generateBinaryProjectManifest()). The manifest would have a representation of which kind of project it is (API, MIDlet, or LIBlet). Having the source project generate one could simplify things. Also the auto-interpreter could use it for determining which non-compiled source projects would be if they were binary projects. This way, it would not be required to compile every source project just to see if it is to be included in the default API set. Currently this is more efficient than before because before I would have had to compile the source project just to see the manifest that would be used.


This means that ProjectList and ProjectGroup become deprecated. The compile portions of ProjectGroup will be moved into SourceProject. Generally one would just request binary projects and/or source projects.


Should I have virtual binary project representations for all source projects that may exist. It might not be needed at all.


So now that I am changing around the project manager, I believe I will remove the internal and external dependency types. I would just treat all dependencies as internal for the most part. When it comes to implementations of APIs in other projects (such as for OpenGL ES) they would not be depended on at all and not even optionally as it currently is. The target builder and the auto-interpreter could determine which implementation of an API to include. I may in the future need a wildcard selection, a kind of inexpensive regex, where I can do for example mips-*,*+*.(bsd|macosx).*.