The Math.Power of Bit Masks

 This article was originally published on JRoller on the 9/9/2011

Quite often, you would see lines like these in a program, for defining some bit masks:

  public static final int BIT_ZERO_MASK = 1;

  public static final int BIT_ONE_MASK = 2;

  public static final int BIT_TWO_MASK = 4;

  ...

  public static final int BIT_TWENTY_ONE_MASK = 2097152;

Don't pay too much attention to the constants name, imagine something more meaningful here. The point is, when the mask is encompassing more and more bits, you end up with cryptic numbers, like this 2097152 at the end. Often, the developer would add a comment, like this:

  public static final int BIT_TWENTY_ONE_MASK = 2097152; //2^21

Recently (and that's the reason for my post), I spotted this attempt at giving a meaning to these numbers:

  public static final int BIT_ZERO_MASK = Math.pow(2, 0);

  public static final int BIT_ONE_MASK = Math.pow(2, 1);

  public static final int BIT_TWO_MASK = Math.pow(2, 2);

  ...

  public static final int BIT_TWENTY_ONE_MASK = Math.pow(2, 21);

Although mathematically correct, it seemed to me a bit overkill for the low order bits. Also, using a general mathematical method for bit calculation shows that the developer has not much idea about the existing bit operations existing natively in Java. So if you really want to give a meaning to those numbers, so the next developer would understand, I suggest rather using a bit shifting operation, like this:

  public static final int BIT_TWENTY_ONE_MASK = 1 << 21;

And if you are one of those lucky guys who can already use Java 7 at work, there is this even nicer solution:

  public static final int BIT_ZERO_MASK = 0b000_0001;

  public static final int BIT_ONE_MASK = 0b000_0010;

  public static final int BIT_TWO_MASK = 0b000_0100;

  ...

  public static final int BIT_TWENTY_ONE_MASK = 0b00010000_00000000_00000000;

Nowadays, Java 7 syntax is hopefully supported everywhere...

JComboBox breaks on Exception in ActionListener

This article was posted originally on JRoller on the 7/9/2011. 

We had a bug reported to us the other day, when one combobox suddenly stopped working. You could select any item, the other components would not react to the selection. Looking through the logs, we noticed a nice NullPointerException, but only one. It seems like the first exception in our ActionListener was breaking something in our combobox. So I looked at the source code of JComboBox, and here is what I found: 

    protected void fireActionEvent() {

    if (!firingActionEvent) {

    firingActionEvent = true;

    // Loop through Listeners

    //call to listener.actionPerformed(e)

    firingActionEvent = false;

    }    

    }

Notice the firingActionEvent boolean, that is here to prevent an infinite loop of event. If an exception occurs in the listener, the boolean firingActionEvent remains at true, and no action will ever be processed. I filed a bug report to Oracle, so that they add a try/finally block to ensure the boolean goes back to false at the end of the method.

Looking a bit further in the code, I could find the same pattern applied in the setSelectedItem() method:

     // Must toggle the state of this flag since this method    

    // call may result in ListDataEvents being fired.

    selectingItem = true;

    dataModel.setSelectedItem(objectToSelect);

    selectingItem = false;

 I guess it would be a good idea to apply the same fix here.

UPDATE: Bug ID: 7087720

Although I could not find any trace of this bug ID, I could check in Java's source code that the fireActionEvent is indeed now enclosed in a try/finally block. However, there is not such block even today around the selectingItem boolean.

Found Archives of my Old Blog!

Eons ago, I started blogging about Java on JRoller.com. Unfortunately, the company running the site disappeared. And being really lazy, I lost all my articles. About 5 years ago, I restarted blogging on Blogger, feeding first my articles from my talk in Devoxx "The Awakening of the Threads", then adding new material as it came, mainly on Python and AWS. But today, completely by accident, I found that there is an archive of 73 of my old blog articles dating from 2011 to 2017 on rssing. So I will try to re-post them here as time allows, travelling into my past, and rediscovering old java stuff.

Warnings on SQS endpoint URL while mocking with moto

 We have many unit tests using moto library to mock calls to boto3 to access AWS services.They all work fine, except for a warning on the use of this fixture:

@fixture(scope='function')

def sqs():

    with mock_sqs():

        yield boto3.client('sqs', region_name=AWS_REGION)

This is one of the correct ways of using moto mocks. But only this mock on SQS shows the following warning:

FutureWarning: The sqs client is currently using a deprecated endpoint: eu-central-1.queue.amazonaws.com. In the next minor version this will be moved to sqs.eu-central-1.amazonaws.com. See https://github.com/boto/botocore/issues/2705 for more details.

 Now, our Sonar is considering these warnings as errors, and leads our build to fail. As explained by the issue, the warning comes from the use of a deprecated attribute called sslCommonName. I didn't dive into the moto library, but there might be a way to avoid the use of this attribute. The easisest way to stop using it, is to add this environment variable to our test code:

import os

os.environ['BOTO_DISABLE_COMMONNAME'] = 'true'

This skips completely the use of the deprecated attribute.