Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #28415 > unrolled thread

String[] , Arrays.asList , Collections.unmodifiableList

Back to article view | Back to comp.lang.java.programmer

Contents

  String[] , Arrays.asList , Collections.unmodifiableList Roedy Green <see_website@mindprod.com.invalid> - 2014-05-08 21:30 -0700
    Re: String[] , Arrays.asList , Collections.unmodifiableList leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-09 01:02 -0500
      Re: String[] , Arrays.asList , Collections.unmodifiableList Roedy Green <see_website@mindprod.com.invalid> - 2014-05-09 09:25 -0700
        Re: String[] , Arrays.asList , Collections.unmodifiableList leif.roar@invalid.com (Leif Roar Moldskred) - 2014-05-09 12:45 -0500
    Re: String[] , Arrays.asList , Collections.unmodifiableList Stanimir Stamenkov <s7an10@netscape.net> - 2014-05-11 00:09 +0300

#28415 — String[] , Arrays.asList , Collections.unmodifiableList

I wrote a method of the form

String[] someMethod( ... )

IntelliJ complained this was a wicked thing todo.

Why?  Because the caller could modify the String array it at would
wreck by copy inside SomeMethod.  

So what do people do?  They use Arrays.asList to convert to a List, an
java.util.Arrays$ArrayList.

But List still lets the user modify the field which in turn modify the
underlying array. We have gained nothing.

We have to use Collections.unmodifiableList which gives us a
Collections.unmodifiableList wrapper around our List that throws
UnsupportedOperationException when we attempt to write.

The catch is the set methods are still there. We don't find out about
the problem of modifying this list until run time.
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Culture is your operating system. 
~ Terence McKenna (born: 1946-11-16 died: 2000-04-03 at age: 53)

[toc] | [next] | [standalone]

#28416

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 
> So what do people do?  They use Arrays.asList to convert to a List, an
> java.util.Arrays$ArrayList.

Return a clone of the internal array, not the array itself:

public class NotBad {
  private String[] myArray = ...;

  public String[] getArray() {
    if( myArray == null ) {
      return null;
    } else {
      return (String[]) myArray.clone();
    }
  }

>
> But List still lets the user modify the field which in turn modify the
> underlying array. We have gained nothing.

The problem isn't that you're returning something the client can
modify.  The problem is that you're giving the client backdoor access
into this object's private state: if you just return your internal
array any changes the client does to that array is a change in the
state of /this/.  If you return a _copy_ of the internal array, or a
list created from the internal array, any changes made to the return
value by the client only affects the _client's_ state, not /this/'s.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28417

On Fri, 09 May 2014 01:02:35 -0500, leif.roar@invalid.com (Leif Roar
Moldskred) wrote, quoted or indirectly quoted someone who said :

>Roedy Green <see_website@mindprod.com.invalid> wrote:
>> 
>> So what do people do?  They use Arrays.asList to convert to a List, an
>> java.util.Arrays$ArrayList.
>
>Return a clone of the internal array, not the array itself:
>
>public class NotBad {
>  private String[] myArray = ...;
>
>  public String[] getArray() {
>    if( myArray == null ) {
>      return null;
>    } else {
>      return (String[]) myArray.clone();
>    }
>  }
>
>>
>> But List still lets the user modify the field which in turn modify the
>> underlying array. We have gained nothing.
>
>The problem isn't that you're returning something the client can
>modify.  The problem is that you're giving the client backdoor access
>into this object's private state: if you just return your internal
>array any changes the client does to that array is a change in the
>state of /this/.  If you return a _copy_ of the internal array, or a
>list created from the internal array, any changes made to the return
>value by the client only affects the _client's_ state, not /this/'s.

I will add your idea to http://mindprod.com/arraylist.html#ARRAYASLIST
-- 
Roedy Green Canadian Mind Products http://mindprod.com
Culture is your operating system. 
~ Terence McKenna (born: 1946-11-16 died: 2000-04-03 at age: 53)

[toc] | [prev] | [next] | [standalone]

#28419

Roedy Green <see_website@mindprod.com.invalid> wrote:
> 
> I will add your idea to http://mindprod.com/arraylist.html#ARRAYASLIST
>

Please don't. The issue I tried to explain isn't _about_ arrays and
lists. The main point is that you shouldn't let access to your private
state leak out. This is a concern for _any_ mutable object that makes
up part of your internal state, not just arrays.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#28425

Thu, 08 May 2014 21:30:08 -0700, /Roedy Green/:

> We have to use Collections.unmodifiableList which gives us a
> Collections.unmodifiableList wrapper around our List that throws
> UnsupportedOperationException when we attempt to write.
>
> The catch is the set methods are still there. We don't find out about
> the problem of modifying this list until run time.

I think this more or less a general rule: Don't assume a returned 
Collection (or Map) is mutable unless explicitly stated by the 
documentation / contract.

-- 
Stanimir

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web