Thoughts on Array Initialization in JavaONE 2025

[david Grajales]

Hi Mr. Per Minborg Thanks for the advice, I had already watched the
presentation (excellent btw) but I haven't had the time to properly play
around with this new API. I promise I will give it a check ASAP.

Cheers.

El lun, 28 jul 2025 a la(s) 2:21 a.m., Per-Ake Minborg (
per-ake.minborg at oracle.com) escribió:

> Hi David,
>
> Unrelated to arrays but to your "StrictCollection" sketch, I'd like to
> draw Stable Values <https://openjdk.org/jeps/502> to your attention where
> similar constructs are available.
>
> For example:
>
> var list = StableValue.list(5, i -> "List-" + i)
>
> Such lists might additionally benefit from certain performance
> optimizations (such as constant folding). Here is a video
> <https://inside.java/2025/07/22/javaone-stablevalues/> where I explain
> stable values in detail.
>
>
> Best, Per Minborg
> ------------------------------
> *From:* amber-dev <amber-dev-retn at openjdk.org> on behalf of Remi Forax <
> forax at univ-mlv.fr>
> *Sent:* Sunday, July 27, 2025 6:08 PM
> *To:* Brian Goetz <brian.goetz at oracle.com>
> *Cc:* david Grajales <david.1993grajales at gmail.com>; amber-dev <
> amber-dev at openjdk.org>
> *Subject:* Re: Thoughts on Array Initialization in JavaONE 2025
>
>
>
> ------------------------------
>
> *From: *"Brian Goetz" <brian.goetz at oracle.com>
> *To: *"david Grajales" <david.1993grajales at gmail.com>, "amber-dev" <
> amber-dev at openjdk.org>
> *Sent: *Saturday, July 26, 2025 11:48:49 PM
> *Subject: *Re: Thoughts on Array Initialization in JavaONE 2025
>
> All of the points you raise that "arrays are not the abstraction you are
> looking for" are absolutely true -- and well understood. The goal of
> improving array creation is not to help arrays win market share away from
> collections.
>
> But there is a reason that the language has arrays, and that reason hasn't
> gone away.  Arrays are the bottom brick on which the tower of better data
> structures are built.  You can't have ArrayList or HashMap without arrays.
> Arrays are part of the language for a reason.  As we improve the language,
> sometimes arrays have to improve with it.  (For example, if you have a
> non-implicitly-constructible value class NVA (one who has no valid default
> value), and someone wants to create an array of NVA![n], allowing the
> existing "zero the memory" array creation expression to create it would
> undermine the integrity of the runtime by exposing objects that are not in
> a valid state as determined by their constructor.  So we can't allow that,
> which means we have to provide something else.)
>
> If we hadn't found the need to improve other aspects of initialization, we
> probably wouldn't have bothered to improve array initialization.  But
> because we are improving initialization more broadly, we have to do the
> whole job.  Not being able to create interesting arrays linguistically
> would forever look like a weird omission.
>
> Your suggestion -- "why not just" not improve array creation
> linguistically, and shunt any sort of exotic array creation to a privileged
> API -- leaves the user with little explanation for why the tower stands
> up.  The bottom brick is not there, instead replaced by some sort of magic
> that seems to hold up the brick above it.  While we expect relatively few
> programmers to program with arrays (ideally, just the guy who maintains
> ArrayList and HashMap, and the like), we should provide linguistic
> mechanisms for properly using core linguistic building blocks.
>
> I can imagine three implicit lines of thought for why you think such a
> low-level mechanism should be performed by a privileged library rather than
> a language feature:
>
>  - The easier we make it to use, the more people will use it, and you
> would like fewer people to use it (as would we.)  A scary-looking library
> will scare away more people than a pretty-looking language feature.
>  - Language features are expensive, more expensive than libraries, so by
> shunting this to a library, we preserve resources to focus on more
> important things.
>  - Array initialization appears to be competing for resources with
> features like collection literals, and you'd rather have the latter, so
> suggesting that we skip the former seems like it would bring the latter
> more quickly.
>
> These are appealing-sounding arguments, but they don't point to either
> usability wins or project-management wins.  Arrays are the right tool for
> some jobs.  Collections are the right tool for others (most others.)  But
> the way to encourage people to use the right tool is not to make the other
> tools harder to use.  (We too would like to have linguistic support for
> creating sets, lists, maps, etc, but that feature is not competing with
> arrays, its waiting for something else.)  Nor is the cost of a privileged
> array-construction API significantly cheaper than a language feature.
>
>
> I always flip-flop between thinking that arrays are redeemable and losing
> all hope about them :)
>
> I think that the solution to our problem is to use value classes, after
> all, a value class allows abstraction without the runtime cost, right, so
> why not eating our own dog food ?
>
> Why not using array wrapped into a value class that implements the List
> interface ?
>
> By example, here is a List that allows only to access to an element of the
> List only if it has been initialized first (using a watermark),
>
> value class WatermarkedList<E> implements List<E> {
>   E[] array;
>   int watermark;
>
>    // private constructor + static method
>
>   WatermarkedList<E> append(E element) {
>     array[watermark] = element;
>     return new WatermarkedList<>(array, watermark + 1);
>   }
>
>   E get(int index) {
>    Objects.checkIndex(index, watermark);
>     return array[index];
>   }
>
>   int size() { return watermark; }
>
>   WatermarkedList<E> copyOf(int newCapacity) { ... }
>
>   ...
> }
>
> Here the array can be initialized with zeroes (using a "JDK restricted"
> method) and a WatermarkedList is still safe to be used with element that
> are NVA.
>
> I think the JDK can define few of those lightweight Lists that can be used
> as primitive by anyone wanting to implement more complex data structures
> (ArrayList, HashMap, etc).
>
>
>
> Cheers,
> -Brian
>
>
>
> regards,
> Rémi
>
>
>
>
>
>
>
>
> On 7/26/2025 5:03 PM, david Grajales wrote:
>
> 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/20250728/194ea1f8/attachment-0001.htm>