Suggestion: A "record"-like Construct to Model Stateless Behavior in Java

[david Grajales]

Hi Amber Team.

The following is not "a solution" it's more like an idea or suggestion to
illustrate the core idea and intention based on experience, the core idea
is "java should have a convenient construct that is the equivalent of
records but for modeling behavior only. so please take the following just
as a mean for explanation.

The more I use records and learn about DOP (Data-Oriented Programming), the
more I find myself using utility classes to separate data modeling from
behavior, and to enforce immutability by creating both immutable data
structures and stateless static methods that manage the data. For example,
let's say we have a User record whose personal data is retrieved from a
database or any other entry point, with some data encrypted in a details
field. The utility class to decrypt and obtain the UserDetails for business
logic would look like this:


public record User(

    String email,

    String password,

    String encryptedDetails

) {}


public record UserDetails(

    String phone,

    String idDocument,

    String name

) {}


public final class EncryptionUtilityClass {

    private static final String key;

    public static final String value = "foo";

    private static final Gson gson = new Gson; // or any other
deserialization library


    static {

        key = getConfigurationKey();

    }


    private EncryptionUtilityClass() {}


    private static String getConfigurationKey() {

        return "keyFromConfigFile";

    }


    public static UserDetails decryptUserDetails(String details) {

        String data =  EncryptionLibraryClass.decrypt(details, key);

        return gson.fromJson(data, UserDetails.class);

    }


    public static String encryptUserDetails(UserDetails userDetails) {

        return EncryptionLibraryClass.encrypt(gson.toJson(userDetails),
key);

    }

}


This is a very common pattern to create utility classes that are meant to
contain only constant values and static methods (such as the Math class in
Java SE):

   1.

   Define a final class.
   2.

   Declare a private constructor to prevent instantiation.
   3.

   Expose only static methods and optionally static final constants
   (possibly initialized in a static block).

This pattern is verbose and requires the programmer to be aware of it as it
lacks the semantics to clearly express the class’s intention: to serve only
as a namespace for stateless functions.

Much like how record was introduced to model immutable data more
expressively and concisely, it would be valuable to introduce a dedicated
construct that semantically declares a class as a stateless, behavioral
container—a "function-only" namespace, with no instances or mutable state.

Such a construct could implicitly provide:

   -

   The class being final
   -

   All methods being static
   -

   Only one constructor, implicitly private
   -

   All fields being static final, requiring initialization via assignment
   or static blocks
   -

   Disallowance of instance-level fields or methods

This would improve not only readability and clarity of intent but could
also enable the compiler and JVM to optimize the generated code more
directly by emitting invokestatic calls directly, avoiding later
optimization passes, and supporting aggressive inlining and constant
folding where possible.

A keyword or construct name could be namespace, as it aligns with the idea
of a purely functions and constants grouping. Alternatives might
include utility
class or allowing outer static classes.

Here is how an hypothetical namespace construct could look like:

public namespace EncryptionUtilities {  // alternative public utility
class. No need for final modifier

    private String key; //No need for static final fields, implicitly
assumed as such

    public String value = "foo"; // since fields are strictly initialized
and no instances are allowed one can pass public fields directly and assume
these will always be in a correct state

    private  Gson gson = new Gson;


    static {

        key = getConfigurationKey();

    }


    // No private constructor requried or even allowed


    private String getConfigurationKey() { // No need for static modifier
on methods either public or private

        return "keyFromConfigFile";

    }


    UserDetails decryptUserDetails(String details) {

         String data =  EncryptionLibraryClass.decrypt(details, key);

        return gson.fromJson(data, UserDetails.class);

    }


    String encryptUserDetails(UserDetails userDetails) {

        return EncryptionLibraryClass.encrypt(gson.toJson(userDetails),
key);

    }

}

Such feature would benefit a wide range of use cases—helper libraries
(encryption, validation, logging, etc), stateless DSLs, functional-style
code, immutable-style APIs, etc.—not only for conciseness, but more
importantly, for providing clearer semantics to both developers about
intention and the JVM for enable optimization at compilation time.

Thank you for your continued work on improving the Java language. I have
been using records and DOP in both my personal projects and prod; this
suggestion is heavily inspired by this experience. I hope this
insight helps.

Best regards and always yours.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250504/18d2c060/attachment-0001.htm>