Use Java polymorphism to new corresponding object (StringBuffer or StringBuilder)

Actually, I want to use JAVA polymorphism to design a function that it can return a StringBuffer or StringBuilder for me depends on different scenario. My error code is

public class Builder{
    private boolean threadSafe;
    public Builder(boolean threadSafe) {
        this.threadSafe = threadSafe;
}
    public String buildMsg(String name, int age) {
       AbstractStringBuilder asb;
       asb = threadSafe ? new StringBuffer() : new StringBuilder();
       return asb.append("name: ").append(name).append(", age: ").append(age).toString();
}
}

The code can not be compiled. The error message is 'java.lang.AbstractStringBuilder' is not public in 'java.lang'. Cannot be accessed from outside package.
So I try another method, use Appendable instead of AbstractStringBuilder, it still doesn't work.
Until, I write code like this:

public class Builder{
    private boolean threadSafe;
    public Builder(boolean threadSafe) {
        this.threadSafe = threadSafe;
}
    public String buildMsg(String name, int age) {
       if (threadSafe) {
        StringBuffer sb = new StringBuffer();
        return sb.append("name: ").append(name).append(", age: ").append(age).toString();
    } else {
        StringBuilder sb = new StringBuilder();
        return sb.append("name: ").append(name).append(", age: ").append(age).toString();
    }
}
}

The code is obviously redundant. So how can I use polymorphism to fix my code.
(My English is not very well, hope you understand well)

StringBuffer - though thread safe - is only warranted if you would allow different threads to mix things up:

Thread1:

sb.append("a").append("b").append("\n");

Thread2:

sb.append("c").append("d").append("\n");

Might result in:

"acb\nd\n"

So with StringBuffer you might need:

sb.append("a" + "b" + "\n");

which is ridiculous for obvious reasons. Also error prone when violated,
as an erroneous sb.append(...).append(...) might go undetected.

So it is preferable to use a thread-safe logger or your own synchronisation (around a StringWriter maybe?).

Also as these classes are final, it is really a dead-end.

I would to advice you to just do

public String buildMsg(String name, int age) {
    StringBuilder sb = new StringBuilder();
    sb = sb
        .append("name: ")
        .append(name)
        .append(", age: ")
        .append(age);
    return sb.toString();
}

since there are no problems regarding multi-threading in this code. Also this is exactly what the StringBuilder class is for.

You should use the StringBuffer if multiple threads have access to the same StringBuffer object, but since you create the object and at the end lose the reference to it, no other thread can access the object.

However, to answer the question in the title.
If you have two types that both implement the method Foo but without a common interface, like:

public class A {
    public Res Foo(Args args) { ... }
}

public class B {
    public Res Foo(Args args) { ... }
}

Then you will always need some casing to distinguish between both version of Foo.
But you can implement a Adapter or Wrapper type for both types, like:

public abstract WrapperBase {
    public abstract Res Foo(Args args);

    public static WrapperBase Wrap(A a) {
        return new AWrapper(a);
    }
    public static WrapperBase Wrap(B b) {
        return new BWrapper(b);
    }
    // or
    public static WrapperBase Wrap(Object obj) {
        if (obj instanceof A) {
            return new AWrapper((A)obj);
        } else if (obj instanceof B) {
            return new AWrapper((B)obj);
        } else {
            throw new Exception("Can not be wrapped");
        }
    }
}

class AWrapper extends WrapperBase {
    private A a;
    public AWrapper(A a) { this.a = a; }

    @override
    public Res Foo(Args args) { return a.Foo(args); }
}

class BWrapper extends WrapperBase {
    private B b;
    public BWrapper(B b) { this.b = b; }

    @override
    public Res Foo(Args args) { return b.Foo(args); }
}

The drawback of this is this can get out of hand if you have a larg amount of methods that you want to wrap up.