assets/developer-notes/stephanie-gawroriski/2016/01/25.mkd

   1 # 2016/01/25
   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 ## 11:16
  10
  11 Currently at the hospital. In either case, must solve the classpath issue
  12 when using `URLClassLoader`. I am on my oftly used netbook which is lacking
  13 in some departments such as a lack of free graphics acceleration. Right now
  14 I am working offline completely, there are wireless access points but I am
  15 not sure of which one would be the most secure. At least with fossil I still
  16 have access to all of my commits, which is good.
  17
  18 ## 11:22
  19
  20 So the initialization of my HairballClassLoader does not trigger it.
  21
  22 ## 11:41
  23
  24 Probably the best thing to do would be to just load the classes as I can and
  25 just avoid the issue without actually fixing the issue.
  26
  27 ## 11:44
  28
  29 I should perhaps just instead add a compliance.FIXME as some kind of note of
  30 sorts for issues I am stuck on and just have to avoid. Although thinking
  31 about it, it is possible that the initialization of the compiler is chaning
  32 the context class loader perhaps so that after compiling my URLClassLoader
  33 which did work just gets wiped away.
  34
  35 ## 11:47
  36
  37 So to figure this out, I will have to just **NOT** call the compiler.
  38
  39 ## 11:49
  40
  41 Ok that is not it.
  42
  43 ## 11:50
  44
  45 Actually forget that, I never rebuilt. Ok, so it may be linked to the compiler
  46 which may be messing with the stuff. So I was right on that so far by throwing
  47 an Error before the compiler is initialized.
  48
  49 ## 11:54
  50
  51 Ok, so before I call "build" on the compiler it works and deletes. So how
  52 about just BEFORE the compiler task is initialized? And for safety it works
  53 before the task is initialized. Now to check after initialize but before the
  54 actual compilation.
  55
  56 ## 11:57
  57
  58 Ok, so initialization is fine, I am now going to drop it AFTER the running
  59 of it, and it should trigger then. It should hit then, if not I have a very
  60 odd heisenbug. And I got failure as expected. So I need to determine what the
  61 compiler is doing before and after. It is possible it is changing the system
  62 class loader or similar.
  63
  64 ## 12:02
  65
  66 Ok, so the class loaders I can easily know about work the same. It is possible
  67 that my JARs are being removed by the compiler. I am going to check that.
  68
  69 ## 12:08
  70
  71 Ok so, my URLs are the same, the compiler is just doing something it should not
  72 be doing so that it causes the classes to not be found.
  73
  74 ## 12:10
  75
  76 So the main issue is to either see the cause of it, guess, or try a work around
  77 by perhaps seeing if launching another thread does not cause said issue.
  78
  79 ## 12:20
  80
  81 The irony of portals. The WAP at the hospital asks whether to agree or to
  82 decline the terms and conditions before using it, however selecting the
  83 terms and conditions ends up going back to the portal page.
  84
  85 ## 12:33
  86
  87 Ok so running it in another thread does cause the issue. So the JavaCompiler
  88 does something which changes things. The JavaCompiler would be initialized by
  89 the class loader used by the system, while the one for hairball is used for it
  90 lower in the chain. So this has never happened before, I have changed my
  91 classes around. It also is possible that this has always existed. It is also
  92 possible that this has been fixed in a future version. However later versions
  93 do not run on my PowerPC systems at least. Also if it is fixed anyway, it
  94 would not be fixed anyway.
  95
  96 ## 12:39
  97
  98 So it is quite possible that there is a kind of cross class loader with
  99 exceptions.
 100
 101 ## 12:44
 102
 103 The code is in a finally block, so an exception was thrown, it just has not
 104 been logged because it is lost, it is most likely however a TODO.
 105
 106 ## 12:48
 107
 108 It is possible that the exception wrapping my exception thrown by the Java
 109 compiler causes the issue.
 110
 111         at com.sun.tools.javac.main.Main.compile(Main.java:559)
 112
 113 So if I implement the code in the file manager which causes the unrolling
 114 may just fix it.
 115
 116 ## 20:05
 117
 118 I believe I know the cause. I just need to check if it happens with zero.
 119 Anyway, basically `UnknownError` which is part of the system classloader is
 120 being used. Also, the `JavaCompiler` is also part of the system classloader.
 121 Hairball being run though is in its own `URLClassLoader` initialized by the
 122 bootstrap. And the DPC is part of the URLCL. So JamVM at least appears to run
 123 the exception handlers in the method that threw the exception and using its
 124 class loader, when it should be using the classloader of the class the handling
 125 method is in. So I will see what Zero does. If it has this issue too, then I
 126 will probably want to avoid duplicating this behavior since it seems like a
 127 rather bad bug. And Zero does it too. I just hope fixing the exceptions due
 128 to the incomplete JavaFileManager using PackageContents can fix such things.
 129 So hopefully by implementing the stuff I can avoid it, this will be a rather
 130 big gotcha. I could make a test case for this actually, a small set of code
 131 which can duplicate the behavior.
 132