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
