How about this as a proposed solution to avoid
UnsupportedOperationException:
1. Renamed the internal ArrayList to ArrayWrappingList
2. Override add() in ArrayWrappingList and make it deprecated to warn
people from using it.
On Fri, Nov 18, 2022 at 6:23 PM Ethan McCue <et...@mccue.dev> wrote:
> I think there is potentially actionable feedback in that the exception
> thrown when users bump into this limitation kinda sucks
>
> jshell> Arrays.asList(1, 2, 3).add(4);
> | Exception java.lang.UnsupportedOperationException
> | at AbstractList.add (AbstractList.java:155)
> | at AbstractList.add (AbstractList.java:113)
> | at (#8:1)
>
> jshell> try { Arrays.asList(1, 2, 3).add(4);} catch (Exception e) {
> System.out.println(e.getMessage());}
> null
>
> I think there would be value in overriding "add" and other such operations
> to provide enough context for users to *understand* that
> * they did an unsupported operation
> * the list given by `Arrays.asList` was the cause
>
> If I had to guess, that's the core of the frustration. The process to get
> from "not understanding what went wrong" -> "understanding what went wrong"
> -> "knowing how to fix it" is high.
>
> The design problem is how much context can be conveyed in an exception
> message/stack trace.
>
> There is a similar conversation to be had for the collections returned by
> List.of() and similar.
>
> jshell> List.of().add(1)
> | Exception java.lang.UnsupportedOperationException
> | at ImmutableCollections.uoe (ImmutableCollections.java:142)
> | at ImmutableCollections$AbstractImmutableCollection.add
> (ImmutableCollections.java:147)
> | at (#6:1)
>
> jshell> try { List.of(1, 2, 3).add(4);} catch (Exception e) {
> System.out.println(e.getMessage());}
> null
>
> There is a clue in the stack trace here though for List.of() with the
> "ImmutableCollections" calls. Maybe if we took two moves
>
> 1. Renamed the internal ArrayList to something like ArrayWrappingList
> 2. Overrode add
>
> then the stack trace could be enough (or better than the status quo)
>
> jshell> Arrays.asList(1, 2, 3).add(4);
> | Exception java.lang.UnsupportedOperationException
> | at ArrayWrappingList.add (ArrayWrappingList.java:155)
> | at ArrayWrappingList.add (ArrayWrappingList.java:113)
> | at (#8:1)
>
> On Fri, Nov 18, 2022 at 12:14 PM Andreas Røsdal <andreas.ros...@gmail.com>
> wrote:
>
>> `new ArrayList<>(Arrays.asList(array))` is quite complex syntax to
>> convert an array to an java.util.ArrayList,
>> so a suggestion could be to add a new method to Arrays to convert an
>> array to a normal java.util.ArrayList which is modifiable.
>>
>> Are there any low-hanging-fruit issues in core-libs-dev in
>> bugs.openjdk.org that you are aware of that
>> you would like me to help you implement?
>>
>> Thanks for considering my request.
>>
>> Regards,
>> Andreas
>>
>>
>>
>>
>> On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs <daniel.fu...@oracle.com>
>> wrote:
>>
>>> Hi Andreas,
>>>
>>> First of all, congratulations for seeking advice before working on
>>> a PR. This is exactly how first contributions should start. Thank
>>> you for that!
>>>
>>> Given the area in which you intended to work however, `core-libs-dev`
>>> might have been a better list than `discuss` to start from.
>>>
>>> With regard to the meat of the issue however, and as noted by Ethan,
>>> Arrays.asList() behaves as intended, and changing that would be a
>>> major incompatible change, as many users of the API expect the list
>>> returned by Arrays.asList to be immutable (and depend on it).
>>> It is not possible nor desirable to change that.
>>>
>>> As for your observation, I believe that:
>>>
>>> `new ArrayList<>(Arrays.asList(array))`
>>>
>>> will get you what you want.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 18/11/2022 16:29, Andreas Røsdal wrote:
>>> > Yes, the exception comes when adding objects to the returned list. So
>>> I
>>> > would like a convenient way to use Arrays to convert an array to a
>>> > normal modifiable java.util.ArrayList, instead of this AbstractList.
>>> >
>>> >
>>> > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue <et...@mccue.dev
>>> > <mailto:et...@mccue.dev>> wrote:
>>> >
>>> > What situation were you encountering the exception? Was it when
>>> > trying to add to the returned list?
>>> >
>>> > If so, that's expected. Arrays.asList only wraps an underlying
>>> > array, it can't grow it. By that measure List.of() is even more
>>> > unintuitive because you can't set anything.
>>> >
>>> > On Fri, Nov 18, 2022, 11:06 AM Andreas Røsdal
>>> > <andreas.ros...@gmail.com <mailto:andreas.ros...@gmail.com>>
>>> wrote:
>>> >
>>> > Hello!
>>> >
>>> > I am an aspiring JDK contributor, having used Java in my work
>>> as
>>> > a developer.
>>> >
>>> > I was recently surprised by an Exception thrown when using the
>>> > java.util.Arrays.asList() method
>>> > so I would like to propose some improvements to this API. In
>>> > particular:
>>> > - When using java.util.Arrays.asList() then AbstractList is
>>> > throwing UnsupportedOperationException which is not
>>> > user-friendly or intuitive.
>>> > - java.util.Arrays.asList() returning a private class called
>>> > ArrayList, which is not the usual java.util.ArrayList, so it's
>>> > not user-friendly or intuitive.
>>> >
>>> > Since this would be my first contribution to the JDK, and the
>>> > goal is to complete the contribution with accepted pull request
>>> > and get the Arrays API improved, what would the first step to
>>> > making this first improvement to the JDK be?
>>> >
>>> > I would also like to share a link to an open source project
>>> I've
>>> > been working on:
>>> > https://github.com/fciv-net/fciv-net
>>> > <https://github.com/fciv-net/fciv-net>
>>> >
>>> > Thank you!
>>> >
>>> > Regards,
>>> > Andreas R.
>>> >
>>>
>>>
