Why is the Vector API still an incubating module, what does that mean for using it, and how does it relate to Project Valhalla?

## What 'incubator module' means An **incubator module** (defined by **JEP 11**) is an official channel for shipping **non-final APIs and tools** so the community can use them and give feedback *before* they are committed to as permanent. Key consequences: - The module name and package live under **`jdk.incubator.*`** (here `jdk.incubator.vector`). - The API is **not on the module path by default**: you must opt in with **`--add-modules jdk.incubator.vector`** at both compile time and run time. Compilers emit a warning that you are using an incubating module. - **The API can change or be removed** between releases with no backwards-compatibility guarantee. Code written against one JDK may not compile or behave identically on the next. This is different from a **preview feature** (which is a *language/JVM* feature gated by `--enable-preview`); incubator modules are *library* APIs. Both signal 'not final yet.' ## History The Vector API was introduced as an incubator in **Java 16 (JEP 338)** and has been **re-incubated in essentially every feature release since** (17, 18, 19, ... continuing into the 21+ era). Re-incubation each release is the mechanism by which an unfinished API keeps shipping while still being officially non-final. ## Why it has not gone final: Project Valhalla **Project Valhalla** is the long-running OpenJDK effort to add **value classes / primitive classes** — objects that have no identity, can be **flattened** into their container, and live on the stack or inline in arrays with **no heap allocation or pointer indirection**. Why this matters for vectors: a `FloatVector` conceptually is just a bag of, say, 8 floats. Ideally it should live entirely in a CPU vector register with **zero heap allocation**. Today, because Java only has identity objects, a `Vector` is a regular heap object, and the JIT must do heavy work (**escape analysis / scalarization**) to eliminate the allocation and keep the data in registers. That mostly works in hot loops but is fragile and can fail. With Valhalla's value types, `Vector` could be declared a **value class** so it is *inherently* allocation-free and flattened, making performance robust and the API shape cleaner. **Finalizing the API now would bake in the identity-object design**, which Valhalla would then obsolete — forcing a breaking redesign. So the deliberate decision is to keep the Vector API **incubating until Valhalla provides the right foundation**. ## Practical implications for you - **Pin your JDK** or be ready to adjust code on upgrades; an incubating API is a moving target. - **Isolate** vectorized kernels behind a stable internal interface so a future API change touches one place. - **Provide a scalar fallback path** anyway (you often need one for non-vector hardware), which doubles as a safety net if the incubator API changes. - Don't ship it in a public library API surface you must keep stable for years without versioning awareness.