v0.4.6

What's Changed

• Simplified the artifact naming in the CI pipeline.
  • The uploaded artifact is now consistently named tinytools-jar.
  • The JAR file inside remains versioned correctly (e.g., tinytools-0.4.6.jar).

This change ensures a more predictable workflow for artifact management.

v0.4.5

What's Changed

• Updated the project version to 0.4.5 in pom.xml.

This release ensures the correct versioning across the project and includes the updated JAR file. Future releases will be more carefully managed.

v0.4.4

What's Changed

• Fixed the artifact naming in the GitHub Actions pipeline to include the project version from pom.xml.

v0.4.3

What's Changed

• Renamed the GitHub Actions pipeline to "Test and Package" for improved accuracy and clarity.

This change ensures the workflow name better reflects its functionality.

v0.4.2

What's Changed

• Added dynamic versioning to the GitHub Actions workflow for packaging JAR files.
  • The uploaded JAR artifact now includes the version from pom.xml (e.g., tinytools-0.4.2.jar).

This update improves automation and ensures version consistency across builds.

v0.4.1

What's Changed

• Added a GitHub Actions workflow for Continuous Integration (CI) using Maven.
• Removed the .idea directory from the repository to clean up project files.

---

These changes improve automation and maintainability for the project.

v0.4.0

This release enhances the robustness of the Late<T> and Memo<T> classes by introducing stricter null value handling, improving their reliability and usability. Additionally, comprehensive tests ensure 100% coverage, and performance profiling confirms their efficiency under concurrent conditions.

---

What's Changed?

Late<T> and Memo<T>: Enforcing Non-Null Values

To enhance safety and prevent ambiguities, both Late<T> and Memo<T> now enforce that:

• null values are not allowed in set(T value), setIfAbsent(T value), and resetAndSet(T value).
• Attempts to set null will result in a clear and explicit NullPointerException.

This update ensures that these classes are easier to use and integrate into projects that require strict non-null guarantees.

---

Key Features of Late<T>

• Single-thread-safe initialization using set(T value).
• Access to the initialized value using get().
• Initialization state checking with isInitialized().

Key Features of Memo<T>

• Flexible initialization with set(T value) or setIfAbsent(T value).
• Ability to reinitialize safely using resetAndSet(T value).
• Convenient default-value retrieval with getOrElse(T defaultValue).

---

Testing and Performance

• 100% Test Coverage: Comprehensive unit tests validate all methods and edge cases, ensuring correctness.
• Efficient Performance: Profiling shows an average execution time of ~6ms for Late<T>'s set method under concurrent conditions across 1000 iterations.

---

Looking Ahead

This release strengthens the reliability of Late<T> and Memo<T>. These changes set the stage for further enhancements, including potential extensions for additional initialization strategies or lazy-loading capabilities.

Your feedback and contributions are always welcome! 😊

v0.3.0

This release introduces a renaming of the Lazy<T> class to Late<T> and establishes a clear distinction for future functionality. The new Late<T> class focuses on explicit, thread-safe initialization, while the upcoming Lazy<T> class will support on-demand initialization using Supplier<T>.

---

What's Changed?

Late<T>: Thread-Safe, Explicit Initialization

The previously named Lazy<T> has been renamed to Late<T> to better align with its behavior. The Late<T> class is designed for cases where:

• A value must be initialized exactly once, explicitly.
• The initialization is deferred until the value is set manually.
• Safe access to the value is required across threads.

Planned: Lazy<T> for On-Demand Initialization

A new Lazy<T> class is planned for future releases, which will enable on-demand initialization using a Supplier<T>. This functionality will complement Late<T> by providing automatic initialization when the value is first accessed.

---

Key Features of Late<T>

• Single initialization using set(T value).
• Thread-safe access to the initialized value using get().
• Check initialization state using isInitialized().

---

Looking Ahead

The Late<T> class now sets a strong foundation for managing explicit initialization. The upcoming Lazy<T> class will provide more flexibility with Supplier<T>-based initialization, enabling true lazy-loading functionality. Stay tuned for future updates!

Your feedback and contributions are always welcome!

v0.2.0

I am excited to announce the first thread-safe implementation of the following utilities designed to simplify and enhance concurrency in your projects:

Features:

• Lazy<T>:

  • A thread-safe utility for lazy initialization.
  • Ensures that a value is initialized only once and provides efficient, synchronized access for subsequent reads.
  • Ideal for scenarios where expensive computations or resource-heavy initializations need to be deferred until the first use.

• Memo<T>:

  • A thread-safe memoization utility.
  • Enables single-use or conditional initialization of a value with safe, synchronized access.
  • Supports reinitialization with methods like reset() and resetAndSet(T value) for greater flexibility.
  • Includes state-checking with isInitialized() to help manage and control the lifecycle of the memoized value.

Why This Matters:

These utilities are designed to help developers manage thread-safe initialization and reuse of values efficiently in multithreaded environments. They provide simple yet powerful tools for handling common concurrency patterns with minimal boilerplate.

Example Use Cases:

• Lazy<T>: Lazy-load configuration values, singleton instances, or heavy resources that are only required under certain conditions.
• Memo<T>: Store and safely update stateful values in applications that require controlled reinitialization or memoization.

---

Looking Ahead:

Future releases will continue to expand on this foundation with additional thread-safe utilities and performance optimizations.

I also plan on creating versions of these classes that work with the Supplier<T> type down the line, providing even more flexibility for deferred initialization and memoization.

Your feedback and suggestions are always welcome!