Hello Chen,
Thank you for clarifying the API surface concern. I agree that the bar for
additions to Arrays should remain high.
The reason I still think this may be worth considering is that the
repeated manual loop appears frequently for small unsorted primitive
arrays, and a dedicated API would provide both readability and also a very
clear optimization hook for future implementations, including vectorized
fast paths where appropriate.
I don't want to unnecessarily expand Arrays, but I want to explore whether
this specific operation is common and fundamental enough to justify a
standard library entry point.
Markus’s earlier point about possible optimization opportunities for
unsorted primitive arrays especially made me think more that this may be a
direction that is worth validating a little more.
Would a prototype (for example starting with char[]) be useful for
debating if the API bar could be met?
Regards,
Arnav
On Apr 10, 2026, at 3:55 PM, Chen Liang <[email protected]> wrote:
Hello all,
I still don't think you should add these APIs.
This linear search is easily written by users.
As I said again, you shouldn't use a linear array for passing such data
around. This usually represents a failure in program structure design.
Vectorization can be done with the Vector API.
Arrays is not the home of a million garbage APIs. If everyone says "oh I
have a proposal" and add something, we can see this class blow up really
quickly.
So there is a bar for API additions.
This "contains" proposal clearly doesn't meet that bar, as it can be
replaced by more high-level APIs like sort+binarySearch, or some sort of
String KMP algorithm applied onto arrays.
Regards,
Chen Liang
From: Arnav Somaghatta <[email protected]>
Sent: Friday, April 10, 2026 5:45 AM
To: Markus KARG <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [External] : Proposal for primitive arrays
Hello all,
Thank you all for the feedback so far, and Markus especially for the
helpful perspective on the potential optimization and vectorization
opportunities for unsorted primitive array searches.
I have now submitted my OCA form as well and waiting for it to get
approved.
Based on the discussion so far, would it make sense for me to begin
working on an initial prototype patch (starting with the char[] overload
and its tests) so the API shape and implementation can be reviewed better?
And Markus, if this direction still seems aligned, would you be
comfortable acting as sponsor/reviewer for an initial contribution?
Regards,
Arnav
On Apr 6, 2026, at 6:00 AM, Markus KARG <[email protected]>
wrote:
Chen,
how does this explain that the propopsal "is not good"?
It is not on us to decide what others do with the tools we provide, as
long as we DO provide them. IF people are using primitive arrays, and IF
they need to search them in an UNSORTED fashion, Arnav's proposed API would
allows us to apply vectorization. Hence, the result COULD be multiple times
faster than custom search loops. As long as primitive arrays DO exist, I
would rather say, his proposal "is good".
-Markus
Am 06.04.2026 um 02:40 schrieb Chen Liang:
Hello, I don't think this is a good proposal.
Nowadays, primitive arrays are used as an efficient storage format,
much more compact than reference arrays. However, they all suffer from the
mutability issue as all the arrays: when you pass arrays across trust
boundaries, you should always sanitize the input arrays and output arrays.
In this sanitization process, we usually can convert these arrays to more
efficient formats, such as performing a Arrays.sort call, and the
subsequent search can be a Arrays.binarySearch(a, key) >= 0 call.
Regards,
Chen Liang
________________________________
From: Arnav Somaghatta <[email protected]>
Sent: Sunday, April 5, 2026 9:58 AM
To: [email protected] <[email protected]>
Subject: [External] : Proposal for primitive arrays
Hello,
My name is Arnav, and I am a 14-year-old developer who is interested
in contributing to the OpenJDK. I would like to propose adding a set of
"contains" methods to the java.util.Arrays class.
Currently, to check if a primitive array (like char or int) contains
a specific value needs a large manual for loop, converting to a List, or
using a very complicated Stream pipeline.
My idea proposes adding a series of static "contains" methods for all
8 primitive types to java.util.Arrays
public static boolean contains(char[] a, char key)
public static boolean contains(int[] a, int key)
public static boolean contains(byte[] a, byte key)
public static boolean contains(short[] a, short key)
public static boolean contains(long[] a, long key)
public static boolean contains(float[] a, float key)
public static boolean contains(double[] a, double key)
public static boolean contains(boolean[] a, boolean key)
Why should you consider this proposal?
Arrays.contains(myChars, 'a') is much more readable than workarounds
like a for loop.
For newer Java learners, not having a "contains" method on arrays is
very confusing when you compare it to other languages like Python.
If this proposal is viewed favorably, I am willing to make all of the
8 primitive overloads and any of the corresponding unit tests. I am also
looking for a sponsor to help me navigate the OCA process for minors and
guide me through the technical process of pushing these changes.
I look forward to your feedback on whether this is a direction the
Core Libs group would support. Thank you so much for considering my idea
and reading through this email, your support means a lot to me!
Thank you,
Arnav
