Develop Reference

How does the implementation of this bitwise operator make sense?

In an earlier question regarding how to maximize the JFrame I saw this bit of code and it worked. I took out the
name.getExtendedState()
and it still worked? What does the use of the "getter" and the OR symbol accomplish?
name.setExtendedState(name.getExtendedState()|JFrame.MAXIMIZED_BOTH);

Using name.getExtendedState()|JFrame.MAXIMIZED_BOTH means that you're adding MAXIMIZED_BOTH to the existing extended state. If you say only JFrame.MAXIMIZED_BOTH, that means you're replacing the extended state with only that bit, and throwing away anything in the current extended state.

From the API getExtendedState() :
Gets the state of this frame. The state is represented as a bitwise mask.
NORMAL
Indicates that no state bits are set.
ICONIFIED
MAXIMIZED_HORIZ
MAXIMIZED_VERT
MAXIMIZED_BOTH
Concatenates MAXIMIZED_HORIZ and MAXIMIZED_VERT.
The logical OR will combine the returned value with the value of JFrame.MAXIMIZED_BOTH
for example if NORMAL was 10110 and MAXIMIZED_BOTH was 01100, ORing the two would yeild 1110
Normal 10110
MaxBoth 01100
Result 11110

Quoted from Wikipedia: http://en.wikipedia.org/wiki/Bitwise_operation#OR
A bitwise OR takes two bit patterns of equal length and performs the
logical inclusive OR operation on each pair of corresponding bits. The
result in each position is 1 if the first bit is 1 or the second bit
is 1 or both bits are 1; otherwise, the result is 0. For example:
0101 (decimal 5)
OR 0011 (decimal 3)
= 0111 (decimal 7)
So if getExtendedState() is returning a number made up of binary flags (ie. a bit field)... ORing it (using the pipe operator | ), is simply keeping ALL the existing flags in the object's state and also setting the bit/s that correspond to the state JFrame.MAXIMIZED_BOTH.
This is because ORing sets a bit to 1 if it is 1 in either the first operand OR the second operand.
Hope that helps explain it.

What's the correct way to flip one bit in a byte while preserving the rest?

[EDIT]
I realized that unfortunately I oversimplified the question and the answers aren't really helping me, so I'm rephraseing it...
So, my situation I have a stream of incoming bytes (sample) in which the ONLY bit that is potentially set is the first one (0000 | 0001).
So, let's say I get a sequence of these that looks like this:
0000,000**0**,
0000,000**1**,
0000,000**0**,
0000,000**1**,
0000,000**0**,
0000,000**0**,
0000,000**0**,
0000,000**0**
I'm setting the relevant bit to bold to make it clearer as to what I'm actually collecting.
So, as these 'bits' arrive I need to sort them into something that looks like this:
0000,1010
I'm doing this by shifting the existing value >> 1 and then adding the incoming value shifted over by << 7
byte aggregateByte = 0;
//loop 8 times as incoming samples arrive...
aggregateByte = (aggregateByte >> 1) + incomingSample << 7
This (*should) produce the correct result.
HOWEVER because java doesn't have the notion of an signed/insigned, EVERY time I shift, because I'm starting on the left hand side, if the previous incoming bit was 1, java PRESERVES the 1 since it sees this as the sign bit and never allows it to reset back to 0.
So... what I need to do prior to adding my incoming bit is to flip the first bit in the existing byte to 0 and then the incoming bit will be set to whatever it needs to be set to.
Currently I'm doing this by setting a mask of 0x7F and &ing that against the byte.
So, my actual addition looks like this:
((aggregateByte >> 1) & 0x7F ) + incomingSample << 7
0x7F creates a mask that looks like this:
0111,111
So, when I & this against the existing value, it flips the last bit to 0.
I guess my question is "am I reinventing the wheel, and is there a better way to handle this, or will this reliably work and is a relatively efficient way to handle this process?"

Neither | nor & is for toggling bits. For that, you need to use ^. But 0x40 is indeed the correct value for flipping bit 6 ("7th" in your terms).

To flip bit 3:
final int N = 3;
b = (byte) (b ^ (1 << N));

Often big numbers become negative

Since I started using eclipse for project euler, I noticed that big numbers sometime become a seemingly random negative numbers. I suppose this has something to do with passing the boudry of the type.
I'll be glad if you could explain to me how these negative numbers are generated and what is the logic behind it. Also, how can I avoid them (preferable not with BigInteger class). Danke!=)

This image shows what you're looking for. In your case it's obviously larger numbers, but the principle stays the same.
Examples of limits in java are:
int: −2,147,483,648 to 2,147,483,647.
long: -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807
In the image 0000, 0001 etc, shows the binary representation of the numbers.
EDIT: In project euler you often have to think of a way to work around the lagre numbers. The problems are designed with numbers that big so that you can't use the ordinary way of problem solving. However, if you find that you really need to use them, i suggest studying BigInteger anyway. You will find it useful in the long run, and it's not all that complicated. Here is a link with lots of understandable examples:
BigInteger Example

In mathematics numbers are infinite. However in computers they are not. There is MAX_VALUE for each int-like type: int, short, long. For example Integer.MAX_VALUE. When you try to increase number more than this value the number becomes negative. This way the internal binary representation of numbers work.
int i = Integer.MAX_VALUE;
i++; // i becomes negative.

