I have the following code snippet and need some help understanding a few pieces of it.
String fileName = UUID.randomUUID().toString();
int hashcode = fileName.hashCode();
//I'm not sure why we are creating a mask with an int of 255
int mask = 255;
//Wny are we adding 255 to the hashcode?
int firstDir = hashcode & mask;
//What does it mean to have (hashcode >> 8) & mask? If I were to build a third
// tier would I use (hashcode >> 16) $ mask?
int secondDir = (hashcode >> 8) & mask;
StringBuilder sb = new StringBuilder(File.separator);
//I noticed when using this %02 it truncates the directory to 2 chars, does this
//just convert 3 digits to alpha numeric representing the same three digits?
sb.append(String.format("%02x", firstDir));
sb.append(File.separator);
sb.append(String.format("%02x", secondDir));
sb.append(File.separator);
Lastly, if I wanted to generate a file name from the two directories, would I just setup another string builder without the File.separator, or would it be more efficient to build the string first without the file separator, then split up the string?
255 is 0FF hex, 0 1111 1111 binary.
A mask used with the 'and' operator ("&") is used to isolate the bits of the value to which the mask is anded -- an integer anded with the above mask results in an integer with the same lowest-order 8 bits as the original integer.
An integer put through >> 8 is shifted to the right 8 bits; anding with the same mask after that isolates those 8 bits, which started out as the next-higher-order 8 bits in the original integer.
Don't worry about efficiency unless you can show that a few microseconds is going to make a difference. Worry about making your code understandable enough that someone doesn't have to post to stackoverflow to understand it.
That code is just silly.
If you want to create two randomly distributed two-digit hex codes derived from a random UUID, you can just use the first four hex digits of the UUID itself.
String fileName = UUID.randomUUID().toString();
String firstDir = fileName.substring(0,2);
String secondDir = fileName.substring(2,4);
A random UUID is a cryptographically strong random binary string (except for a few fixed digits to denote that this is a type-4 UUID). Any hashing and bit shifting or masking will just degrade the randomness.
Related
I am working on a file reader and came into a problem when trying to read a short. In short (punintended), java is converting a two bytes I'm using to make the short into an int to do bitwise operations and is converting it in a way to keep the same value. I need to convert the byte into an int in a way that would preserve its value so the bits stayed the same.
example of what's happening:
byte number = -1; //-1
int otherNumber = 1;
number | otherNumber; // -1
example of what I want:
byte number = -1; //-1
int otherNumber = 1;
number | otherNumber; // 129
This can be done pretty easily with some bit magic.
I'm sure you're aware that a short is 16 bits (2 bytes) and an int is 32 bits (4 bytes). So, between an integer and a short, there is a two-byte difference. Now, for positive numbers, copying the value of a short to an int is effectively copying the binary data, however, as you've pointed out, this is not the case for negative numbers.
Now let's look at how negative numbers are represented in binary. It's a bit confusing, so I'll try to keep it simple. Modern systems use what's called the two's compliment to store negative numbers. Basically all this means is that the very first bit in the set of bytes representing the number determines whether or not it's negative. For mathematical purposes, the rest of the bits are also inverted and offset 1 bit to the right (since you can't have negative 0). For example, 2 as a short would be represented as 0000 0000 0000 0010, while -2 would be represented as 1111 1111 1111 1110. Now, since the bytes are inverted in a negative number, this means that -2 in int form is the same but with 2 more bytes (16 bits) at the beginning that are all set to 1.
So, in order to combat this, all we need to do is change the extra 1s to 0s. This can be done by simply using the bitwise and operator. This operator goes through each bit and checks if the bits at each position in each operand are a 1 or a 0. If they're both 1, the bit is flipped to a 0. If not, nothing happens.
Now, with this knowledge, all we need to do is create another integer where the first two bytes are all 1. This is fairly simple to do using hexidecimal literals. Since they are an integer by default, we simply need to use this to get four bytes of 1s. With a single byte, if you were to set every bit to 1, the max value you can get is 255. 255 in hex is 0xFF, so 2 bytes would be 0xFFFF. Pretty simple, now you just need to apply it.
Here is an example that does exactly that:
short a = -2;
int b = a & 0xFFFF;
You could also use Short.toUnsignedInt(), but where's the fun in that? 😉
Okay so, I have a case where I have to encode numbers with bitwise operators and then decode them
This is what I came up with to encode the number
Random random = new Random(System.currentTimeMillis());
int lastInt = random.nextInt(24);
int howMany = 350;
int start = (lastInt & ~1337) | (howMany << lastInt);
The number I want to encode is 350 This works fine for the most cases and I decode the number by using
start >> lastInt, How ever if the number is negative such as cases like this: System.out.println(-1593835514 >> 23);, it doesn't print the correct encoded number, I am pretty sure this is because the first integer is negative and I can use >>> to shift unsigned integers, but I don't wanna do that, How can I make sure all my encoded integers decode via >>
Since you use random.nextInt(24) for the shift value, it means the shift value can be in range 0..23. With a shift of 23, that only leaves 9 bits in a 32-bit number to store your value.
If the value is unsigned, that means supported range is 0..511.
If the value is signed, that means supported range is -256..255.
So, if you want to allow a value like 350, your encode/decode must be unsigned, which means you must use >>> when decoding.
As-is, you cannot support both 350 and negative values. If you want larger value ranges to support that, you need to use long.
I want to put a short integer (16 bits) into tail of a 32 bits integer (I'm compressing some small-range numbers to an unique integer). But didn't found a better looking way than bellow, I have to use two operation, can it be better?
short sh = -1; // 16 bits 1
int zip = 0; // last 16 bits presents a short number
System.out.println("Wrong way, maybe many of us will try first:");
zip |= sh; // expect 0xffff
System.out.println(Integer.toHexString(zip)); // but 0xffffffff
System.out.println("Simple way, right but looks ugly, two operations");
zip = 0;
zip |= sh << 16 >>> 16; // expect 0xffff
System.out.println(Integer.toHexString(zip)); // yeah
System.out.println("Is there a nicer looking way, one operation for example?");
All bitwise operations in Java are done using ints or longs, therefore you don't have too much choice here; and casting a shorter primitive type whose sign bit is set will "expand" the sign bit to all "newer created" bits.
There is a solution to do it "in one line", but that will still be two operations:
zip |= (sh & 0xffff);
Note, it pretty much requires that zip is 0 to start with, or at least that its 16 low bits are 0.
I need to generate a 3-bytes code (like A502F1). I am given a criteria:
1st byte is (serialCodeNumber / (256*256) ) & 0xFF
2nd is (serialCodeNumber / 256) & 0xFF
3th is (serialCodeNumber) & 0xFF
serialCodeNumber is a sequence 1-0xFFF
What does that mean!?
I would generate it like this:
String codeNum = new BigInteger(256, random).toString(16).toUpperCase().substring(0, 6);
But what is the right way of doing it as the requirement says?
I'm not quite sure what is meant by the serialCodeNumber, since if it is later on divided by 65025 it has to be a considerably larger number than 0xFFF (which is 4095) for it to make any reasonable sense.
But let's take a look at the conditions, they would all make sense once you are accustomed to the bitwise AND operator. A good read is available here on how it works but the meat of the matter from that question in my opinion is this sentence by Markus Jarderot:
The result is the bits that are turned on in both numbers.
Since in your conditions you have & 0xFF and 0xFF is 255, or in binary it's 11111111 the first eight bits that are all turned on. This is a neat trick to just retrieve only the first 8 bits of any number. And as we all know 8 bits make up a byte. (Are you starting to see where this all is coming together now?)
As for the conditions before the & 0xFF, some might recognize them as bit shift operations hidden behind divisions.
(serialCodeNumber / (256*256)) is equivalent to (serialCodeNumber >> 16)
and
(serialCodeNumber / 256) is equivalent to (serialCodeNumber >> 8)
But that is not that important in this case.
So the first condition takes the serialCodeNumber divides it by 65025 (256*256) and then looks at the 8 right most bits and ignores any other, from those 8 bits it constructs a byte.
In Java you can pretty much just write the condition as it is:
byte myFirstByte = (byte) ((serialCodeNumber / (256*256)) & 0xFF);
The other conditions aren't much different:
byte mySecondByte = (byte) ((serialCodeNumber / (256)) & 0xFF);
and
byte myThirdByte = (byte) ((serialCodeNumber) & 0xFF);
Once you have all three of your bytes, I'm assuming you need to convert them to a hex String. So I'll add them into a byte array.
byte[] myArray = {myFirstByte,mySecondByte,myThirdByte};
And borrow some method on how to convert byte arrays to HEX strings from this question.
String codeNum = bytesToHex(myArray);
And the result will look something like this:
F03DD7
EDIT:
Since you have to generate a serial number that has to be up to 6 bytes in value, I'd recommend using a long number.
A 6 byte number will be anywhere from 1 to 281474976710655, so you probably need to generate one randomly.
First instantiate a Random object which you will be able to poll numbers from:
Random random = new Random();
Once you have that, poll a long from it for the range 1 to 281474976710655.
For this you can borrow KennyTM's answer from this question.
So you can then generate the number like so:
long serialCodeNumber = nextLong(random, 281474976710655L)+1L;
We add the +1L at the end since we want it to include the last number as well as start from 1 instead of 0.
If you ever need to show a HEX string of the serialCodeNumber you can then just call:
String serialHex = Long.toHexString(serialCodeNumber);
But make sure to add any additional "0"s at the left side based on the length of the string so that it is 6-bytes = 12 characters long.
We have a J2ME application that needs to read hex numbers. The application is already too big for some phones so We try not to include any other codec or write our own function to do this.
All the numbers are 64-bit signed integers in hex, when we use Long.ParseLong(hex, 16), it handles positive numbers correctly but it throws exception on negative numbers,
long l = Long.parseLong("FFFFFFFFFFFFFFFF", 16);
How can we get -1 from that hex string using classes provided in Java itself?
Some people may suggest we should write our hex as -1 as Java expected. Sorry, the format is fixed by the protocol and we can't change it.
Your problem is that parseLong() does not handle two's complement - it expects the sign to be present in the form of a '-'.
If you're developing for the CDC profile, you can simple use
long l = new BigInteger("FFFFFFFFFFFFFFFF", 16).longValue()
But the CLDC profile doesn't have that class. There, the easiest way to do what you need is probably to split up the long, parse it in two halves and recombine them. This works:
long msb = Long.parseLong("FFFFFFFF", 16);
long lsb = Long.parseLong("FFFFFFFF", 16);
long result = msb<<32 | lsb;
UPDATE
As of Java 8, you can use parseUnsignedLong():
long l = Long.parseUnsignedLong("FFFFFFFFFFFFFFFF", 16);
Parse it in chunks.
long l = (Long.parseLong("FFFFFFFFF",16)<<32) | Long.parseLong("FFFFFFFF",16);
Worse case scenario, you could check to see if the string is 16 characters that begins with an 8-F, and if so, change that to the equivalent character w/o the most significant bit set (i.e. subtract 8 from that digit), parse the result, and add the parsed value to the lower bound of a signed long? (Essentially just doing the 2's complement yourself.)