1

I'm trying to make a method that modifies a incoming Collection or List. The problem is that I can't check if the Collection / List is an unmodifiable Collection / List. Sure I could just "try" to write to it with set and catch the exception. But I think we agreed that try catch is not a valid control flow tool. Is there something I'm missing? Any method that returns a boolean (modifiable or not) or an interface that signals modifiablity / unmodifiablity? I think there should be since the collection api is single typed (doesn't distinguish between modifiable and not by the type passed around). But when you want to write to a collection you get passed you can't be sure it's modifiable.

RedCrafter LP
  • 174
  • 1
  • 8
  • 1
    Primary motive behind Collections is to store and manipulate data, hence all collections are modifiable by default. Unless any specific class or field marked as `Final`. If you'd check methods for any collections such as List (`has add,remove, addAll`) etc, HashMap or HashSet ( `has put`) likewise and so on and so forth ! Are you trying to do something specific? You can mention the code snippets if so – Harsh Jun 22 '22 at 05:34
  • 1
    I dispute that '`try catch` is not a valid control flow tool'. It *is* a control flow tool, and *ergo* it is valid. Don't let crackpot theories determine how you write programming code. – user207421 Jun 22 '22 at 06:10
  • 1
    Why do you want to know this? If a collection handed to you is unmodifiable, yet you need to modify it, document this requirement and let it crash. – akarnokd Jun 22 '22 at 06:35
  • 3
    What exactly do you want to do after the hypothetical method told you that the collection is not modifiable despite you method requires it? The most natural thing would be to throw an exception when requirements are not met, so you’re back to square one. So why not let the exception go to the caller in the first place? – Holger Jun 22 '22 at 07:01

2 Answers2

7

But I think we agreed that try catch is not a valid control flow tool.

It is debatable. But lets not debate it.

Is there something I'm missing?

No.

[Is there] any method that returns a boolean (modifiable or not) or an interface that signals modifiablity / unmodifiablity?

No and No.

There is no standard API method or marker interface. (I guess you could implement your own ... but you would run into difficulties when using the standard collection implementation classes.)

The best you could do is to do some messy tests for specific implementation classes that are known to be modifiable or non-modifiable. But that approach has problems too:

  • You can't just test for the (private) UnmodifiableCollection etc classes. Other collection classes can be unmodifiable.

  • Even within the Java SE class library, the classes you would need to test for actually differs between different Java versions. (See @Holger's comment!)

  • You can't use instanceof because someone could subclass a modifiable class to be unmodifiable ... or vice versa.

  • Modifiability could depend on a collection object's runtime state. For example, the object could have a "frozen" flag that can be set after populating the collection using add methods.

In general, catching the exception is the most practical solution, irrespective of your feelings on how "proper" it is to use exceptions for this.

If course ... if you have total control over the collection classes that are used in your application, or may be encountered by your library ... then testing the classes may be more viable.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • I was thinking that it might be practical to just abort the method by an if check for modifiablity. My idea was, throwing and catching exceptions is expensive if I only want to do nothing in this exact case. But I think that informing the user nothing changed is a good idea. Preferably I would return a boolean but throwing an exception is most likely a good alternative. Thanks – RedCrafter LP Jun 22 '22 at 07:37
  • 5
    “throwing and catching exceptions is expensive”, but you are not supposed to catch them. Since passing an unmodifiable collection to a method expecting a modifiable collection is a programming error, throwing shouldn’t happen either. Then, optimistically performing the modification is the most efficient approach. It’s worth noting that modification support isn’t even a binary property. E.g. `Arrays.asList(…)` supports `set`, replace, and sorting, but no `add` nor `remove`. Whereas `HashMap`’s or `TreeMap`’s `keySet()` supports `remove` but not `add`. It’s not just modifiable or unmodifiable… – Holger Jun 22 '22 at 08:23
0

try below:

if(yourcolletion.getClass().getSimpleName().equals("UnmodifiableCollection")) {
 //can not modified
} else {
//given list is modifiable
}

you can also add for more check for UnmodifiableList etc.

Note: I would have recommended to use instanceof instead of checking for class name but you can not import the UnmodifiableList or UnmodifiableCollection classes into your code

Shridutt Kothari
  • 7,326
  • 3
  • 41
  • 61
  • 1
    This is what I was going to answer. `UnmodifiableXXX` are inner classes of `Collections` that are package private. As such, they are not visible to entities outside the package. Therefore, it cannot be tested using `instanceof` operator. Also, there are no methods in the Java Collections API that can perform such test. Therefore, the above answer is a reasonable workaround. – hfontanez Jun 22 '22 at 05:45
  • @hfontanez we think same brother!! cheers !! – Shridutt Kothari Jun 22 '22 at 05:48
  • You would need a potentially infinite chain of such tests. You can't guarantee that the only unmodifiable Collections that exist are those you've found in the JDK. – user207421 Jun 22 '22 at 06:11
  • 3
    @user207421 even within the JDK, there’s an unmaintainable number of tests to make. E.g. `Collections.emptyList()`, `Collections.singletonList("test")`, `List.of("test")`, `List.of("foo", "bar", "baz")` are instances of four different classes, all implementing an unmodifiable list not covered by this test. Though in case of `List.of(…)`, the number of implementation classes can change in every version. And that’s just the lists. Add the `Collection` and `Set` overloads and that’s not all, as each unmodifiable map may have its own `keySet()`, `values()`, and `entrySet()` implementation classes… – Holger Jun 22 '22 at 07:20