RocketMan on 8/5/2009 at 06:05
Thanks Al_B. Perhaps with enough practice these rules will simply become ingrained.
I have a new problem...this time somewhat more legitimate. I've exhausted multiple troubleshooting options before posting so hopefully this doesn't seem stupid. Here's a real snippet:
public String[] thrustdata(String filename) {
File fil;
FileReader instream;
BufferedReader buf;
int i=0;
String[] thrustpoints = null;
try {
fil = new File(filename);
instream = new FileReader(fil);
buf = new BufferedReader(instream);
String current = buf.readLine();
while(!(current.equalsIgnoreCase("EOF"))) {
thrustpoints = current;
current = buf.readLine();
i++;
}
buf.close();
}
catch(Exception e) {
System.out.println("fail");
System.out.println(e.getMessage());
}
return thrustpoints;
}
I am certain that the bolded line is the one throwing the exception except the exception itself is "null" and I can't for the life of me figure out why assigning a string to an array cell would be a problem. The text file is a space (and hard return) delimited file with several string and numeric entries (which are all parsed as strings anyway). Any clues?
dvrabel on 11/5/2009 at 02:07
You've not allocated any memory for your array. The compiler probably gave an error for this (before you added that '= null').
RocketMan on 11/5/2009 at 05:32
Thanks dvrabel. I defined a size for the array and it fixed the problem. The problem is that the size of the array should be dynamic. I incorporated a function to check the size the array needs to be at runtime but I'm a bit unsettled since I can think of times when this wouldn't be possible to check. What if you need to just start assigning values and make the array bigger as you go? If it's not illegal to define an array without a size then why does it throw an exception when you try to populate it? Shouldn't the array point to the first cell and every subsequent cell occupies the next available memory block?
dj_ivocha on 11/5/2009 at 06:37
Arrays have a fixed size. If you need a dynamically sized one, you can use java.util.Vector instead.
SeriousCallersOnly on 11/5/2009 at 16:50
Quote Posted by dj_ivocha
Arrays have a fixed size. If you need a dynamically sized one, you can use java.util.Vector instead.
Huh, no. Use a list (if needing ordering - array list if don't need removal, linkedlist otherwise) or a HashSet (if not needing ordering).
dj_ivocha on 11/5/2009 at 18:58
And why not? Vectors are just about the same as array lists, except synchronized. Because of that an implementation with vectors might be a bit slower or use more memory (not sure how the serialization influences run time and memory usage), but probably not enough to make that big a difference.
Volca on 12/5/2009 at 06:55
Quote Posted by SeriousCallersOnly
Huh, no. Use a list (if needing ordering - array list if don't need removal, linkedlist otherwise) or a HashSet (if not needing ordering).
Beware - Set does not store duplicates.
SeriousCallersOnly on 12/5/2009 at 15:03
Quote Posted by dj_ivocha
And why not? Vectors are just about the same as array lists, except
synchronized. Because of that an implementation with vectors might be a bit slower or use more memory (not sure how the serialization influences run time and memory usage), but probably not enough to make that big a difference.
That's just the attitude that makes the jdk people use StringBuffers in the EDT instead of StringBuilders.
The attitude of using a array document GapContent instead of a list of paragraphs. (with predictable results when inserting text - hello OoM exception).
Java prides itself of programming to the interface, but if you see the jdk or try to change some implementations you'll see lots of not so little inefficiencies because of programming to it, like the CharSequence SNAFU where the moronic engineer responsible thought a buffered copy method (getChars) would not be needed in spite of the interface already having a (charAt) - so no methods that work efficiently on reading/copying all views thank you very much, with the predictable result of using Strings on the other interfaces, with the predictable result of calling toString() in StringBuffer/Builder EVERY FUCKING WHERE DUPLICATING MEMORY REQUIREMENTS OF LARGE TEXTS.
At least google changes the interfaces in android, there is hope yet for a sane jdk.
Do yourself a favor if you are a library programmer. Use abstract classes instead of interfaces for extensible public api.
dj_ivocha on 12/5/2009 at 18:44
Thanks for this very informative post. Now I know why I should never, ever use vectors. :thumb:
not really
SeriousCallersOnly on 12/5/2009 at 21:03
ArrayList is faster. Ok?
