Thoughts on Array Initialization in JavaONE 2025

[david Grajales]

Dear Amber developers,

I recently watched the JavaONE 2025 session titled *“A New Model for Java
Object Initialization”* and was particularly intrigued by the proposed
improvements to array initialization.

https://www.youtube.com/watch?v=XtvR4kqK8lo


I strongly agree that Java needs better mechanisms for initializing data
structures in a concise, expressive, and stricter manner—similar in spirit
to Python’s list comprehensions and aligned with Strict initialization,
required for Valhalla. Such constructs can help avoid subtle bugs and the
presence of unintended null values. However, I remain skeptical about the
decision to focus this new model exclusively around arrays.

As has been discussed over the past few months, arrays are not ideal as a
default abstraction, especially for students or in enterprise applications.
Arrays are a low-level construct with several limitations:

   -

   They do not integrate well with generics.
   -

   They are of fixed size.
   -

   They lack methods and flexibility.
   -

   They are syntactically and semantically inconsistent with the rest of
   the Java Collections Framework.

In many ways, arrays are a legacy feature inherited from C/C++—much like
the original switch statement—that carry forward certain limitations that
Java has otherwise worked hard to overcome.

Given these issues, Why not just create an small API that facilitates the
creation of the most used data structures with strict initialization?

For example:


void main(){


    // toArray

    var array = StrictCollections.toArray(String.class, 5, i -> "Item-" +
i);

    IO.println("Array: " + Arrays.toString(array));


    // toList

    var list = StrictCollections.toList(5, i -> "List-" + i);

    IO.println("List: " + list);


    // toSet

    var set = StrictCollections.toSet(5, i -> "Set-" + (i % 3));

    IO.println("Set: " + set);



    var map = StrictCollections.toMap(

        5,

        i -> "Key-" + i,

        i -> i * 100

    );

    IO.println("Map: " + map);




}



public static class StrictCollections {


    public static <T> T[] toArray(Class<T> clazz, int size, IntFunction<T>
function) {

        @SuppressWarnings("unchecked")

        T[] array = (T[]) Array.newInstance(clazz, size); // This could be
a frozen array once these are ready

        for (int i = 0; i < size; i++) {

            array[i] = function.apply(i);

        }

        return array;

    }


    public static <T> ArrayList<T> toList(int size, IntFunction<T>
function) {

        var list = new ArrayList<T>(size);

        for (int i = 0; i < size; i++) {

            list.add(function.apply(i));

        }

        return list;

    }


    public static <T> HashSet<T> toSet(int size, IntFunction<T> function) {

        List<T> list = new ArrayList<>(size);

        for (int i = 0; i < size; i++) {

            list.add(function.apply(i));

        }

        return new HashSet<>(list);

    }


    public static <K, V> HashMap<K, V> toMap(int size, IntFunction<K>
kFunction, IntFunction<V> vFunction) {

        HashMap<K, V> map = new HashMap<>(size);

        for (int i = 0; i < size; i++) {

            map.put(kFunction.apply(i), vFunction.apply(i));

        }

        return map;

    }

}

While this is admittedly a rough sketch developed in just a few minutes, I
believe a similar—much more thoroughly designed—approach could provide much
greater flexibility with far less complexity than introducing a dedicated
array-specific feature. It would also extend naturally to a broader range
of use cases --Such as being able to be combined with the Stream API in a
much more ergonomic way--. Furthermore, as value classes and parametric JVM
start to make it into the language and the JVM, the advantages of arrays
and primitive types will diminish further. In that context, arrays will
become even less compelling in the future.

If Java is to introduce a safe, expressive, and idiomatic strict
initialization literal for data structures, I would argue it should
primarily support List, Set, and Map—especially Map, which remains one of
the least ergonomic structures to initialize in the language today,
particularly when compared to alternatives in Dart, Python, or even
JavaScript objects. Data structures that are much more used.


Thank you so much for all your work and always yours
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250726/263f42b8/attachment.htm>