convert string to Jlist

The following code snippet produces a string of words

Code:

---

            nWords = 0;
            findWords(Dawg.root, 0);//findWords is an anagram routine which produces the string
            strBuf.append("(" + nWords + ")"); //nwords = number of words
            HintListBox = new JList(model);
            model.addElement(strBuf.toString());

---

I am trying to populate the results into a JList but the results appear as a single string, i.e.

EAT would look like:

AT ATE EAT

what I need is

AT
ATE
EAT

Have been working on it for a while but cannot figure out how to 'split' each new word. I can do it for a TextBox but Jlist is a little bit trickier

Can someone shed some light?
Thanks

You need to add each word separately to the JList.

Why does findwords() concatenate them all into a StringBuilder object (is that what it is doing?) rather than returning an array of Strings.

If it has to be as is then convert the StringBuilder into a String (call toString()) and then use the String's split(..) method to break it into an array of Strings, which you can then iterate over adding each one to the JList.

Quote:

---

Originally Posted by peahead

Have been working on it for a while but cannot figure out how to 'split' each new word. I can do it for a TextBox but Jlist is a little bit trickier

Can someone shed some light?
Thanks

---

Use StringTokenizer(str, " ") to separate words.

Quote:

---

Use StringTokenizer(str, " ") to separate words.

---

No don't. StringTokeniser API docs state:

Quote:

---

StringTokenizer is a legacy class that is retained for compatibility reasons although its use is discouraged in new code. It is recommended that anyone seeking this functionality use the split method of String or the java.util.regex package instead.

---

Quote:

---

Originally Posted by keang

No don't. StringTokeniser API docs state:

---

it is not prohibited to use StringTokenizer, right?
It will kept for back compatibility, as other obsolete methods.

But in this particular case better teach
findWords(Dawg.root, 0);
put words into JList immediately, not create strBuf

Quote:

---

Originally Posted by jitechno

it is not prohibited to use StringTokenizer, right?
It will kept for back compatibility, as other obsolete methods.

---

It's not prohibited, and strangely, despite calling it a 'legacy' class and explicitly recommending it should no longer be used, Sun haven't yet deprecated it...

However, String.split(..) is the recommended choice.

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race...
A. N. Whitehead

Quote:

---

Originally Posted by jitechno

it is not prohibited to use StringTokenizer, right?
It will kept for back compatibility, as other obsolete methods.

---

True, but just because something is there it doesn't mean you should use it. It's good practice to use those classes that are the recommended classes and not those that are deprecated, or in this case, no longer recommended.

Quote:

---

Originally Posted by jitechno

But in this particular case better teach
findWords(Dawg.root, 0);
put words into JList immediately, not create strBuf

---

I agree that it shouldn't put the words into a StringBuffer but it equally should not populate the JList.

findwords(..) should do exactly what it says it does ie it should just find words and it should return the found words in either an array or collection class. A method that returns the found words is more useful than one that finds the words and populates the JList or one that finds the words and concatenates them into a StringBuffer. If you have a list/array of words you can easily populate the JList and/or create a concatenation of words, it's not so easy to go the other way.

Quote:

---

Originally Posted by dlorde

and strangely, despite calling it a 'legacy' class and explicitly recommending it should no longer be used, Sun haven't yet deprecated it...

---

And equally strangely they have embedded the comment half way through the description of how to use the class rather than putting it clearly at the top. I guess this is just another of life's little mysteries.

Thanks to all for their input. String's split(..) method is the way to go.
I was able to follow the example from this site to create an array of Strings, which I then iterated into the JList.
http://www.java-examples.com/java-string-split-example
code snippet here

Code:

---


//* String to split. */
String str = "one two three";
String[] temp;
//* delimiter */
String delimiter = " ";
//* given string will be split by the argument delimiter provided. */
temp = str.split(delimiter);
//* print substrings */
for(int i =0; i < temp.length ; i++)
System.out.println(temp[i]);

---

Quote:

---

Originally Posted by keang

True, but just because something is there it doesn't mean you should use it. It's good practice to use those classes that are the recommended classes and not those that are deprecated, or in this case, no longer recommended.
I agree that it shouldn't put the words into a StringBuffer but it equally should not populate the JList.

findwords(..) should do exactly what it says it does ie it should just find words and it should return the found words in either an array or collection class. A method that returns the found words is more useful than one that finds the words and populates the JList or one that finds the words and concatenates them into a StringBuffer. If you have a list/array of words you can easily populate the JList and/or create a concatenation of words, it's not so easy to go the other way.

---

Keang, it depends on requirements to your application and selected realization.
If you use findwords(..) only for creation JList, you may build Jlist directly. If you use findwords(..) also for other purposes, bettre to create String and parse this string.

Quote:

---

If you use findwords(..) only for creation JList, you may build Jlist directly.

---

And what happens in the future if you add another feature that requires the list of words?
It's far better to separate the functionality now rather than trying to do it later.

Quote:

---

If you use findwords(..) also for other purposes, bettre to create String and parse this string.

---

I'm not sure if I understand what you are suggesting here, it reads like you are saying it is better for the findWords method to concatenate all the words into one string which it returns and then the calling method has to parse the string to break it back into individual words. Is this really what you mean or have I misread it?