<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p class="gmail-">Hi Amber Team.</p><p class="gmail-">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.</p><div><br></div>
<p class="gmail-">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 <code>User</code> record whose personal data is retrieved from a database or any other entry point, with some data encrypted in a <code>details</code> field. The utility class to decrypt and obtain the <code>UserDetails</code> for business logic would look like this:</p><p class="gmail-"><br></p><p class="gmail-">public record User(</p><p class="gmail-">    String email,</p><p class="gmail-">    String password,</p><p class="gmail-">    String encryptedDetails</p><p class="gmail-">) {}</p><p class="gmail-"><br></p><p class="gmail-">public record UserDetails(</p><p class="gmail-">    String phone,</p><p class="gmail-">    String idDocument,</p><p class="gmail-">    String name</p><p class="gmail-">) {}</p><p class="gmail-"><br></p><p class="gmail-">public final class EncryptionUtilityClass {</p><p class="gmail-">    private static final String key;</p><p class="gmail-">    public static final String value = "foo";</p><p class="gmail-">    private static final Gson gson = new Gson; // or any other deserialization library</p><p class="gmail-"><br></p><p class="gmail-">    static {</p><p class="gmail-">        key = getConfigurationKey();</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    private EncryptionUtilityClass() {}</p><p class="gmail-"><br></p><p class="gmail-">    private static String getConfigurationKey() {</p><p class="gmail-">        return "keyFromConfigFile";</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    public static UserDetails decryptUserDetails(String details) {</p><p class="gmail-">        String data =  EncryptionLibraryClass.decrypt(details, key);</p><p class="gmail-">        return gson.fromJson(data, UserDetails.class);</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    public static String encryptUserDetails(UserDetails userDetails) {</p><p class="gmail-">        return EncryptionLibraryClass.encrypt(gson.toJson(userDetails), key);</p><p class="gmail-">    }</p><p class="gmail-">}</p><div><br></div><div><br></div><div><p class="gmail-">This is a very common pattern to create utility classes that are meant to contain only constant values and static methods (such as the <code>Math</code> class in Java SE):</p>
<ol>
<li class="gmail-">
<p class="gmail-">Define a final class.</p>
</li>
<li class="gmail-">
<p class="gmail-">Declare a private constructor to prevent instantiation.</p>
</li>
<li class="gmail-">
<p class="gmail-">Expose only static methods and optionally static final constants (possibly initialized in a static block).</p>
</li>
</ol>
<p class="gmail-">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.</p>
<p class="gmail-">Much like how <code>record</code> 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.</p>
<p class="gmail-">Such a construct could implicitly provide:</p>
<ul>
<li class="gmail-">
<p class="gmail-">The class being final</p>
</li>
<li class="gmail-">
<p class="gmail-">All methods being static</p>
</li>
<li class="gmail-">
<p class="gmail-">Only one constructor, implicitly private</p>
</li>
<li class="gmail-">
<p class="gmail-">All fields being static final, requiring initialization via assignment or static blocks</p>
</li>
<li class="gmail-">
<p class="gmail-">Disallowance of instance-level fields or methods</p>
</li>
</ul>
<p class="gmail-">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 <code>invokestatic</code> calls directly, avoiding later optimization passes, and supporting aggressive inlining and constant folding where possible.</p>
<p class="gmail-">A keyword or construct name could be <code>namespace</code>, as it aligns with the idea of a purely functions and constants grouping. Alternatives might include <code>utility class</code> or allowing outer static classes.</p>
<p class="gmail-">Here is how an hypothetical <code>namespace</code> construct could look like:</p><p class="gmail-">public namespace EncryptionUtilities {  // alternative public utility class. No need for final modifier</p><p class="gmail-">    private String key; //No need for static final fields, implicitly assumed as such</p><p class="gmail-">    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</p><p class="gmail-">    private  Gson gson = new Gson; </p><p class="gmail-"><br></p><p class="gmail-">    static {</p><p class="gmail-">        key = getConfigurationKey();</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    // No private constructor requried or even allowed</p><p class="gmail-"><br></p><p class="gmail-">    private String getConfigurationKey() { // No need for static modifier on methods either public or private</p><p class="gmail-">        return "keyFromConfigFile";</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    UserDetails decryptUserDetails(String details) {</p><p class="gmail-">         String data =  EncryptionLibraryClass.decrypt(details, key);</p><p class="gmail-">        return gson.fromJson(data, UserDetails.class);</p><p class="gmail-">    }</p><p class="gmail-"><br></p><p class="gmail-">    String encryptUserDetails(UserDetails userDetails) {</p><p class="gmail-">        return EncryptionLibraryClass.encrypt(gson.toJson(userDetails), key);</p><p class="gmail-">    }</p><p class="gmail-">}</p></div><div>
<p class="gmail-">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.</p>
<p class="gmail-">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.</p>
<p class="gmail-">Best regards and always yours.<br><br></p></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>