SquirrelJME/SquirrelJME

# 2016/04/13

## 07:58

I can actually use GCJ to compile the stuff to byte code interestingly. GCJ
appears to just completely ignore the version identifier. However, since
Java ME is essentially Java 5 in that it has nothing that makes it require
Java 7, it works regardless. Language features such as `AutoCloseable` and
such are just syntactic sugar on top of the byte code.

## 08:01

Thus potentially, GCJ could be used in the initial stages and would essentially
currently just support Linux for now. Following that then, I could develop the
main library and then also have the interpreter laid out on top of that for
example. This way I can develop the main library. I could also then reverse
engineer the output binaries to figure out how certain code is generated and
such.

## 08:35

One thing though, it seems that GCJ when given my class files is not including
any code at all even when specifying shared and such.

## 08:42

This might be because it is an interface, which has no code.

## 09:02

However, GCJ is heavily tied into GNU classpath and since Java ME lacks some
things, there are some impossible means of doing things. The only way to get
it to work on GCJ would be to rename all of my classes with a prefix and then
use a bridge of sorts so it runs on an existing VM. So this would just be
plain Java support. So that is, all of the byte codes and such would remain
the same, however instead stuff such as `java.lang.Object` would become instead
`__squirreljme.java.lang.Object`, then any references in the class would also
just become referenced as such. In reality, having this code run on an existing
VM would be quite simple when it comes to code generation. Note that a VM on
the VM would also need the compiler code to exist too so that JARs ran by the
user can be cross compiled and ran.

## 09:14

So an eventual JVM on JVM could eventually be compiled with GCJ anyway so
that it would be native for the most part. However thinking about this and the
SSA class program code. I believe that I will have the class program code not
use SSA and instead have the SSA functionality and layout elsewhere. Thus the
classprogram will strictly handle Java byte code.

## 09:17

From what I started writing at _09:02_, `Class.forName()` would be wrapped so
even if it sends it `"java.lang.Object"`, the method that would be called is:
`__squirreljme.java.lang.Class.forName()`.

## 10:04

The interpreter could then just use the bytecodes mostly directly and become a
pure intrepreter which would be simpler to implement. Then I can develop the
main library. Once that is developed, I will have enough base to have actual
native compilation without hitting TODOs all the time.

## 14:10

What if for the class file consants, instead of having all of it be in the same
class, I split the entries apart. These would be a bit easier to type and the
entry code would be slightly smaller.