Java does not correctly convert string to long object

We are using Spring / Hibernate on WebSphere Application Server for AIX. On my Windows machine, the problem does not occur - only when starting AIX. When a user logs in with an account number, if the prefix "0" matches their login ID, the application rejects the login. In a DB2 table, the column is of numeric type and there should be no problem converting '090 ....' to '90 ... '

Does anyone have such a problem? Both machines have Java v1.5.

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

In LoginValidator, the login value is null, prefixed with 0. Without 0, the value will be what it should be (but again, this is only on AIX - this is fine on two Windows environments). Here's a code snippet where object is 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 also wrote this short Java program to construct a Long from String and using the java binary that is packaged in 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
    }
}

      

DECISION

+1


source to share


5 answers


DECISION

A co-worker did some research on Spring updates and apparently this bug was correct in 2.5.3:



CustomNumberEditor treats number with leading zeros as decimal (removed unnecessary octal support when storing hex)

We used Spring 2.0.5. We just replaced the jars with Spring 2.5.4 and it worked the way it should!

Thanks everyone for your help / help. We'll be using unit tests in the future, but that just turned out to be a Spring bug.

+2


source


Well, there's a lot going on there. You really need to try to isolate the problem - figure out what is being sent to the database, what is visible with Java, etc.



Try setting it in a short but complete program that just shows the problem - then you are in a much stronger position to write a bug or fix your code.

+3


source


Trace through the program along the String path to the database, and unit tests for each individual method along the way. And don't just take the shortest path here, do some unit tests with different inputs and expected outputs to really see what went wrong. Assuming you find no errors, run the same unit tests on a different machine and you should be able to identify the error. From the top of my head, I would guess it might have something to do with case sensitivity, but there really is no way to be sure.

Use TDD next time.

+2


source


I don't know much about Java, but it can happen that the string is interpreted as an octal string because of the leading "0".

Perhaps you can get around this using Long.parseLong (a, 10).

0


source


Not sure why it will behave differently on different systems. These are many C-derived languages, zero-based numbers are considered octal, not decimal. Again, it should behave the same on all platforms, but you can ask Hans' advice to specify the radix value as 10 in the parseLong method.

-1


source







All Articles