Past week...

So, I've been busy on two seperate projects, one with asp.net concurrency and bug fixing; the other with mapping schemas in BizTalk 2004.

The concurrency problem had an interesting solution. We used the timestamp in the database to check for a change before conmitting the updates. My other bugs where as always easy and stupd mistakes.

The biztalk conversion wizard for converting BTS2002 to BTS2004 didn't want to work for me, but it did give me the information that I needed. So I have the old maps and schemas, of course they are not sane mappings. The schemas use lots of attributes and multiple nodes in the destination schemas, which made me convert alot of visual basic into C# inline code, and use xslt in complex mappings.

BTS 2002 to BTS 2004 Migration: Error about a user('null')

I was having trouble using VS 2003 Migration wizard to authenicate to a remote server. Of course I had to VPN into the domain. The problem I was getting after entering the server and database name, was an error stating that I could not connect because the username was null. The VS was suppose to use my credential for the connection. Solving the problem was done by going to the Control Panel > Stored User Names and Passwords. Add a connection with my username@domain and password. This got me in.

Java Question:

Well, I was just browsing the Code Project's website and found this interesting. Given the following Java code:

Posted by: Dominik Reichl

Integer i = 1;
Integer j = 1;
Integer n = 1000;
Integer m = 1000;

boolean b1 = (i == j);
boolean b2 = (n == m);

Now, what are b1 and b2?

Surprisingly b1 is true, b2 is false.

Why?
















Posted by: Dominik Reichl

Ok, so here's the solution why it works this way
First of all, we are using Integer wrapper classes instead of the primitive int type. When compiling, the integral values 1 and 1000 are implicitely converted to Integer objects (called auto-boxing, from int to Integer).

So, we got 4 different Integer instances, right? No!

The Java VM automatically packs "small" primitive values into identical objects (1 is small, 1000 isn't small). You can easily verify this by pasting the code above into a small testing project and fire up the debugger: i and j reference the same object, while n and m reference different objects. The == operator is comparing references, therefore b1 is true (same references) and b2 is false (different references).

Currently "small" means any integer between -128 and 127. But according to Sun this can change to [-32768, +32767] in the future. This packing trick has been introduced to solve performance problems when doing arithmetic with wrapper classes.