Re: efficient vector math...

sorry if I am missing something obvious here, but I am hoping for
suggestions on a relatively efficient general-purpose way to handle
vector math and similar (in the sense of geometric vectors...).

I will likely be writing any code myself, so the request is for ideas
for a general design.

this is for a personal project (most of the rest of the project uses C,
but this will be for the Java part of the project). Java isn't really my
main language FWIW...

purposes and requirements:
performance should be good, and interface should also be nice (if
possible);
the app will be soft real-time on a custom JVM (JavaME style), and the
GC is slow and so avoiding GC (by minimizing garbage) is preferable (so
user will not experience stalls);
it doesn't need to deal with arbitrary N-sized vectors, only 2, 3, and 4
element vectors (XYZW), and also Quaternions;
likely vector size and usage will be considered as part of the type (a
Vec2 is not a Vec3 which is not a Vec4 which is not a Quat);
the vectors will potentially be recalculated frequently and in large
numbers;
...

so, a few possibilities:

A, immutable vectors:
pros: clean interface, supports merging and sharing vectors, ...
cons: many vectors may be created, likely creating lots of garbage.

B, mutable vectors:
pros: likely to reduce garbage (most recalculation can reuse existing
vectors);
cons: vectors can't be shared (since they may change without warning),
and the interface is more awkward (vector values are copied, meaning
vectors need to be provided to use for storing temporary values, ...).

C, supporting both (as different types):
pros: can mix and match as needed;
cons: 2x or 3x as many types (mutable and immutable versions of each
size, 3x if both versions are subclasses of a common abstract type),
more awkward class names to distinguish them, more methods, ...

D, supporting both (as different operations on the same type):
pros: allows mixing and matching use-patterns (general);
cons: use-case ambiguity (need to infer intended use from context).