😮 Programming Help Please!

yahwho · Feb 17th 2021

Hi folk!

So I am rewriting my dice system at the moment, optimizing along the way. In this case changing ints to bytes... and although it appears to be working fine (it is working). I'm getting the IDE underlining telling me something isn't right?

I've pulled out the "offending" code into a test class to show you here without all the unnecessaries.

You'll see I get a message saying "The constant value `null` used in comparison appears earlier in the chained if-else statement. The condition never evaluates to true"

Question; is the IDE wrong or am I wrong?

Minotorious · Feb 17th 2021

I will look at it in more detail later but take a look at this one for now, might fix it quickly: https://www.javatpoint.com/java-byte-compare-method

yahwho · Feb 17th 2021

Thanks Minotorious thing is the code compiles and works as expected. But the IDE gives me that strange warning.

I don't really want to use public static int compare(byte x, byte y) because that by nature is creating another int

byte 1 byte Stores whole numbers from -128 to 127

int 4 bytes Stores whole numbers from -2,147,483,648 to 2,147,483,647

I know I'm saving quite literally bytes of memory, this is more an exercise in optimisation.

Minotorious · Feb 17th 2021

hey so I was in a hurry before when I replied and basically wanted to also ask as to why you are want to use a byte instead of an int, you already mentioned that it is for optimisation but I am not sure if that is actually the case.

See this thread for example, it has a much better explanation than what I could write here about the topic: https://stackoverflow.com/ques…ead-of-int-and-float-inst

Also according to oracle's documentation: byte: The byte data type is an 8-bit signed two's complement integer. It has a minimum value of -128 and a maximum value of 127 (inclusive). The byte data type can be useful for saving memory in large arrays, where the memory savings actually matters. They can also be used in place of int where their limits help to clarify your code; the fact that a variable's range is limited can serve as a form of documentation.

Did some more testing now and even though I am not sure why the else if brings up that warning I know that switch doesn't so to be safe I would recommend using that instead (it is also faster in most cases)

Java

switch(b){
    case ONE:
        System.out.println("A");
        break;
    case TWO:
        System.out.println("B");
        break;
    case THREE:
        System.out.println("C");
        break;
    case FOUR:
        System.out.println("D");
        break;
    default: 
        System.out.println("X");
}

// or the new version thereof
switch(b){
    case ONE -> System.out.println("A");
    case TWO -> System.out.println("B");
    case THREE -> System.out.println("C");
    case FOUR -> System.out.println("D");
    default -> System.out.println("X");
}

Display More

yahwho · Feb 17th 2021

Hmm by the sounds of it I should just return to using the int then or ignore the warning. As I said, the code does compile and does work correctly. I just dislike seeing the IDE underlining "problems".

I suppose I'm interested in the "why" of the IDE message. Because as far as I can tell the message is wrong not me. Normally, I'm wrong, so there must be a reason for the message. 😂

The message refers to a null constant but the constants are declared with values, so not a null in sight.

If I do b ==1 b == 2 etc. I don't get the "warning message". It appears to be related to me using the named constants.

Minotorious · Feb 17th 2021

yep I tested too and it does compile and seem to work correctly but since the IDE error shows up I would try to either fix it or use something else instead just in case.

btw removing the final flags from the variables fixes the warning but no idea why tbh.

PS: not sure if you saw my message above after I last edited it but I would recommend using switch anyway as it is faster than if

yahwho · Feb 17th 2021

Quote from Minotorious

I would recommend using switch anyway as it is faster than if

Yeah I tend to write the statements as chained ifs and then use the IDE to convert to switch once they are completed. It's just I can follow the ifs easier when coding as it's what I'm used to 😁

Quote from Minotorious

btw removing the final flags from the variables fixes the warning but no idea why tbh.

Very strange! Maybe it is an IDE "bug"?

yahwho · Feb 17th 2021

Many thanks for your input Minotorious always appreciated

~~I think I may just remove the final modifier - they are private after all!~~

Scratch that! Removing the final then gives me even more warnings saying the fields can be final!

I'll just use ints

yahwho · Feb 17th 2021

Quote from yahwho

it's what I'm used to 😁

Java 1.2 was my starting block. Geeze that makes me feel old. One of the depot managers I work with was 7 years old back then

yahwho · Feb 17th 2021

Quote from Minotorious

I know that switch doesn't

Sorry Mino, misread your message. You are right, using the switch works without warning messages.

I'll chalk this one up to an IDE bug with "legacy" if statements

Guess, I'll have to force myself to use switches from the start instead of using the IDE to convert them

red51 · Feb 17th 2021

The warning seems to be incorrect, there is nothing wrong in using final bytes in if-else statements So it looks like a bug in the IDE... Which version of Netbeans do you use? I'm not getting this warning in Netbeans 8.2, but Netbeans 11.2 shows me the same warning

You could either ignore this warning or just disable it (by hitting the light bulb on the left side). Or just use ints in this case - unless you're creating big arrays, the memory difference is negligible

yahwho · Feb 17th 2021

Thank you red51 ! I thought I was going a bit nuts.

Strangely I am using 8.2 (NetBeans IDE 8.2 RC (Build 201609140952))

Quote from red51

just disable it (by hitting the light bulb on the left side)

Ah I didn't know about this. I've always assumed the `IDE knows best` and have done what it's said (like a zombie).

Quote from red51

the memory difference is negligible

Yeah I know it is in this situation, I mean what can you do with a couple of extra bytes (unless we're talking pizza!)? But what I am trying to do is learn to "always optimise" if I do it here when it doesn't really matter when it does matter it will be second nature.

Again, really appreciate the feedback

Participate now!