Dear org.lcsim developers,
I would like to share some comments about the API from a user point-of-view. I hope that the comments will become more detailed, once I actually use it:
The use of double[] for Vectors and Shapes
I don't think this is a good idea. While I appreciate that the description is in the javadoc, I strongly feel that it should be part of the API. For vectors, this might still be acceptable, while for shapes I find it absolutely necessary to have descriptive names. The mapping between index and name of the parameter is totally arbitrary and should therefore be avoided completely.
The API for the analysis should be as high-level as possible. I would therefore very much appreciate if classes for the vectors and shapes and track parameters could be added. No, they don't need Draw(), Rotate(), Pt() and Streamer components 
The Track class
I have some nitpicks with this class:
- There already is an accessor getReferencePoint(), so accessors to the components are totally unnecessary and don't make the programmer's life easier at all.
- Same goes for momentum ad Px
- The boolean functions all (as far as I could tell) have a has- or is- prefix, which is how it should be. fitSuccess() is therefore a little inconsistent and not where I would look for this function if I was to learn the API.
- getTrackParameters() - see above
Status codes
The Java language was awarded such a nice enum class. Is there really a performance issue in using ints for status bits or types ?
/** Type of hit. Mapping of integer types to type names * through collection parameters "TrackerHitTypeNames" * and "TrackerHitTypeValues". */
This does not help me at all when I am coding, and I don't want to have a web browser open all the time to see what the type, status, flag, whatever, actually stands for. This is where I would like to take advantage of Code Completion.
org.lcsim.mc.fast.cluster.ronan
I disagree with the use of names that have no meaning outside of SLAC.
Thank you for your consideration
Jan