On 5/1/20 2:02 AM, dmytro sheyko wrote:
The checked, synchronized and unmodifiable wrappers in some cases store backing
collection in more than one fields.
Thus `UnmodifiableList` has
1. its own field `List list` and
2. `Collection c`, which it inherits from
`UnmodifiableCollection`.
Also `Un
Thank you, I got it. I have one more a bit unrelated question.
The checked, synchronized and unmodifiable wrappers in some cases store
backing collection in more than one fields.
Thus `UnmodifiableList` has
1. its own field `List list` and
2. `Collection c`, which it inherits from
`UnmodifiableCo
The general rule in the collections that wrappers and views don't divulge their
backing collections. The reason is fairly obvious for things like the checked
wrappers and unmodifiable wrappers, but it's equally important for various view
collections like those of Lists, Sets, and Maps. If there
Hi Stuart,
In general I agree with you regarding synchronized collections. But
nevertheless there is a lot of legacy code that still uses synchronized
wrappers. And sometimes synchronization is done on wrong lock object, which
leads to relatively rare but extremely hard to reproduce and troublesho
Hi Dmytro,
Callers of an API performing explicit synchronization, along with the
synchronized collections wrappers, have mostly fallen into disuse since the
introduction of the java.util.concurrent collections.
Multiple threads can either interact directly on a concurrent collection, or the
Background on this can be found here:
https://bugs.openjdk.java.net/browse/JDK-4335520
Jason
From: core-libs-dev on behalf of
dmytro sheyko
Sent: Wednesday, April 29, 2020 2:58 AM
To: core-libs-dev
Subject: Collections.synchronizedXXX() and internal
Hello,
Have you ever discussed to make field mutex in synchronized collections
accessible?
Javadoc for Collections#synchronizedSortedSet suggest to iterate collection
this way:
SortedSet s = Collections.synchronizedSortedSet(new TreeSet());
SortedSet s2 = s.headSet(foo);
...
synchron
