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

   1 # 2016/01/03
   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 ## 01:38
  10
  11 ## 01:54
  12
  13 Naming units for the most part.
  14
  15 ## 02:29
  16
  17 I believe for images, instead of creating a few thousand sprites with various
  18 rotations I will use voxels instead. Would require creation of a text based
  19 voxel format and editor of the data. This would probably be the simplest route
  20 at a slight cost of complexity. The rotations of the voxel data could even
  21 be rendered at run-time when a frame is needed.
  22
  23 ## 02:34
  24
  25 I suppose editing voxel images will be cube stacking (attaching a cube to
  26 another cube with a specific color) and specific splices. The other alternative
  27 to voxels is to actually use 3D models. Using 3D models would at least have it
  28 where I could have skeletons. However creation of models is a bit complex when
  29 it comes to editing them. Voxels would be easier to draw, however 3D models
  30 would be more universal. Pre-existing 3D editing tools are a pain to use though
  31 due to the varying differences and explicit requirement of things.
  32
  33 ## 15:33
  34
  35 It appears my desktop SSD is failing, thus I am going to resume work on my
  36 laptops. There is a laptop in plans by a group to make a PowerPC laptop. This
  37 would be rather interesting.
  38
  39 ## 17:51
  40
  41 I can probably also split the first Java library, but before I do that I must
  42 determine the interdependencies of the stuff to figure out how to split the
  43 packages. So I suppose I should generate a DOT of the imports declared in
  44 packages and such.
  45
  46 ## 18:16
  47
  48 Looking at the graph, I can split out...
  49
  50  * javax.sscript - Nothing depends on this.
  51  * java.util.function - This is only depended on.
  52
  53 ## 18:26
  54
  55 Well actually, I can explot the boot-built stuff. Since the host will have to
  56 be a Java 8 system, I can just move function into its own project and then have
  57 it not be boot built. However, the compiler detects when there is a name
  58 collision between stuff that is compiled and stuff that is in the classpath.
  59 Actually forget that, I had just forgotten `package` in my small class. So yes
  60 I can exploit this fact.
  61
  62 ## 18:47
  63
  64 Figured out how the `javax.security.auth.login` is used. That code is basically
  65 just an authenticator. It does not actually do any authentic work. What it can
  66 be used for though is say a login screen to start a shell. It can basically run
  67 a user authentication setup to determine if a password is valid or not (or
  68 request a password) before a login is actually made.
  69
  70 ## 18:59
  71
  72 The compact2 profile can also be split around. Although the compact2 will be
  73 easier to split, it is essentially in 3 pieces: RMI, SQL, and XML/W3C.
  74
  75 ## 19:20
  76
  77 I can also continue the split on compact3. I can also work on splitting the
  78 complete remaining API (compact4).
  79
  80 ## 19:24
  81
  82 I believe I will start with compact4 first since that contains stuff such as
  83 Swing and AWT.
  84
  85 ## 19:29
  86
  87 ImageIO depends on AWT. However, for Swing, these three are a concern:
  88
  89         java__awt -> javax__swing__text;
  90         java__awt__im__spi -> javax__swing;
  91         javax__accessibility -> javax__swing__text;
  92
  93 So I should see how dependent `javax.swing.text` is. And that depends on
  94 everything. So far then, awt, swing, accessibility, and print must be together
  95 in a gui subpackage.
  96
  97  * `javax.sound` is alone _sound_.
  98  * `java.beans` is alone as _beans_.
  99  * `javax.activation` depends on _gui_, called _activation_.
 100  * `javax.xml` depends on _activation_, called _xml_.
 101  * `javax.activity` is alone as _activity_.
 102  * `javax.annotation` is alone as _annotation_.
 103  * `javax.jws` is alone as _jws_, it only contains annotations.
 104  * `javax.print` goes with _gui_.
 105  * `javax.rmi` is alone as _rmi_.
 106  * `javax.rmi.corba` goes with _omg_ and depends on _rmi_.
 107  * `org.omg` is alone as _omg_.
 108
 109 So this is much more complex.
 110
 111 ## 22:46
 112
 113 Actually beans are part of the GUI system.
 114
 115 ## 22:51
 116
 117 The default provided PLAFs can also go into their own packages also.
 118
 119 ## 23:28
 120
 121 And now to finally split compact3.
 122
 123 ## 23:49
 124
 125 The preferences API looks rather interesting and I will most likely use that
 126 for my operating system. To think of it, due to the splits I have made of the
 127 code I can have other programs use it without requiring the entire compact3
 128 profile to be pulled in. This is exceptionally nice.
 129