This is why I asked in my first posting whether it's a design bug or a performance issue... BTW: Did you run the benchmark with j<1000? On my MacBook Pro (C2D 2,2 Ghz, OS X) I got 7(,8) seconds with j<10 and 78 seconds with j<100.
Anyway... I really think that ReadableVector?f should be used instead of Vector?f wherever possible. So I think Elias' idea of making ReadableVector?f an abstract class would solve the problem. The fields may be defined protected, so the static methods could directly access the fields, but they are not visible from outside the class hierarchy.
Luckily, the Vector classes are not derived from each other, so we do not run into problems. IMHO, the following modifications are to be made (R = ReadableVector, V = Vector, W = WriteableVector, R/V/W4 omitted here):
interface Vector -- was class
interface W2 extends Vector
interface W3 extends W2
abstract class R extends Vector -- was interface
abstract class R2 extends R
abstract class R3 extends R2
class V2 extends R2 implements W2 -- was: extends V ...
class V3 extends R3 implements W3 -- was: extends V ...
This way, V2 .. V4 can access the fields x, y, z, w directly, from outside the class hierarchy final getters can be used.
The Vector class has gone, method length() is to be implemented in R (where it belongs since it's a read only method).
normalise() has to be declared in the interface now and has to be implemented in V2, V3, and V4 (which is the only trade-off here).
The results returned by "instance of" are not changed except W is now an instance of V (which seems ok since V becomes a kind of W0 interface). Could this cause problems?
The good thing is that V3 is not an instance of V2 in the current version. So we do not run into problems here.
If you do not object I can implement this in the next days and provide another patch here, too.
Jens