byte array

Alright. result is a string, and the += operator, when the left hand side value (or what is known as an lvalue) is a string it concatenates the lvalue string with the string on the right hand side (or rvalue), and assigns the resulting string to the lvalue, or result. This is done in the background, but it's pretty simple and is the only way to do it since in Java strings are immutable, which means they cannot be changed.

Integer is a class in the java.lang package (which happens to be implicitly imported for every Java program), and toString is a static method of the Integer class, which means it can be called from the class name itself (Integer) instead of creating an instance of Integer to call it from. That method takes two arguments, an int argument, which happens to be the expression " ( b & 0xff ) + 0x100 "; and what is called a radix, or the number of unique symbolic characters, or digits, that represent value in that number system, and that is "16". I'd look at this Wikipedia article on Hexadecimal to learn more about radix 16. The expression is probably the part that confuses you the most, so I'll explain it a bit more:

The expression can be broken down even further. [noparse]b[/noparse] is the value in the byte array that is being converted, and to explain what is going on after that, you'd have to understand how Java interprets stuff as well as a little bit about binary logic. [noparse]b[i][/noparse] & 0xff means to perform a Binary And operation ( & ) on [noparse]b[i][/noparse] and 0xff. Since 0xff, in binary, equals "11111111", and the Binary And operation returns a binary value equalling whatever both the operands have a 1 located at are. It's difficult to explain, so here's a couple of examples:

0x7f & 0xf7:
00111111 &
11110011 =
00110011 (0x77)

0x55 & 0xaa:
01010101 &
10101010 =
00000000 (0x00)

Think of it as the processor simply lines up the bits and finds out which ones both have a 1 in each bit. This means, that in the operation [noparse]b[i][/noparse] & 0xff, you'll always end up with the same binary value as [noparse]b[i][/noparse]. So... why would you want to do that? The answer to that question is that all bytes MUST be signed, as Java does not have an unsigned type, and this operation will result in the [i]unsigned value of [noparse]b[i][/noparse]. This isn't important for the initial conversion, but it IS important for the next part, where you add 0x100. Now, if you notice, the next operation is to perform substring(1), which if you think about it, will cut off the first character returned by toString, which in this case will always be 1 (thanks to the + 0x100). So... if you're simply going to cut off the number you added... why add it?! Well, it's important to add 0x100 so that the returned string always has 0 digits. Imagine if [noparse]b[i][/noparse] happens to be 0, then when you perform the & operation, it's still 0, and from there, without adding 0x100, the toString will simply return "0", which is one digit. This will result in a HexString that is short one digit, and that's the last thing you want. Instead, you [i]want toString to return all of the 0 digits without reduction, so you tell it to toString 0 + 0x100 (0x100), then cut off the first digit, to ensure you have two 0 digits instead of only one. What this all essentially means is that the reason for all of these expressions is that there is two digits instead of one in cases where there would normally only be one.