Compile error... what's wrong?


    Feb 19 2009 | 5:55 pm
    I'm using some bitwise operators that would be dead simple in plain-vanilla C but that generate compile errors in Java. I understand that Java does some things differently than C, but I'm puzzled about this one. Although I've found an alternative way to do what I need, can anyone explain what's going on?
    I write:
    -------- byte statusByte = buf[kPMHeaderLen + 2]; // buf is a byte[], the index is in range, all is well
    outlet(4, (statusByte & 0x08) ? 3 : 0); // Looks OK to me. // Believe it or not, it does something useful. --------
    The mxj Java compiler responds, however:
    /Applications/MaxMSP 4.6/Cycling '74/java/classes/seitecIPMasterPollState.java[ 202 ] incompatible types found : int required: boolean
    outlet(4, (statusByte & 0x08) ? 3 : 0); ......................^
    [The carat appears under the ampersand with a monospace font.]
    What is wrong with using a bitwise AND in this context? I can see the compiler says it wants a boolean, but if you can't do bitwise operations on any integer type, I'm left wondering just what the operator is good for in Java.
    FWIW, this is with Max/MSP 4.6.3, Mac OS 10.5.6, JavaVM 12.0.2. Anything else worth knowing?
    As well as examing bit 3, in real life I need to check bits 3, 2, and 1. In C I would do it as above. What's the most idiomatic Java way do to this stuff?

    • Feb 19 2009 | 7:14 pm
      I have NO idea if this is on the right track - totally guessing -- perhaps you have to create a Byte as opposed to a byte, and operate on that?
      Dan
      On 2/19/09 12:55 PM, "Peter Castine" wrote:
      > > I'm using some bitwise operators that would be dead simple in plain-vanilla C > but that generate compile errors in Java. I understand that Java does some > things differently than C, but I'm puzzled about this one. Although I've found > an alternative way to do what I need, can anyone explain what's going on? > > I write: > > -------- > byte statusByte = buf[kPMHeaderLen + 2]; > // buf is a byte[], the index is in range, all is well > > outlet(4, (statusByte & 0x08) ? 3 : 0); > // Looks OK to me. > // Believe it or not, it does something useful. > -------- > > The mxj Java compiler responds, however: > > /Applications/MaxMSP 4.6/Cycling > '74/java/classes/seitecIPMasterPollState.java[ 202 ] incompatible types > found : int > required: boolean > > > outlet(4, (statusByte & 0x08) ? 3 : 0); > ......................^ > > [The carat appears under the ampersand with a monospace font.] > > What is wrong with using a bitwise AND in this context? I can see the compiler > says it wants a boolean, but if you can't do bitwise operations on any integer > type, I'm left wondering just what the operator is good for in Java. > > FWIW, this is with Max/MSP 4.6.3, Mac OS 10.5.6, JavaVM 12.0.2. Anything else > worth knowing? > > As well as examing bit 3, in real life I need to check bits 3, 2, and 1. In C > I would do it as above. What's the most idiomatic Java way do to this stuff? > > > -- > ---- > Peter Castine > Litter Power: > iCE Tools:
      -- Dan Nigrin - Defective Records 202 Hack / PC-1600 User / VSTi Host / Jack OS X / Major Malfunction http://defectiverecords.com http://jackosx.com
    • Feb 19 2009 | 7:17 pm
      Nope, that wasn't it - but it seems like you can only do bitwise operations on ints:
      Dan
      On 2/19/09 12:55 PM, "Peter Castine" wrote:
      > > I'm using some bitwise operators that would be dead simple in plain-vanilla C > but that generate compile errors in Java. I understand that Java does some > things differently than C, but I'm puzzled about this one. Although I've found > an alternative way to do what I need, can anyone explain what's going on? > > I write: > > -------- > byte statusByte = buf[kPMHeaderLen + 2]; > // buf is a byte[], the index is in range, all is well > > outlet(4, (statusByte & 0x08) ? 3 : 0); > // Looks OK to me. > // Believe it or not, it does something useful. > -------- > > The mxj Java compiler responds, however: > > /Applications/MaxMSP 4.6/Cycling > '74/java/classes/seitecIPMasterPollState.java[ 202 ] incompatible types > found : int > required: boolean > > > outlet(4, (statusByte & 0x08) ? 3 : 0); > ......................^ > > [The carat appears under the ampersand with a monospace font.] > > What is wrong with using a bitwise AND in this context? I can see the compiler > says it wants a boolean, but if you can't do bitwise operations on any integer > type, I'm left wondering just what the operator is good for in Java. > > FWIW, this is with Max/MSP 4.6.3, Mac OS 10.5.6, JavaVM 12.0.2. Anything else > worth knowing? > > As well as examing bit 3, in real life I need to check bits 3, 2, and 1. In C > I would do it as above. What's the most idiomatic Java way do to this stuff? > > > -- > ---- > Peter Castine > Litter Power: > iCE Tools:
      -- Dan Nigrin - Defective Records 202 Hack / PC-1600 User / VSTi Host / Jack OS X / Major Malfunction http://defectiverecords.com http://jackosx.com
    • Feb 19 2009 | 7:20 pm
      Hello Peter,
      I'm not in a position to test this at the mo, but the issue might be with having an int before the '?'. That is, you might have to explicitly say: (w & x == 0) ? y : z
      Which is the sort of thing that irritates C people about Java, and makes Java people quiver in fear about C :)
      -- O
      Peter Castine wrote: > I'm using some bitwise operators that would be dead simple in > plain-vanilla C but that generate compile errors in Java. I > understand that Java does some things differently than C, but I'm > puzzled about this one. Although I've found an alternative way to do > what I need, can anyone explain what's going on? >
    • Feb 19 2009 | 7:20 pm
      It's complaining that the whole (statusByte & 0x08) results in an int, but you need a boolean for the test.
      outlet(4, (statusByte & 0x08) != 0 ? 0 : 3);
      On Thu, Feb 19, 2009 at 06:55:54PM +0100, Peter Castine wrote: > > I'm using some bitwise operators that would be dead simple in plain-vanilla C but that generate compile errors in Java. I understand that Java does some things differently than C, but I'm puzzled about this one. Although I've found an alternative way to do what I need, can anyone explain what's going on? > > I write: > > -------- > byte statusByte = buf[kPMHeaderLen + 2]; > // buf is a byte[], the index is in range, all is well > > outlet(4, (statusByte & 0x08) ? 3 : 0); > // Looks OK to me. > // Believe it or not, it does something useful. > -------- > > The mxj Java compiler responds, however: > > /Applications/MaxMSP 4.6/Cycling '74/java/classes/seitecIPMasterPollState.java[ 202 ] incompatible types > found : int > required: boolean > > > outlet(4, (statusByte & 0x08) ? 3 : 0); > ......................^ > > [The carat appears under the ampersand with a monospace font.] > > What is wrong with using a bitwise AND in this context? I can see the compiler says it wants a boolean, but if you can't do bitwise operations on any integer type, I'm left wondering just what the operator is good for in Java. > > FWIW, this is with Max/MSP 4.6.3, Mac OS 10.5.6, JavaVM 12.0.2. Anything else worth knowing? > > As well as examing bit 3, in real life I need to check bits 3, 2, and 1. In C I would do it as above. What's the most idiomatic Java way do to this stuff? > > > -- > ---- > Peter Castine > Litter Power: > iCE Tools:
    • Feb 19 2009 | 11:54 pm
      I concur ;-) In C, as you know, this would work, in Java it needs to be something that can be converted to boolean state so you need to help it for that purpose.
      Cheers, ej
    • Feb 20 2009 | 12:04 am
      Quote: owen wrote on Thu, 19 February 2009 20:20 ---------------------------------------------------- > I'm not in a position to test this at the mo, but the issue might be > with having an int before the '?'. That is, you might have to explicitly > say: > (w & x == 0) ? y : z > > Which is the sort of thing that irritates C people about Java, and makes > Java people quiver in fear about C :) ----------------------------------------------------
      If that's what it is, I could live with it. I grew up with Pascal-style typechecking and am still not entirely comfortable with C's casual use of integers where there *ought* to be a boolean.
      OTOH, I've gotten used to it enough to use the idiom in the context of (x ? y : z) statements, which are an infernal C idiosyncrasy anyway.
      But if that's it, I wonder why the error message seemed to flag the ampersand, and not the end of the integer expression. I'll try tomorrow.