assets/developer-notes/stephanie-gawroriski/2014/09/27.mkd

   1 # 2014/09/27
   2
   3 ***DISCLAIMER***: _These notes are from the defunct k8 project which_
   4 _precedes SquirrelJME. The notes for SquirrelJME start on 2016/02/26!_
   5 _The k8 project was effectively a Java SE 8 operating system and as such_
   6 _all of the notes are in the context of that scope. That project is no_
   7 _longer my goal as SquirrelJME is the spiritual successor to it._
   8
   9 ## 02:00
  10
  11 For clarity all of the wrapped compilation work should be placed in memory,
  12 although this will not be possible for command line wrapped compilers. It is
  13 only possible for my simple compiler in the future and the built in compiler
  14 in the runtime.
  15
  16 ## 02:07
  17
  18 Doing all of this dynamic reflection of the compiler invocation code is rather
  19 ugly. What I can do instead is embed a class directly in InvokerAPIJC which
  20 contains precompiled Java 6 code. I dislike having binary code already
  21 existing but it would produce far cleaner code as I can use the tool interface
  22 directly.
  23
  24 ## 02:23
  25
  26 For the compiler wrapper, the command line version will need to operate on
  27 files, however I would like it to be able to operate entirely in memory, so
  28 that must be the case which is used. OK, so what I will do is model the
  29 wrapper like the existing JavaCompiler class and just keep it very very
  30 simple, inputs and outputs are either absolute files or a stream of bytes in
  31 memory. For the command line based compilation wrapping (of say gcj and ecj)
  32 it will instead create temporary directory to simulate compilation operations
  33 (since there is no way to portably have it use a filesystem completely in
  34 memory).
  35
  36 ## 02:45
  37
  38 What I need to determine is how the JavaCompiler files are input and output
  39 and where they are placed.
  40
  41 ## 03:07
  42
  43 So I essentially will need to make my own JavaFileManager with file objects
  44 for my wrapper.
  45
  46 ## 05:10
  47
  48 InternalDoBuild is too complex for its own good. Going to instead use domains
  49 which are like beacons in almost every way but are a bit more friendlier and
  50 simpler to use. But first, I need to cleanup InternalDoBuild so that it is
  51 easier to use it to compile dependencies and such, since it pretty much is
  52 currently a singleton class which is rather ugly.
  53
  54 ## 05:18
  55
  56 The problem with beacons was that it is too specific to the compiler,
  57 essentially it would make the compiler happy but only once.
  58
  59 ## 06:04
  60
  61 This cleanup is still only partial, but InternalDoBuild looks much nicer and
  62 is much easier to modify now. Not to mention shorter currently.
  63
  64 ## 06:08
  65
  66 For the DomainManager to be used very efficiently with the package builder and
  67 such, I need much more than the base string, I need a complete table mapped
  68 thing and a way to search for existing domains that were added.
  69
  70 ## 07:14
  71
  72 The toStrings() for the domains will need to be a special unique prefix so
  73 they can be recycled.
  74
  75 ## 09:08
  76
  77 Instead of including byte code, I just stumbled upon a reflection class called
  78 Proxy which can implement interfaces. Now one thing I do wonder if it would be
  79 possible to dynamically create the classes that implement unknown interfaces
  80 of unknown classes. And it is quite possible, I can easily determine stuff and
  81 wrap it, although it will be a bit strewn out, it could work. This would
  82 probably be the only dynamic means to support API management in the compiler
  83 wrapper without embedding class files or forcing Java 6 support. And another
  84 thing is I could use proxy classes for my future testing code, so that could
  85 work out well.
  86
  87 ## 09:26
  88
  89 I am very excited and happy, this is the breakthrough that I need for my
  90 compiler wrapper.
  91
  92 ## 09:36
  93
  94 I only need to use the proxy classes to use for the JavaCompiler newTask where
  95 it requires FileManagers and such, so I do not need to completely replace an
  96 existing JavaCompiler. Although it would be handy to wrap.
  97
  98 ## 10:17
  99
 100 It has been a long morning and I must be getting to sleep very soon, when I am
 101 fully awake when I wake up I can continue making progress.
 102
 103 ## 17:41
 104
 105 Actually have not slept at all, do not feel well. With all of this proxy stuff
 106 I am going to need a reflective dynamic call thing. A base class which can
 107 spit out proxies of a desired type and perform call wrapping on existing
 108 objects when needed. With a type of wilcard system for unknown arguments and
 109 such.
 110