Resetting the array size

Hi Can anybody plz guide me a bit as to how can one reset an array size once declred .e.g:String[] str = new String[100]; I load this array with 100 elements . Now if i need to add the 101th element.... how can i do that ? [ March 19, 2004: Message edited by: raghav mathur ]

I don't think you can expand the array size, if you need to have a array with dynamic size, could try Vector or ArrayList Or you want to declare a large size array & use System.arrayCopy() to move elements to new array.

The simplest thing to do is to keep your objects in an ArrayList until you actually need an array - see the toArray method. Copying large numbers of references from one array to another is supposed to be faster with the System.arrayCopy method (But I have not timed it) Bill

My solution for a single dimension array (such as you've indicated) that will vary in size, would be to forget arrays and use a LinkedList. This way you don't have to worry about out-of-bounds exceptions. Just remember that when you get something from the LinkedList it is returned as type Object, so you will have to cast it back to its original form.LinkedList list = new LinkedList(); String string = new String("whatever"); list.addFirst(string); String newString = (String)list.getFirst();

Raghav: As the other posts have suggested, if you need a dynamic array (i.e., one that grows as needed), then you should use one of the classes provided by the Collections Framework, such as ArrayList. My question back to you is this: Is there some reason why you would not be able to use one of the standard collections? If there is such a reason, then you can use the approach you suggest in your follow-up post, except use the System.arraycopy() method to actually copy the array. It is faster than doing the copy manually, as your code did.

For my latest books on Java, including my Java Programming Cookbook, see HerbSchildt.com

Raghav Mathur
Ranch Hand

Joined: Jan 12, 2001
Posts: 641

posted Mar 26, 2004 08:36:00

0

Originally posted by Herb Schildt:

My question back to you is this: Is there some reason why you would not be able to use one of the standard collections? If there is such a reason, then you can use the approach you suggest in your follow-up post, except use the System.arraycopy() method to actually copy the array. It is faster than doing the copy manually, as your code did.

Herb : The reason i am not able to use the standard collection such as ArrayList or LinkedList is because i am constructing Object Arrays( I am working on the MVC architechture). i'll write some code here which will make things a bit clear. I have a class say LeaseType.java

The class mentioned above comprises of getter and setter funcrions . Now i have another class CaptiveLeaseTypeImpl.java

That means that there will be only one instance of the class "CaptiveLeaseTypeImpl.java" . That means the method "public CaptiveLeaseType[] setLeaseTypeDetails()" will be executed but the arrays will be loaded only once if the instance of class "CaptiveLeaseType" is null. So i have the array ready which means i have a mini database in the form of an array on the server. Now whatever data i need ... i will only have to connect to the db once till the object arrays are loaded. Now comes the part which made me post a my question here . If the database gets upddetd , my object array also has to be updated so what i was doing till now was :

setting the CaptiveLeaseTypeBean to null and executing a connection again to load the object arrays. I hope i am clear now

Ok... So you're writing a singleton that acts as a cacheing mechanism. You can store anything you want in the standard collections. They are collections of the the uber super class: Object. All you need to do is cast them to the more specific class when you need to use them. If the sub-type varies in the array, there are still calls you can make to find out what type of object that instance is (i.e. instanceOf operator) and cast it accordingly. FYI... Lots of application servers and dbms's, etc. already do better caching than most of us can ever hope to write. Be very careful issues related to making this sort of thing thread safe and efficient are more complex than many people initially think. It can be tricky stuff. [ March 26, 2004: Message edited by: Byron Estes ]