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

   1 # 2014/09/29
   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:33
  10
  11 I decided to put the open for a file through the stat class because that
  12 contains a bunch of file information.
  13
  14 ## 03:09
  15
  16 Files are read by Oracle's Java compiler, however they just contain NUL
  17 characters so the getCharSequence is incorrect.
  18
  19 ## 03:13
  20
  21 Would seem that CharBuffer is not the thing that I want.
  22
  23 ## 03:35
  24
  25 The compiler appears to compile files, but it does not seem to output them
  26 anywhere at all. If I change the code so that it fails to compile (by changing
  27 all a to e), that results in failure. So there is more to the puzzle to have
  28 it actually write files. Unless it is related to the ClassLoader possibly.
  29
  30 ## 03:41
  31
  32 Actually I figured it out, I perform an ls on the directory I am in and the
  33 class files all popped up there, so it must be where the ClassLoader
  34 determines the files should be placed. Possibly not.
  35
  36 ## 03:59
  37
  38 I believe it is the hasLocation in JFM, because right now I only say that a
  39 location is valid if the configuration has a path for it. However, the
  40 compiler might see the false for CLASS_OUTPUT as "Cannot output class files,
  41 so use a default mechanism".
  42
  43 ## 04:05
  44
  45 Does not appear to be the case at all, the compiler still places them in the
  46 current directory. I will see if StandardJavaFileManager causes a difference
  47 compared to a normal JavaFileManager, I would not need to change any code
  48 because that interface extends the one I am replacing.
  49
  50 ## 04:16
  51
  52 Using StandardJavaFileManager makes no difference at all.
  53
  54 ## 06:21
  55
  56 I am completely stuck, before it was using list but now it does not. I added
  57 list in d025550fa05972bdede00fdd008553915f20a450. That was when I still had
  58 domains, but that would now make much of a difference.
  59
  60 ## 06:47
  61
  62 I believe I may have figured it out, the base file manager being used could be
  63 null, and if a null is passed to the compiler then it uses the standard file
  64 manager instead. Forcing the value of null in the call pass, causes the same
  65 result, class files in current dir.
  66
  67 ## 07:31
  68
  69 Had to eat but this is the case. I also forgot to write a throw in
  70 ProxyJavaFileManager to check the configuration so the base was never set,
  71 however the null pointer checks in other places make it more robust. Will need
  72 to write an arbitrator so that files are written to memory rather than the
  73 disk for where the API is used by the build package. This way, the source
  74 directory stays pristine.
  75
  76 ## 08:06
  77
  78 I will need to implement list which means more manager work for stats and
  79 such.
  80
  81 ## 09:32
  82
  83 Before I proceed I will need to implement access into JAR files so I can list
  84 the contents of the bootclasspath JARs on the host.
  85
  86 ## 09:55
  87
  88 The compiler has a massive call stack along with my stuff totalling 40.
  89 Another thing I can tell is that the ZIP interface is really ancient, uses
  90 Enumeration for one.
  91
  92 ## 11:33
  93
  94 I believe I have a working ls for JarHandler, now I just need to implement
  95 list in JFM: "PLATFORM_CLASS_PATH" "progress" "[CLASS]" "false".
  96
  97 ## 21:03
  98
  99 Doing the actual ls appears to be simple.
 100
 101 ## 21:22
 102
 103 And my ls was actually complicating things by adding an exploded string array
 104 (from the path) to the ls in StatControl. That of which, in SC already knows
 105 the current location because it is cached, so the implementation gets much
 106 simpler after that.
 107
 108 ## 22:21
 109
 110 Actually I am overcomplicating ls in stat, I do all this fancy explosion but
 111 the path is already known and just ls in stat (at least for JAR) works.
 112
 113 ## 22:40
 114
 115 MountTree ls works now.
 116