DISCLAIMER: These notes are from the defunct k8 project which precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26! The k8 project was effectively a Java SE 8 operating system and as such all of the notes are in the context of that scope. That project is no longer my goal as SquirrelJME is the spiritual successor to it.
07:36
Looks like classes might not be read properly (their buffers) in the class
loader. I was never increasing at. I also decided to just add hairball to
the default primary HairballClassLoader.
07:48
The class for BuildFailedException is being loaded however and the
ClassLoader returns it but it seems it wants to check a URLClassLoader
instead after it.
09:15
It is possible that the getBinaryContents() for PackageStatus may be
incorrect by using old and bad package contents. I should actually check the
file date to see if it has changed, if it has then a new contents should be
initialized.
09:23
When a package is freshly built, trying to use it in the class loader fails with being unable to find any classes.
09:33
When it comes to PackageContents, there is duplicated code with times and
such. I can really just have another class which can handle such things for me
and to reduce said duplicate code. There can also be the potential for
better efficiency and stability.
09:59
Having HairballClassLoader use package statuses instead, might be better.
That way the binaries can change and it could still find them.
12:55
Did not know that Debian comes with a netbeans package. However I need to upgrade I believe to support Java 8 anyway. I can use JDB but using a GUI debugger might be a bit easier.
13:29
i might just have to revert all these changes because I have no idea why this is happening and I am in a situation where it is difficult to use a debugger.
13:41
It is as if after compilation URLClassLoader just decides to die and be worthless.
15:43
For HairballClassLoader I can modify it so everything is based on resources
instead of just names of classes. Then those references to resources can be
cached for the most part.
15:47
Actually HairballClassLoader might not even have to cache anything at all
when I use the ready and might not even need the ready. It is up to the
loadClass() method to check if a class is already loaded. So having my
own cache is kind of pointless. The only thing that is needed is there has to
be a lock on the name. There is getClassLoadingLock(String) which goes by
the name of a class.
16:42
So the classloader is much simpler now and I still get the class not found issues. I believe online searches have shown these problems also. I suppose the only remaining alternative is to actually check if the system class loader is a URLClassLoader and then just plop on all the JARs. That may work.
17:58
That might actually be a bit hacky. It might be best to just modify the
bootstrap setup system so that it just does consecutive calls rather than
having hairball itself just be launched directly rather than have a large
URLClassLoader bridge. That would require the execution scripts to do more
work though.
18:09
I will need a script in Java which checks the version and if it is old then a bootstrap is used, otherwise if Java 8 is available just invoke the bootstrap directly. I would need three scripts still though, for UNIX, DOS, and NT. This new hairball would probably not have the class loading issues. It would also probably be much easier to maintain without requiring tons of ugly code.