> Would a prototype (for example starting with char[]) be useful for debating if the API bar could be met?
Not by itself, but metrics from it might. If the tradeoff threshold for searching an unsorted array multiple times was high enough compared to sorting then searching that array multiple times, then that might sway opinions. Sadly, what you are trying to do is extremely well explored territory, which is why Chen and others are telling you this is not going to work out. We have a VERY good idea of what the answer will be -- the inflection point where sorting an array beforehand starts to outperform searching it unsorted is embarrassingly low, to the point where it makes no sense to even include the API in the first place. It's extremely unlikely that the answer has changed since most of us checked, but by all means, run the numbers and see what you get. At the end of the day, evidence born from testing something out is the strongest argument you can make. It's just extremely unlikely that the evidence will work in your favor. On Fri, Apr 10, 2026 at 4:04 PM Arnav Somaghatta < [email protected]> wrote: > 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 >
