Java Not Converting String to Long Object Properly

Question

We're using Spring/Hibernate on a Websphere Application Server for AIX. On my Windows machine, the problem doesn't occur--only when running off AIX. When a user logs in with an account number, if they prefix the '0' to their login ID, the application rejects the login. In the DB2 table, the column is of numeric type, and there shouldn't be a problem converting '090....' to '90...'

Anyone else experience a problem like this? Both machines have Java v1.5.

To be more specific, the flow is FormView -> LoginValidator -> LoginController

In LoginValidator, the value of login is null with the prefixed 0. Without the 0, the value is what it should be (But again, this is only on the AIX environment--on 2 Windows environments it's fine). Here's the snippet of code where the object equals null..

public class LoginValidator implements Validator  {

    public boolean supports(Class clazz) {
    return Login.class.equals(clazz);
    }

    @SuppressWarnings("all")
    public void validate(Object obj, Errors errors) {
        System.out.println("Inside LoginValidator");
        Login login = (Login) obj;
        //null value
        System.out.println("Before conversion in Validator, store id = " 
              + login.getStoreId()); 
    }
}

I've also written this short Java program for constructing a Long from a String, and using the java binary that is packaged with WebSphere

public class String2Long {
    public static void main(String[] args){
        String a = "09012179";
        String b = "9012179";

        Long _a = new Long(a);
        Long _b = new Long(b);

        System.out.println(a + " => " + _a); //09012179 => 9012179
        System.out.println(b + " => " + _b); //9012179 => 9012179
        System.out.println("_a.equals(_b) " + _a.equals(_b)); //_a.equals(_b) true
    }
}

SOLUTION

Answer 1

SOLUTION

A co-worker did some research on Spring updates, and apparently this error was correct in v. 2.5.3:

CustomNumberEditor treats number with leading zeros as decimal (removed unwanted octal support while preserving hex)

We were using Spring 2.0.5. We simply replaced the jars with Spring 2.5.4, and it worked as it should have!

Thanks to everyone for your help/assistance. We will make use of Unit tests in the future, but this just turned out to be a Spring bug.

Answer 2

Well there's an awful lot of things going on there. You really need to try to isolate the problem - work out what's being sent to the database, what's being seen by Java etc.

Try to pin it down in a short but complete program which just shows the problem - then you'll be in a much stronger position to file a bug or fix your code.

Answer 3

Trace through the program following the path of the String all the way to database and make unit tests for every single method on that path. And don't just take the shortest possible route here, make multiple unit tests with different inputs and expected outputs to really see what went possibly wrong. Assuming you don't find any errors, run the same unit tests on the other computer and you should be able to pinpoint the bug. From the top of my head I'd assume it may have something to do with case sensitivity but there really is no way to be sure.

Next time, use TDD.

Answer 4

I don't know much about Java, but this might happen the string is interpreted as octal string because of the leading "0".

You can probably work around this using Long.parseLong(a, 10).