My projects will need dependencies and other things such as inclusion. I have to have profiles and implemented standards for projects essentially. Some of this information can be shared with the launcher too, which does not need a complete view of information.
I am thinking of potentially refactoring the project dependency system so that some dependencies can be auto-selected based on the configuration or profile they require. So basically, all projects will need an optional profile set and then they will need a configuration. I can also use a set of determination for profiles and such. Basically I need to make profiles in SquirrelJME more apparent. I suppose also, I could perform a major restructoring of SquirrelJME I suppose. Maybe.
Although maybe I could just add an extra depth. For example src can contain directories such as "game". Essentially there would be package namespaces so to speak. Or maybe what I just need is an "extra" directory. Basically this directory would contain stuff such as Squirrel Scavanger. Then the src directory would contain the core set of projects. I already have the contrib directory, but having a new directory for non-core stuff would be nice.
In fact, I could have automatic namespacing with a
NAMESPACE.MF file for
each source directory.
I could also have it where I can remove dependencies and just have package level dependencies. Essentially, Squirrel Scavenger instead of depending on opengles, it will depend on javax.microedition.khronos.opengles. Then the opengles project will automatically be included for compilation.
A number of classes are also only used by the JIT too. Also, some are only used by the build system. Basically, I want to remove all of the cruft that exists in the single directory.
Also, one thing I should do is potentially greatly remove the number of projects that are used. That is, remove ones that are not needed at all and fold others into other projects. For example the image reader can be moved into the LCDUI code and anything that needs to handle images can just use LCDUI image code essentially.
When it comes to SquirrelJME and unsafe, I can just rewrite the entire package to use another one. This way I can split the static calls into multiple places in unsafe rather than having it just in one place.
Actually, I should keep dependencies. However for dependencies I should instead have a namespace prefix so that it is known which namespace the project should get dependencies from. Then on top of that, I could actually have namespace renaming. Since ':' is reserved, I would suppose I would use @. So one that relies on the manifest parser would be 'foo@manifest'. But one thing that can be ugly are the liblets and such. For example, Squirrel Scavanger has a dependency on OpenGL ES. So essentially, the system would depend on opengles. This is rather ugly. OpenGL ES will either be a part of the target or it will not be. I also should split Squirrel Scavenger into more parts based on the backing GUI implementation.
I believe I should get rid of the data sink, faucet, and pipe classes. The inflate compression code along with the CRC checking code could be much simpler.
So my code builds again. What I must do is make it so the project handling classes can handle namespaces.
I suppose I will have a
ProjectNamespaces which contains every namespace
ProjectNamespace is essentially
ProjectList for a single
What I can do is have it where I can specify virtualized namespaces with the
project manager. So for example I can construct a
ProjectList which extra
namespaces to source projects from. This would allow projects that are in
other locations to be used.
Actually, instead of
ProjectList, it can be
Going to make it where dependencies use standard names, profiles, and
configurations. Then my build system will determine which projects to
actually pull in based on the namespace they reside in. So, I will
essentially getting rid of the name based dependencies. However, since
I want MIDlets to also be LIBlets (despite this being invalid) I suppose
I can parse
LIBlet-Dependency-<n>. For dependencies that existed before
MIDP3 (such as OpenGL ES) I will make my own up that make sense. This way
selection of projects to be included by the output SquirrelJME binary will
be determined on what is available. So after this refactor I want it so you
can build a Linux running SquirrelJME with virtually nothing in it to be
as minimal as possible, or one that contains the entire set of things to be
implemented. The former for example, I can use it on routers to run Java
programs which would be useful for me potentially. This would be compared to
using full sets or minimal sets where they are fixed to a target.
Seems the standard set of JARs has the following:
API-- The API (JSR###).
- Could be CLDC,
API-Name-- The full "nice" name of the API.
API-Type-- Configuration, Optional, Profile
API-Specification-Version-- The API version.
API-Dependencies-- Dependency groups that may be separated by commas to represent multiple ones. Single groups may be separated by a pipe to indicate multiple ones.
This would be quite simple to use and means that standard libraries could use this. So I suppose that those that provide APIs can use this way of handling dependencies. These would be specific to APIs. So the APIs would not need to have dependencies setup. So this means a project would either be an API provider or something that uses API.
Java ME 8 uses the same stuff naturally, but I do not see any mentions of the dependency names used by liblets.
So MEEP is a profile, but stuff such as GCF and MEEP-IO are optional. So how are they even used?
Ok, so these are internally specified in the executable binary since the service names appear as strings in the binary. What is interesting is that the following strings appear:
These themselves are not specified at all. Some of these may be system properties. The ME docs say nothing about 'meep.version' for example. So they are likely system properties. Since the FileConnection.version one is a system property.
And these properties are likely defined directly in the binary.
Ok, so I believe I get it. MEEP is specified as 8.0, and the microedition-profile is MEEP-8. Then a similar thing is done for CLDC and other such things. So profile could sort of technically use MEEP-8.0.0 if it wanted to.
Thinking about it, perhaps I should merge CLDC and CLDC Compact and just make it full?
Well, I could just use my own magic. Have API dependencies use a sub-variant and the full one will just depend on the compact one. It will be a part of the version.
So JARs will be APIs, LIBlets, or MIDlets to match Java ME. Although it is a bit more limited compared to what I have before, it more closely matches how Java ME and the former J2ME operate.
For the projects and launcher, I should probably use the MEEP SWM classes.
Looks like IMCConnection in MEEP does not have authorization anymore.
Perhaps I should model the project manager on top of SWM. SWM uses interfaces and then I care share some of the code between the launcher and a few other things.
No because suites are internal. But I should model the project builder and such in a way where it can easily be mapped to it for the auto-interpreter. So it could easily be used.
The project handler would be a bit more powerful, so APIs would be part of the "System" suite rather than be a library or application.
Thinking about it, I have the launcher as a separate process. However should it be just part of the kernel process? It would be somewhat a bit more "secure" as a user process, however everything would essentially be bridged to the server anyway using IMC. So effectively the launcher and the kernel will have duplicate code managing everything.
Then MEEP's SWM can just be an IMC to the launcher system that manages the JARs that are installed in the system along with tasks.
I should probably normalize all the manifests that exist.
I wonder if you can SO inject dlopen. Basically I have idea to write a Java SE
VM (like I have before) so I could potentially compile faster on PowerPC based
systems (since I use one daily). However, one issue is I would want to use the
standard OpenJDK classes on the system. Definitely feature creeping for a
bonus library however. A problem with existing libraries is if they
Essentially I could not replace these. However, one feature I could use is
dynamic library re-interpretation. Some programs running on PowerPC systems
may hardcode a shared library. I essentially have to trap System.loadLibrary()
and instead choose an alternative library instead potentially. However, likely
the best choice reliably would be to implement the JIT first in my own
SquirrelJME. If I can output to a ELF file that I can link with using a C
program, I could essentially create my own
libjvm.so. However a problem with
that is SquirrelJME does not support reflection and I have no plans to have it