Task for an aspiring JDK contributor

[Andreas Røsdal]

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 <ethan at 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.rosdal at 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.fuchs at 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 <ethan at mccue.dev
>>> > <mailto:ethan at 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.rosdal at gmail.com <mailto:andreas.rosdal at 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.
>>> >
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20221118/c85092a3/attachment-0001.htm>