Here's a two's complement representation for 2-bit integer: (U means Unsigned, S means Signed)
U | bits | S
---------------
0 | 00 | 0
1 | 01 | 1 \ overflow here:
2 | 10 | -2 / 1 + 1 = -2
3 | 11 | -1
Arithmetic is done mostly like in the unsigned case, modulo max(U) (4 in our case).
The logic is the same for bigger types. int in Java is 32 bit. Use long for 64 bits.

You are probably overflowing the size of your data type, since the most significant bit is the sign bit. I don't think that Java has unsigned data types, so you may try using a larger data type such as long if you want to hold bigger numbers than int. If you are still overflowing a long though, you're pretty much stuck with BigInteger.

Understanding signed numbers and complements in java

I have a 3 byte signed number that I need to determine the value of in Java. I believe it is signed with one's complement but I'm not 100% sure (I haven't studied this stuff in more than 10 years and the documentation of my problem isn't super clear). I think the problem I'm having is Java does everything in two's complement. I have a specific example to show:
The original 3-byte number: 0xEE1B17
Parsed as an integer (Integer.parseInt(s, 16)) this becomes: 15604503
If I do a simple bit flip (~) of this I get (I think) a two's complement representation: -15604504
But the value I should be getting is: -1172713
What I think is happening is I'm getting the two's complement of the entire int and not just the 3 bytes of the int, but I don't know how to fix this.
What I have been able to do is convert the integer to a binary string (Integer.toBinaryString()) and then manually "flip" all of the 0s to 1s and vice-versa. When then parsing this integer (Integer.parseInt(s, 16)) I get 1172712 which is very close. In all of the other examples I need to always add 1 to the result to get the answer.
Can anyone diagnose what type of signed number encoding is being used here and if there is a solution other than manually flipping every character of a string? I feel like there must be a much more elegant way to do this.
EDIT: All of the responders have helped in different ways, but my general question was how to flip a 3-byte number and #louis-wasserman answered this and answered first so I'm marking him as the solution. Thanks to everyone for the help!

If you want to flip the low three bytes of a Java int, then you just do ^ 0x00FFFFFF.

0xFFEE1B17 is -1172713
You must only add the leading byte. FF if the highest bit of the 3-byte value is set and 00 otherwise.
A method which converts your 3-byte value to a proper intcould look like this:
if(byte3val>7FFFFF)
return byte3val| 0xFF000000;
else
return byte3val;

Negative signed numbers are defined so that a + (-a) = 0. So it means that all bits are flipped and then 1 added. See Two's complement. You can check that the condition is satisfied by this process by thinking what happens when you add a + ~a + 1.
You can recognize that a number is negative by its most significant bit. So if you need to convert a signed 3-byte number into a 4-byte number, you can do it by checking the bit and if it's set, set also the bits of the fourth byte:
if ((a & 0x800000) != 0)
a = a | 0xff000000;
You can do it also in a single expression, which will most likely perform better, because there is no branching in the computation (branching doesn't play well with pipelining in current CPUs):
a = (0xfffffe << a) >> a;
Here << and >> perform byte shifts. First we shift the number 8 bits to the right (so now it occupies the 3 "upper" bytes instead of the 3 "lower" ones), and then shift it back. The trick is that >> is so-called Arithmetic shift also known as signed shift. copies the most significant bit to all bits that are made vacant by the operation. This is exactly to keep the sign of the number. Indeed:
(0x1ffffe << 8) >> 8 -> 2097150
(0xfffffe << 8) >> 8 -> -2
Just note that java also has a unsigned right shift operator >>>. For more information, see Java Tutorial: Bitwise and Bit Shift Operators.

For bitwise operations in Java, do I need to care that most numeric types in Java are signed?

This is a really basic question, but I've never fully convinced myself that my intuitive answer of "it makes no difference" is correct, so maybe someone has a good way to understand this:
If all I want to do with one of the primitive numeric types in Java is bitwise arithmetic, can I simply treat it as if it was an unsigned value or do I need to avoid negative numbers, i.e. keep the highest order bit always set to 0? For example, can I use an int as if it was an unsigned 32-bit number, or should I only use the lowest 31 bits?
I'm looking for as general an answer as possible, but let me give an example: Let's say I want to store 32 flags. Can I store all of them in a single int, if I use something like
store = store & ~(1 << index) | (value << index)
to set flag index to value and something like
return (store & (1 << index)) != 0
to retrieve flag index? Or could I run into any sort of issues with this or similar code if I ever set the flag with index 31 to 1?
I know I need to always be using >>> instead of >> for right shifting, but is this the only concern? Or could there be other things going wrong related to the two's complement representation of negative numbers when I use the highest bit?

I know I need to always be using >>> instead of >> for right shifting, but is this the only concern?
Yes, this is the only concern. Shifting left works the same on signed and unsigned numbers; same goes for ANDing, ORing, and XORing. As long as you use >>> for shifting right, you can use all 32 bits of a signed int.

There are legitimate reasons to use >> as well in that context (a common case is when making a mask that should be 0 or -1 directly, without having to negate a mask that is 0 or 1), so there is really no concern at all. Just be careful of what you're doing to make sure it matches your intent.
Operations that care about signedness (ie they have distinct signed and unsigned forms with different semantics) are:
right shift
division (unsigned form not available in Java)
modulo (unsigned form not available in Java)
comparisons (except equality) (unsigned forms not available in Java)
Operations that don't care about signedness are:
and
or
xor
addition
subtraction
two's complement negation (-x means ~x + 1)
one's complement (~x means -x - 1)
left shift
multiplication