5 Replies Latest reply: Nov 15, 2006 6:25 PM by 796440 RSS

    Public Enum Compiler Error

    807607
      /*
      package com.validmanufacturing.antiswaymodule;
      
      import org.openide.NotifyDescriptor;
      import org.openide.DialogDisplayer;
      import java.lang.Short;
      
      /**
       *
       * @author nathani
       */
      public enum CANAddress {
      
          //IF ANY OF THE HEX VALUES CHANGE, CANMsg.java MUST BE CHANGED CORESPONDINGLY
          
          CAN_CONTROLLER_ID     (0x00,"00"),
          
          CAN_REAR_SENSOR_ID    (0x00,"00"),
          CAN_FRONT_SENSOR_ID   (0x01,"00"),
          CAN_IO_MODULE_ID      (0x02,"02"),
          CAN_DAMPING_MODULE_ID (0x03,"03"),
          CAN_ANTISWAY_MODULE_ID(0x04,"04"),
          
          CAN_ID_NON_SPECIFIC   (0xFF,"FF");
      
          private short hexVal;
          private String stringVal;
          
          //Private Constructor, not accessible.
          private CANAddress(short hexVal, String stringVal){
              this.hexVal = hexVal;
              this.stringVal = stringVal;
          }
          
          public void changeAddress(String address) {
              if(address.length() != 2) {
                  String msg = "changeAddress was passed an illegal string length";
                  NotifyDescriptor d = new NotifyDescriptor.Message(msg, NotifyDescriptor.INFORMATION_MESSAGE);
                  DialogDisplayer.getDefault().notify(d);
                  return;
              }
              this.stringVal = address;
              this.hexVal = Short.parseShort(address,16);
          }
      
          public void changeAddress(Short address) {
              if((address < 0) || (address > 255)) {
                  String msg = "changeAddress was passed an illegal short value";
                  NotifyDescriptor d = new NotifyDescriptor.Message(msg, NotifyDescriptor.INFORMATION_MESSAGE);
                  DialogDisplayer.getDefault().notify(d);
                  return;
              }
              this.hexVal = address;
              this.stringVal = Integer.toHexString((int)address);
          }
          
          /**
           * Returns the numeric value of this CANHeader in the form of a short
           *
           * @return  The equivalent short in byte form
           */
          public short numericVal() {
              return hexVal;
          }
          
          /**
           * Returns the string value of this CANHeader in the form of a string
           *
           * @return  The equivalent string value of the CANHeader
           */
          public String stringVal() {
              return stringVal;
          }    
      }
      This is my code. The compiler throws errors at me for each and every constructor. I have 3 separate enum types and the compiler doesn't like any of them. I tried importing every library I can think of. Below is the compiler generated error:

      C:\Projects\NetBeansWorkspace\NewellAntiSwayApplication\NewellAntiSway\AntiSwayModule\src\com\validmanufacturing\antiswaymodule\CANAddress.java:25: cannot find symbol
      symbol : constructor CANAddress(int,java.lang.String)
      location: class com.validmanufacturing.antiswaymodule.CANAddress
      CAN_CONTROLLER_ID (0x00,"00"),

      Thanks, any help is appreciated.
        • 1. Re: Public Enum Compiler Error
          796440
          0x00 is an int (All integer literals in Java are ints) but the c'tor takes a short

          Either pass ((short)0x00, "whatever") to the c'tor, or change the c'tor to use an int.

          If you look closely at the error message, you'll see that it's telling you that you don't have a c'tor that takes an int. You can then look at your c'tor and say, "Oh, yeah, it expects a short."

          At that point you might be stumped, because it's not obvious that 0x00 is always an int. But you should at least read the messages closely enough and think hard enough about it to get that far.
          • 2. Re: Public Enum Compiler Error
            807607
            Thanks, that's what it was. You could ease up a little on me though, this is my first java app in over 4 years and even then that was only a 4 month course and we of course didn't use netbeans.

            Anyhow, is it better to use ints where possible, do shorts have better or equal (or worse? ) performance than ints?

            The reason why i used shorts is because i actually only need byte holders for each communication byte, however java doesn't have a byte varriable that is actually a byte (0-255).
            • 3. Re: Public Enum Compiler Error
              796440
              Thanks, that's what it was. You could ease up a
              little on me though, this is my first java app in
              over 4 years and even then that was only a 4 month
              course and we of course didn't use netbeans.
              Not trying to beat up on you. Just trying to encourage you to dig in a little bit more. People seem to be afraid of error messages and throw up their hands before spending much time reading and thinking about them, but they DO actually contain useful information, and it's not all that cryptic most of the time. :-)


              Anyhow, is it better to use ints where possible, do
              shorts have better or equal (or worse? ) performance
              than ints?
              I would only bother with shorts if you knew for certain that memory was going to be tight and shorts would make a significant difference. Even then, it's possible that shorts will be as big as ints in hardware--most modern desktop and laptop CPUs use 32 bits as their basic word size, and are optimized for doing things in chunks that big, so you might not save any physical memory, and you certainly won't save any clock time (unless maybe you're on an embedded device with a word size of 16 bits).


              The reason why i used shorts is because i actually
              only need byte holders for each communication byte,
              however java doesn't have a byte varriable that is
              actually a byte (0-255).
              Java's bytes are actually bytes. They're signed bytes. What you're talking about there is an unsigned byte. Do you need the numerical value? Will you be doing arithmetic on them? If not, then you can use bytes.
              • 4. Re: Public Enum Compiler Error
                807607
                I would only bother with shorts if you knew for
                certain that memory was going to be tight and shorts
                would make a significant difference. Even then, it's
                possible that shorts will be as big as ints in
                hardware--most modern desktop and laptop CPUs use 32
                bits as their basic word size, and are optimized for
                doing things in chunks that big, so you might not
                save any physical memory, and you certainly won't
                save any clock time (unless maybe you're on an
                embedded device with a word size of 16 bits).
                That's what I figured.
                Java's bytes are actually bytes. They're signed
                bytes. What you're talking about there is an unsigned
                byte. Do you need the numerical value? Will you be
                doing arithmetic on them? If not, then you can use
                bytes.
                No arithmetic, I would just prefer a variable that is bounded like my parameter is bounded, then I wouldn't have to check to make sure it's greater than zero and less than 256 every time I use the variable, i could just know that it is in range. But so goes, working with ints seems to be a lot better anyway (there are functions for converting them to hex character strings and such).

                (I'm a firmware designer, hence the naivety).
                • 5. Re: Public Enum Compiler Error
                  796440
                  I wouldn't call it naievete. You're just used to a different environment, different conventions, constraints, etc.


                  I'm not sure what you mean by this though: I would just prefer a variable that is bounded like my parameter is bounded, then I wouldn't have to check to make sure it's greater than zero and less than 256 every time I use the variable, i could just know that it is in range.

                  If the variable is a byte, its numerical value will alway be in -128..127, and its hex value will always be in 0x00..0xFF.

                  And: anyway (there are functions for converting them to hex character strings and such).

                  Not sure how that's relevant.


                  If ints work for you and are simpler, then by all means use them. I just want to make sure you're not having any misconceptions.