A very silly question: Can StringTokenizer be used to parse non-numeric strings? I ask because in my Intro to Java text it seems to be used only in examples where the user enters multiple numbers in an input dialog box.
I am working on an exercise in which String input is to be manipulated and had been thinking of utilizing StringTokenizer, but wasn't sure if it would work.
"Deprecated" has a specific meaning which does not apply here. StringTokenizer has not been deprecated. Though I would agree that String.split() is better, more flexible. Unfortunately it does have some other complications if the user has not learned about regular expressions yet...
Ok, you are right. Still it is discouraged from use. split is far cleaner. There is no reason to use it anyway.
"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."
Thanks for the input so far. I followed the link to split() in the Java Documentation, and it appears to break up a string and returns an array.
These questions are revolving around an assignment in class dealing with String manipulation. I am NOT asking for someone to tell me how to do this, but the general questions I have will help me rule out how I want to complete it.
If I use split(), in order to change the specific elements of the array, wouldn't I have to convert the String data to something that can be changed since Strings are immutable? Basically I have to move the first letter of a word to the end of that word. I was thinking of using StringBuffer after forming the array. Am I correct in my assumption that items of the String class cannot be changed, but StringBuffer can?
Again, gentle hints are appreciated, I am not fishing for actual code. The split() method was not even mentioned in our introductory text, so I am trying to discern its use without reader friendly explanation, which I expect happens in the field quite frequently.
Originally posted by Garrett Rowe: What type of manipulation do you need to do?
We're taking a string of input and converting it to Pig Latin. For anyone not familiar with this, in a nutshell you take the first letter of a word, move it to the end, then add an "ay" to it. So, the word "bike" would turn into "ikebay", for example.
I've been scouring the Java docs about String and StringBuffer, I'm assuming I cannot use split() with StringBuffer since it's not the same class. That would make things much easier if I could. However, I'm getting the feeling the solution isn't as difficult as I think.
And thanks for the suggestion, Keith. [ April 24, 2006: Message edited by: Brandt Charles ]
Garrett and Stan, thank you for your input. Garrett, your suggestion is what I had been trying to put together coherently. Please tell me that as I learn programming that it gets easier to translate ideas into code. I appreciate the gentle hints instead of the answer itself. I haven't been in a classroom in 10 years and I think expectations of myself are set too high such that I get very frustrated at the least bit of adversity. The frustration tends to cloud my thinking. [ April 24, 2006: Message edited by: Brandt Charles ]
I thought StringTokenizer was deprecated; it was last time i tried, so I usually use String.split(). But I looked a minute ago, and it isn't deprecated; they must have taken the deprecation off and now describe StringTokenizer as a legacy class, not recommended for new code.
Originally posted by Campbell Ritchie: I thought StringTokenizer was deprecated; it was last time i tried, so I usually use String.split(). But I looked a minute ago, and it isn't deprecated; they must have taken the deprecation off and now describe StringTokenizer as a legacy class, not recommended for new code.
StringTokenizer has been obsoleted, not deprecated. The same can be said for java.util.Vector, java.util.Hashtable, java.lang.StringBuffer and a few others.
Obsoleting a type permits the existing codebase of the API spec. implementation to compile without deprecation warnings (though it will not compile without unchecked cast warnings since generics contain some inherent flaws that are unavoidable).