assets/developer-notes/stephanie-gawroriski/2016/10/20.mkd

   1 # 2016/10/20
   2
   3 ## 08:11
   4
   5 Unless the "reserved" areas in the structures are used to send extra
   6 information to the JVM itself. Otherwise how would it be known what the boot
   7 strap class path is?
   8
   9 ## 08:26
  10
  11 No, so then how is the bootstrap classpath actually sent to the JVM? Is it
  12 built into the binary, are there any symbols which are linkable that give this
  13 information, is it magically passed into the JVM?
  14
  15 ## 08:29
  16
  17 `JAVA_HOME` is not set at all.
  18
  19 ## 08:45
  20
  21 JamVM to set the Java home directory just uses `dladdr` which is non-POSIX
  22 specific to find the location of the Java home directory.
  23
  24 ## 10:59
  25
  26 I installed an old version of OpenJDK 8 with JamVM so that I can use it in
  27 development of SquirrelJME so I do not have to wait 5-10 minutes for Zero to
  28 run when JamVM takes up to 3 minutes.
  29
  30 ## 14:51
  31
  32 I believe I will unify directory handling, sort of. Or perhaps just make it
  33 more checked. For each binary JAR there has to be "X-SquirrelJME-BinaryName"
  34 for it to be considered a binary project. Otherwise it will be considered
  35 source and the other property must not exist. If neither property is set then
  36 it will be treated as an "imported" JAR (if it has a manifest that is).
  37 Another thing I can do is split off `ProjectInfo` to have a binary form and
  38 another with a source form, then extend a base class. This way there is no
  39 two state sharing between binaries and sources.
  40
  41 ## 14:59
  42
  43 Then I can also have a `BinaryProjectManifest` which provides higher level
  44 access to the binary information. This manifest could be generated by source
  45 projects (i.e. a `generateBinaryProjectManifest()`). The manifest would have a
  46 representation of which kind of project it is (API, MIDlet, or LIBlet). Having
  47 the source project generate one could simplify things. Also the
  48 auto-interpreter could use it for determining which non-compiled source
  49 projects would be if they were binary projects. This way, it would not be
  50 required to compile every source project just to see if it is to be included
  51 in the default API set. Currently this is more efficient than before because
  52 before I would have had to compile the source project just to see the manifest
  53 that would be used.
  54
  55 ## 15:24
  56
  57 This means that `ProjectList` and `ProjectGroup` become deprecated. The
  58 compile portions of `ProjectGroup` will be moved into `SourceProject`.
  59 Generally one would just request binary projects and/or source projects.
  60
  61 ## 15:47
  62
  63 Should I have virtual binary project representations for all source projects
  64 that may exist. It might not be needed at all.
  65
  66 ## 15:49
  67
  68 So now that I am changing around the project manager, I believe I will remove
  69 the internal and external dependency types. I would just treat all
  70 dependencies as internal for the most part. When it comes to implementations
  71 of APIs in other projects (such as for OpenGL ES) they would not be
  72 depended on at all and not even optionally as it currently is. The target
  73 builder and the auto-interpreter could determine which implementation of an
  74 API to include. I may in the future need a wildcard selection, a kind of
  75 inexpensive regex, where I can do for example `mips-*,*+*.(bsd|macosx).*`.