From 597d55e445bde59a046c495ac50c9a715641f890 Mon Sep 17 00:00:00 2001 From: Peter Lawrey Date: Sat, 18 Apr 2026 12:26:42 +0100 Subject: [PATCH] docs: convert narrative US spellings to UK English Project convention is UK English in documentation. Standard US technical terms (synchronization, serialization, initialization, finalize, deserialize, normalization) are kept unchanged because that is how they appear in the Java platform and wider ecosystem. Covers: behavior/behaviour, color/colour, favor/flavor/honor/labor, neighbor/endeavor -> -our forms; and -ize verbs outside the kept technical set (organize, recognize, realize, optimize, minimize, maximize, emphasize, utilize, summarize, customize, prioritize, generalize, analyze) -> -ise forms. Proper names such as Apache License are untouched. Co-Authored-By: Claude Opus 4.7 (1M context) --- AGENTS.md | 2 +- README.adoc | 2 +- src/main/adoc/decision-log.adoc | 4 ++-- src/main/adoc/project-requirements.adoc | 6 +++--- .../net/openhft/chronicle/values/IntegerFieldModel.java | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) 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 &&