GeeCON Prague 2014*
The moose likes Java in General and the fly likes constant members for an array Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Java in General
Bookmark "constant members for an array" Watch "constant members for an array" New topic
Author

constant members for an array

Kapil Verma
Greenhorn

Joined: Dec 15, 2002
Posts: 1
Hi,
If you have an array declared in a class Xyz as :
public static final int MAXALLOWEDBENF[] = { 0,
3};
and access it from another class as:
int maxAllowedBenf[]= Xyz.MAXALLOWEDBENF;
and change the content: maxAllowedBenf[0]=1;
it changes the content of original array (MAXALLOWEDBENF in Xyz). Making it final doesnt work.
How can you make the members of MAXALLOWEDBENF constant so that they cannot be changed
Regards,
Kapil
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi kapil,
wow! i never thought of this. i am pondering upon this. this is an interesting issue. we can say,
final[] of ints but can't say - final[] of final ints the way we do in C/C++ (in C/C++ we use const keyword though)...
i'm thinking if we can find a way out of this...
regards
maulin
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
hi Kapil,
i found it!! we can't achieve what u want to do as per the JLS 4.5.4 that says,
-----------
"A blank final is a final variable whose declaration lacks an initializer.
Once a final variable has been assigned, it always contains the same value. If a final variable holds a reference to an object, then the state of the object may be changed by operations on the object, but the variable will always refer to the same object. This applies also to arrays, because arrays are objects; if a final variable holds a reference to an array, then the components of the array may be changed by operations on the array, but the variable will always refer to the same array."
-----------
i wonder what is the way of this if we really want this functionality...
Gurus..please throw some light on this.
regards
maulin
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
you could access it through an static accessor method that returns a copy of the array, this means changes would not change the original. e.g.

cheers,
Tom
[ December 16, 2002: Message edited by: Don Kiddick ]
Kalpesh Soni
Ranch Hand

Joined: Jan 02, 2001
Posts: 312
yes maulin
that is true
there is no help from java language in making an object fixed or constant
we can only restrict access by returning a copy (even if it may not be efficient)


Test 094, IBM WID 6.0 cert
SCJP 1.2
SCBCD 1.3 Beta
SCWCD 1.4 Beta
SCMAD Beta
SCDJWS Beta

KS
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
i wonder what is the way of this if we really want this functionality...
KS correctly suggests making a copy of the array - so that any changes to the array do not affect the original. Another option is to use an ArrayList rather than an array, and then use Collections.unmodifiableList() to create an unmodifiable view of the list. Compared to using an array, this will be more efficient to create (at least for large collections) but less efficient to access. More importantly, the unmodifiable collection will throw an exception if anyone tries to modify it - which is useful for detecting errors. The array copying approach may be misleading - people my modify the copy, thinking they're modifying the original, and not understand why it doesn't work. Of course if you've properly documented your methods, you can then chastise them for not reading your documentation. But I like to enforce my documentation where possible by throwing exceptions as punishment for violators.
[ December 16, 2002: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
It would be even better if there was a ReadOnly versions of the collections interfaces. e.g. ReadOnlySet, ReadOnlyList, ReadOnlyCollection etc...
Then you could enforce the unmodifiability (is that a word ?) at compile time.
T.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Yeah, that seems like it might be nice. Though I think it would also get complex quickly - you'd really need new ReadOnly extensions of the existing collections interfaces and implementations. E.g. if I want to write a method that requires a List argument that it also read-only, the only way to enforce that at compile time would be to have a single interface (or class) like ReadOnlyList. And you'd need to provide implementations of each (though I guess you could just redefine methods like Collections.unmodifiableList() to return ReadOnlyList rather than List.) Still, I think this requires too many additiona to the collections framework to be worthwhile. It's easy enough to enforce unmodifiability at runtime; not all checks can be made at compile time.
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
Wouldn't be that difficult :
Deprecate the Collections.unmodifableXXX methods
For each collection type. (I'll use ArrayList as an example.)
Migrate the read-only behaviour to a ReadOnlyArrayList class. The existing ArrayList wraps a ReadOnlyList and additionaly provides the remaning 'write' functionality.
T.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Deprecate the Collections.unmodifableXXX methods
Why? There's nothing wrong with them; we're just providing alternatives.
Migrate the read-only behaviour to a ReadOnlyArrayList class. The existing ArrayList wraps a ReadOnlyList and additionaly provides the remaning 'write' functionality.
I don't see how you could get any benefit from wrapping a ReadOnlyList. How would you implement the add(Object) method? You'd need to put the new object into some sort of structure, and the ReadOnlyList won't let you add anything to it - so you need some other structure. Once you add another structure that can add(), there's no benefit to keeping the ReadOnlyList around.
Alternately, you could just keep ArrayList as is, and create a ReadOnlyArrayList that wraps the ArrayList. You just don't bother crating forwarding methods for things like add(). Presto! Except that this is really what Collections.unmodifiableList() does. The only thing new here is that we're allowing for compile-time checking of the read-only nature of the collection. That's useful, true, but it doesn't seem worth doubling the number of classes and interfaces in the collections framework, IMO.
Another issue is that there are really different levels of "read-only". If you create an unmodifiableList() of StringBuffer objects, is it read-only? Well, you can access an individual StringBuffer element and modify its contents. Calling this read-only might give people a false sense of security. We could have two interfaces - ReadOnlyList and ImmutableList. A List would only be Immutable if it's ReadOnly and its contents are all Immutable. (Immutable would be a new marker interface to be retrofitted onto all existing immutable classes like String). This sort of collection would be best enforced using generics - which incidentally should provide a lot more useful compile-time checking of collections (though not specifically for read-only nature).
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
Good idea, I might create my own ReadOnly collection classes !
T.
 
GeeCON Prague 2014
 
subject: constant members for an array