diff --git a/AGENTS.md b/AGENTS.md index de6b15514..7d17149fb 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -10,7 +10,7 @@ LLM-based agents can accelerate development only if they respect our house rules | Requirement | Rationale | |--------------|-----------| -| **British English** spelling (`organisation`, `licence`, *not* `organization`, `license`) except technical US spellings like `synchronized` | Keeps wording consistent with Chronicle's London HQ and existing docs. See the University of Oxford style guide for reference. | +| **British English** spelling (`organisation`, `licence`, *not* `organisation`, `license`) except technical US spellings like `synchronized` | Keeps wording consistent with Chronicle's London HQ and existing docs. See the University of Oxford style guide for reference. | | **ASCII-7 only** (code-points 0-127). Avoid smart quotes, non-breaking spaces and accented characters. | ASCII-7 survives every toolchain Chronicle uses, incl. low-latency binary wire formats that expect the 8th bit to be 0. | | If a symbol is not available in ASCII-7, use a textual form such as `micro-second`, `>=`, `:alpha:`, `✓`. This is the preferred approach and Unicode must not be inserted. | Extended or '8-bit ASCII' variants are *not* portable and are therefore disallowed. | diff --git a/README.adoc b/README.adoc index 48a3f45ee..f870df34e 100644 --- a/README.adoc +++ b/README.adoc @@ -289,7 +289,7 @@ It achieves this by generating efficient data accessors from Java interfaces. Chronicle-Values is designed to provide: * **High Performance & Low Latency:** Access and manipulate data with minimal overhead, crucial for systems where every microsecond counts. This is particularly true when using its "native" (off-heap) implementations. -* **Minimized GC Impact:** Through the use of off-heap 'flyweight' objects, which act as lightweight views onto raw byte data. This significantly reduces garbage collection pressure by avoiding the creation of numerous heap objects. +* **Minimised GC Impact:** Through the use of off-heap 'flyweight' objects, which act as lightweight views onto raw byte data. This significantly reduces garbage collection pressure by avoiding the creation of numerous heap objects. * **Type Safety:** Define your data structures using standard Java interfaces. This provides compile-time checking, clear API contracts, and reduces runtime errors. * **Developer Convenience:** The library automatically generates the necessary accessor boilerplate (getters, setters, etc.) based on your interface definition and intuitive annotations. This saves development time and reduces manual coding errors. * **"Zero-Deserialization" Access:** Read data directly from memory without the traditional cost of hydrating full heap objects, allowing for faster processing. diff --git a/src/main/adoc/decision-log.adoc b/src/main/adoc/decision-log.adoc index bad15bfa4..27d8828c0 100644 --- a/src/main/adoc/decision-log.adoc +++ b/src/main/adoc/decision-log.adoc @@ -10,14 +10,14 @@ The requirement tags referenced here originate from link:project-requirements.ad * Date: 2025-05-26 * Context: ** Need for a type-safe, efficient, and developer-friendly way to represent and manipulate data with well-defined, fixed-size schemas (e.g., financial messages, event payloads). -** Desire to minimize GC impact and integrate smoothly with other Chronicle libraries like Map and Queue. +** Desire to minimise GC impact and integrate smoothly with other Chronicle libraries like Map and Queue. ** Requirements: CV-FN-001, CV-FN-003, CV-FN-007, CV-FN-008, CV-NFP-011, CV-NFP-012, CV-UX-026. * Decision Statement: ** Chronicle Values *will be adopted* as the primary mechanism for modeling and accessing structured, fixed-size data, particularly when type safety, developer convenience, and integration with Chronicle Map/Queue are priorities. * **Alternatives Considered:** ** _Direct use of Chronicle Bytes for all structured data_: *** *Description:* Manually managing offsets and data interpretation within Chronicle Bytes buffers for all structured data. -*** *Pros:* Maximum control over memory layout; potentially the absolute lowest latency if hand-optimized perfectly. +*** *Pros:* Maximum control over memory layout; potentially the absolute lowest latency if hand-optimised perfectly. *** *Cons:* Higher development complexity; error-prone (offset miscalculations, type misinterpretations); poor type safety at compile time; more boilerplate code. ** _Using third-party serialization libraries (e.g., Protocol Buffers, Avro) on top of Chronicle Bytes_: *** *Description:* Employing external libraries for defining structures and serializing/deserializing them into/from Bytes buffers. diff --git a/src/main/adoc/project-requirements.adoc b/src/main/adoc/project-requirements.adoc index 8f78b72f7..8824082b9 100644 --- a/src/main/adoc/project-requirements.adoc +++ b/src/main/adoc/project-requirements.adoc @@ -31,7 +31,7 @@ The Nine-Box scheme covers `FN` for functional behaviour, `NF-P`, `NF-S` and `NF ** _Source:_ Core design goal of both Chronicle Bytes and Values. * *CV-NFP-010:* The system *must* support high throughput for data processing. ** _Source:_ Core design goal of both Chronicle Bytes and Values. -* *CV-NFP-011:* The system *must* minimize Garbage Collection (GC) impact by extensive use of off-heap memory for data storage. +* *CV-NFP-011:* The system *must* minimise Garbage Collection (GC) impact by extensive use of off-heap memory for data storage. ** _Source:_ Key feature of Chronicle Bytes and Chronicle Values flyweights. * *CV-NFP-012:* The system *must* provide "zero-deserialization" access for structured data where appropriate, avoiding hydration into heap objects for reads. ** _Source:_ Chronicle Values flyweights. @@ -39,7 +39,7 @@ The Nine-Box scheme covers `FN` for functional behaviour, `NF-P`, `NF-S` and `NF ** _Source:_ Fixed-layout nature of Chronicle Values; controlled access in Bytes. * *CV-NFP-014:* The system *must* support atomic operations for concurrent, lock-free programming paradigms. ** _Source:_ Chronicle Bytes (e.g., compareAndSwapInt) and Chronicle Values (generated atomic methods). -* *CV-NFP-015:* The system *must* allow for efficient memory alignment of data fields to optimize access, especially for atomic operations and cache performance. +* *CV-NFP-015:* The system *must* allow for efficient memory alignment of data fields to optimise access, especially for atomic operations and cache performance. ** _Source:_ Chronicle Values (@Align annotation); manual management in Chronicle Bytes. == Non-Functional Requirements - Operability (NF-O) @@ -72,7 +72,7 @@ The Nine-Box scheme covers `FN` for functional behaviour, `NF-P`, `NF-S` and `NF == Operational / DevOps Concerns (OPS) -* *CV-OPS-024:* The project build system *must* be configured to support Java annotation processing if Chronicle Values is utilized. +* *CV-OPS-024:* The project build system *must* be configured to support Java annotation processing if Chronicle Values is utilised. ** _Source:_ Chronicle Values build process requirement. * *CV-OPS-025:* Strategies for managing schema evolution and data format compatibility across application versions *must* be defined and documented. ** _Source:_ Implied by analysis of schema evolution for Values and Bytes. diff --git a/src/main/java/net/openhft/chronicle/values/IntegerFieldModel.java b/src/main/java/net/openhft/chronicle/values/IntegerFieldModel.java index d7214d9eb..d3441bd70 100644 --- a/src/main/java/net/openhft/chronicle/values/IntegerFieldModel.java +++ b/src/main/java/net/openhft/chronicle/values/IntegerFieldModel.java @@ -343,7 +343,7 @@ private String genGet( // "Unsigned" value. This is a special case of the next next block, but treated // differently, because `readByte() & 0xFF` looks more familiar than `readByte() + 128`, - // also the first form is optimized on assembly level by HotSpot (unsigned treatment of + // also the first form is optimised on assembly level by HotSpot (unsigned treatment of // the value, no actual `& 0xFF` op), not sure about the second form. long readRange = readMax - readMin; if (range.min() == 0 &&