Hi,
I agree the exception message could be added to facilitate the
understanding and the resolution of UnsupportedOperationExceptions from
List implementations.
New issue: https://bugs.openjdk.org/browse/JDK-8297283
As to what should be included in the message, that will need more
discussion.
To the original point, in the case where the list should have particular
features or abilities, such as mutability or extensibility, the
developer should construct the list themselves or only use factory
methods such as Arrays.asList() that are specified to meet their
requirements. With all kinds of lists and other collections, there are
many different implementation features to choose from. Immutable lists
are very common and well supported by the libraries.
$.02, Roger
On 11/18/22 12:23 PM, Ethan McCue 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 <http://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.
>
