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
discussio
The problem is that would necessitate a new public class that is *only*
used as a return value. Since it would then come up with auto complete for
people searching for ArrayList, that's non trivial.
Deprecated also isn't the right concept. Mechanically it puts a line
through a method invocation, b
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 wrote:
> I think there is
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.a
`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
new ArrayList<>(Arrays.asList(theArray));
I'm not intending to be pithy - just this is one of the "known
deficiencies" of the collections framework. If you look hard enough you can
find some spitballing I did on how to address it in the core-libs mailing
list (which would be the place to go for th
