Java design approach for "duplicated" class that are identical, except the import sources are different

In this situation, I would create an interface which would have the same signatures as the Message and CoolClass. Then you would simply create two implementations, one for Google and one for Microsoft. ClassA and ClassB then collapse into a single class that takes an instance of this interface and calls the same methods it does now with the exception of calling the CoolClass constructor. That could be handled inside the wrapper classes i.e., it would create the object and passes it to the message instance.

The main potential dowside of this is if there are many methods that your ClassA/B need to call, you will need a lot of boiler-plate to wrap all of those. You can probably generate them with an IDE.

Here's a rough example as requested:

package packageA;

public interface MessageX {
    void setType(String typeStr);
    void createCoolObj();
   //etc same for other  methods
}

// ................... //

import com.project.google.cool.Message;
import com.project.google.cool.CoolClass;
import packageA.MessageX;

class GoogleMessage implements MessageX {
    private final Message message;

    GoogleMessage(Message msg) {
        this.message = msg;
    }

    void setType(typeStr) {
        this.message.setType(typeStr);
        
    }
    
    void createCoolObj() {
        this.message.setObj(new CoolClass());
    }
    
    //etc same for other  methods
}

// ................... //

import com.project.microsoft.cool.Message;
import com.project.microsoft.cool.CoolClass;
import packageA.MessageX;

class MicrosoftMessage implements MessageX {
    private final Message message;

    MicrosoftMessage(Message msg) {
        this.message = msg;
    }

    void setType(typeStr) {
        this.message.setType(typeStr);
        
    }
    
    void createCoolObj() {
        this.message.setObj(new CoolClass());
    }
    
    //etc same for other  methods
}

// ................... //

package packageB;

import packageA.MessageX;

public class ClassX {

   // this is a static class

   public static void method(MessageX m) {
       m.setType("cool message");
       m.createCoolObj();
   }
}

The classes from com.project.google/microsoft are autogenerated and there's nothing I can do to change them, including renaming.

I am sure this is too pessimistic. You can surely write your own tiny generator script which takes the classes' source code after they were autogenerated and applies some changes to the code, like adding different namespaces around them, or changing the name. Then integrate that script into the build process.

That should to the trick.

Take a step back, and ask yourself:

Is the code unrelated, and thus the automation reporting it as evil code duplication the problem?

Or do both specimens solve the same problem and thus are identical, and they belong to the same project, meaning they should be folded?

It's clearly the former, as the google and microsoft projects are independent. On top of that, auto-generated code being similar up to identical should not be too surprising.

In the end, you just have to curb the automation. See https://docs.sonarsource.com/sonarqube/8.9/project-administration/narrowing-the-focus/#ignore-duplications for reigning it in.