Java StringTokenizer - Problems with nextToken() usage with substring

I have a text file I must iterate through and want to move certain elements of each line into an ArrayList. Each line of the file is in the format: number. String number. decimal decimal
As the two numbers have a full stop (.) at the end and I need to read these as a String, removed the . using substring and then convert to a primitive data type (int or short).

Example on file:
294. ABC123 66. .00 .00

I get a string range error if I try this: (* temp is a String)

while(fileLine.hasMoreTokens())
{
	oneNumber = Integer.valueOf(fileLine.nextToken().substring(0, 
                          fileLine.nextToken().indexOf('.')));
	twoString = fileLine.nextToken();
	threeNumber = Short.valueOf(fileLine.nextToken().substring(0, 
                          fileLine.nextToken().indexOf('.')));
	temp = fileLine.nextToken();    //Handle attributes not required
	temp = fileLine.nextToken();    //Handle attributes not required
}

I believe why this is happening is that the nextToken() in the substring's parameters is confusing the StringTokenizer. So I fixed it like this:

				while(fileLine.hasMoreTokens())
				{
					temp = fileLine.nextToken();
					oneNumber = Integer.valueOf(temp.substring(0, temp.indexOf('.')));
					twoString = fileLine.nextToken();
					temp = fileLine.nextToken();
					threeNumber= Short.valueOf(temp.substring(0, temp.indexOf('.')));
					temp = fileLine.nextToken();
					temp = fileLine.nextToken();
				}

While this works it feels a bit redundant. Is there something I can try to make this cleaner, while retaining use of the StringTokenizer?

This is the intended behavior of .nextToken(): it returns the token and moves past the current token. When you use Integer.valueOf(fileLine.nextToken().substring(0, fileLine.nextToken().indexOf('.'))), you are calling .nextToken() twice, which means you are dealing with two distinct tokens. It has nothing to do with how String#substring works. You need to store the token in a variable if you need to perform additional operations on it. This exact same problem can also be caused by using BufferedReader#readLine twice when one should be storing the value.

Yup. nextToken() is stateful, calling it changes things, so using it twice in a single line would consume two tokens.

Your second snippet seems much easier to read to me, so I'm not sure what the problem is. Presumably you want your code to be more readable.

An easy fix is to make helper methods:

while (fileLine.hasMoreTokens()) {
    oneNumber = fetchHeadingNumber(fileLine);
    twoString = fileLine.nextToken();
    threeNumber = fetchHeadingNumber(fileLine);
    fileLine.nextToken(); // no need to assign it.
    fileLine.nextToken();
}

with this method:

int fetchHeadingNumber(StringTokenizer t) {
    String token = t.nextToken();
    return Integer.parseInt(token.substring(0, token.indexOf('.')));
}

you can go even further and make a class representing a line, which has all the code needed to parse it (I made up names; your snippet doesn't make clear what kind of thing the line represents):

@lombok.Value class InventoryItem {
    int warehouse;
    String name;
    int shelf;

    public static InventoryItem read(StringTokenizer tokenizer) {
        int warehouse = num(tokenizer);
        String name = tokenizer.nextToken();
        int shelf = num(tokenizer);
        tokenizer.nextToken();
        tokenizer.nextToken();
        return new InventoryItem(warehouse, name, shelf);
    }
    private static int num(StringTokenizer t) {
        String token = t.nextToken();
        return Integer.parseInt(token.substring(0, token.indexOf('.')));
    }
}

and then reading a line and retrieving, say, the location where it is stored is so much nicer: Now things actually have names!

InventoryItem item = InventoryItem.read(fileLine);
System.out.println("This item is in warehouse " + item.getWarehouse());

NB: Uses lombok's @Value to avoid putting a lot of boilerplate in this answer.