This class consists solely of static constants that describe lane-wise vector operations, plus nested interfaces which classify them. The static constants serve as tokens denoting specifically requested lane operations in vector expressions, such as the token ADD in w = v0.lanewise(ADD, v1).

The documentation for each individual operator token is very brief, giving a symbolic Java expression for the operation that the token requests. Those symbolic expressions use the following conventional elements:

• a, b, c — names of lane values
• Java operators like +, ?:, etc. — expression operators
• Java method names like max, sin, etc. — methods in standard classes like Math, Double, etc. Unqualified method names should be read as if in the context of a static import, and with resolution of overloading.
• bits(x) — a function call which produces the underlying bits of the value x. If x is a floating point value, this is either doubleToLongBits(x) or floatToIntBits(x). Otherwise, the value is just x.
• ESIZE — the size in bytes of the operand type
• EMASK — the bit mask of the operand type, where EMASK=(1<<(ESIZE*8))-1
• intVal, byteVal, etc. — the operand of a conversion, with the indicated type

Operations on floating point vectors

• Lane-wise vector operations that apply to floating point vectors follow the accuracy and monotonicity specifications of the equivalent Java operation or method mentioned in its documentation unless specified otherwise. If the vector element type is float and the Java operation or method only accepts and returns double values, then the scalar operation on each lane is adapted to cast operands and the result, specifically widening float operands to double operands and narrowing the double result to a float.
• Certain associative operations that apply to floating point vectors are not truly associative on the floating point lane values. Specifically, ADD and MUL used with cross-lane reduction operations, such as FloatVector#reduceLanes(Associative). The result of such an operation is a function both of the input values (vector and mask) as well as the order of the scalar operations applied to combine lane values. In such cases the order is intentionally not defined. This allows the JVM to generate optimal machine code for the underlying platform at runtime. If the platform supports a vector instruction to add or multiply all values in the vector, or if there is some other efficient machine code sequence, then the JVM has the option of generating this machine code. Otherwise, the default implementation is applied, which adds vector elements sequentially from beginning to end. For this reason, the result of such an operation may vary for the same input values.

Note that a particular operator token may apply to several different lane types. Thus, these tokens behave like overloaded operators or methods, not like type-specific method handles or lambdas. Also unlike method handles or lambdas, these operators do not possess operational semantics; they have no apply or invoke method. They are used only to request lane operations from vector objects, and cannot (by themselves) perform operations on individual lane values.