使用更改的构造函数和“抽象”修饰符实例化相同 class 的不同版本

Question

I am writing a Java program which uses external libraries. I want to write my code so it is compatible with two different versions of one specific library.

The problem is, they changed a class (called Configuration in my example) to abstract, added an abstract method and changed the constructor from a no-argument to parameterized constructor. I am not able to influence the external library and I have to work with what I got.

Old class example

public class Configuration {

    public Configuration() {
        //Some code...
    }

    public static void main(String[] args) {
        Configuration conf = new Configuration();
        //Some code...
    }

}

New class example

public abstract class Configuration {

    public Configuration(boolean isCool, Map<String, String> entries, Object otherThing) {
        //Some code...
    }

    public abstract int doSomething();
    
    public static void main(String[] args) {
        Configuration conf = new MyConfiguration(false, null, new Object());
        //Some code...
    }

}

My implementation

public class MyConfiguration extends Configuration {
    
    public MyConfiguration(boolean isCool, Map<String, String> entries, Object otherThing) {
        super(isCool, entries, otherThing);
    }
    
    public MyConfiguration() {
        //needs super constructor call!?
    }

    public int doSomething() {
        //Some code...
        return -1;
    }

    public static void main(String[] args) {
        int version = 0;
        Configuration conf = version > 2 ? new MyConfiguration(false, null, new Object()) : new MyConfiguration();  
        //Some code...
    }

}

The no-argument constructor of my custom class MyConfiguration needs to call the constructor of the superclass in order to be compiled. However, the old class does not have a parameterized constructor, so I will run into an error if I do that.

• Are there any tricks how I don't have to call the super constructor?
• Maybe there is a way using reflection to do what I want?

Answer 1

Your example is a bit odd, as the new class example contains a reference to your MyConfiguration .

Generally, you're better off maintaining two versions of your MyConfiguration class or dropping support for the old version of that library. Or, consider not to use a library that makes such drastic changes.

For completeness, there is a hack addressing your literal question. Assuming that the class Configuration is not serializable as shown or at least, the old version isn't, you can utilize a specific Serialization behavior. When a serializable class extends a non-serializable class, deserializing an instance of it will cause the invocation of the superclass's default constructor.

So, the code utilizing it could look like:

public class MyConfiguration extends Configuration implements Serializable {
    public MyConfiguration(
        boolean isCool, Map<String, String> entries, Object otherThing) {
        super(isCool, entries, otherThing);
        // new version setup
    }
  
    private void readObject(java.io.ObjectInputStream in)
                                          throws IOException, ClassNotFoundException {
        // old version, Configuration's default constructor has been called
    }
  
    public static MyConfiguration create() {
        return new ByteArrayOutputStream() {
            MyConfiguration get() {
                final short numFields = 0;
                try {
                    Configuration.class.getConstructor(); // check for old version
                    DataOutputStream os = new DataOutputStream(this);
                    // using import static java.io.ObjectStreamConstants.*;
                    os.writeShort(STREAM_MAGIC);
                    os.writeShort(STREAM_VERSION);
                    os.write(TC_OBJECT);
                    os.write(TC_CLASSDESC);
                    os.writeUTF(MyConfiguration.class.getName());
                    os.writeLong(ObjectStreamClass.lookup(MyConfiguration.class)
                                                  .getSerialVersionUID());
                    os.write(SC_SERIALIZABLE);
                    os.writeShort(numFields);
                    os.write(TC_ENDBLOCKDATA);
                    os.write(TC_NULL);
                    os.flush();
                    return (MyConfiguration)new ObjectInputStream(
                           new ByteArrayInputStream(buf, 0, count)).readObject();
                }
                catch(NoSuchMethodException ex) {
                    // new version
                    return new MyConfiguration(false, Map.of(), null);
                }
                catch(IOException|ClassNotFoundException ex) {
                    throw new AssertionError(ex);
                }
            }
        }.get();
    }

    public int doSomething() {
        //Some code...
        return -1;
    }
}

This class can be compiled against the new version. The create() method first checks for the presence of the default constructor. When absent, ie running with the new version, the new constructor is called. Otherwise, it deserializes an instance with a stream having no data, so after the superclass's default constructor has been called, the readObject may perform the actual setup.

This all requires a lazy verifier that doesn't care for the incompatible constructors, as long as no-one tries to actually invoke the constructor. As said at the beginning, you're likely better off with other solutions.