Java为什么这样做的问题已经有了答案，但由于我无意中发现了这个问题，希望找到一个更好的单行程序的替代品，因此在此分享我的解决方法:

public class SomethingComplicated extends SomethingComplicatedParent {

    private interface Lambda<T> {
        public T run();
    }

    public SomethingComplicated(Settings settings) {
        super(((Lambda<Settings>) () -> {

            // My modification code,
            settings.setting1 = settings.setting2;
            return settings;
        }).run());
    }
}

调用静态函数应该执行得更好，但如果我坚持将代码“置于”构造函数内部，或者如果我必须更改多个参数，并且发现定义许多静态方法不利于可读性，我会使用这种方法。

我完全同意，限制太严格了。使用静态辅助方法(如Tom Hawtin - tackline所建议的)或将所有“pre-super()计算”推入参数中的单个表达式并不总是可行的，例如:

class Sup {
    public Sup(final int x_) { 
        //cheap constructor 
    }
    public Sup(final Sup sup_) { 
        //expensive copy constructor 
    }
}

class Sub extends Sup {
    private int x;
    public Sub(final Sub aSub) {
        /* for aSub with aSub.x == 0, 
         * the expensive copy constructor is unnecessary:
         */

         /* if (aSub.x == 0) { 
          *    super(0);
          * } else {
          *    super(aSub);
          * } 
          * above gives error since if-construct before super() is not allowed.
          */

        /* super((aSub.x == 0) ? 0 : aSub); 
         * above gives error since the ?-operator's type is Object
         */

        super(aSub); // much slower :(  

        // further initialization of aSub
    }
}

正如Carson Myers所建议的那样，使用“尚未构造的对象”异常会有所帮助，但是在每个对象构造期间检查这个异常会减慢执行速度。我希望Java编译器能够更好地区分(而不是不合理地禁止if语句，但允许在形参中使用?-操作符)，即使这会使语言规范复杂化。

我已经通过链接构造函数和静态方法找到了解决这个问题的方法。我想做的是这样的:

public class Foo extends Baz {
  private final Bar myBar;

  public Foo(String arg1, String arg2) {
    // ...
    // ... Some other stuff needed to construct a 'Bar'...
    // ...
    final Bar b = new Bar(arg1, arg2);
    super(b.baz()):
    myBar = b;
  }
}

基本上是根据构造函数的形参构造一个对象，将对象存储在成员中，并将该对象的方法的结果传递到super的构造函数中。使成员为final也是相当重要的，因为类的性质是不可变的。注意，构造Bar实际上需要一些中间对象，因此在我的实际用例中，它不能简化为一行程序。

我最终做出了这样的工作:

public class Foo extends Baz {
  private final Bar myBar;

  private static Bar makeBar(String arg1,  String arg2) {
    // My more complicated setup routine to actually make 'Bar' goes here...
    return new Bar(arg1, arg2);
  }

  public Foo(String arg1, String arg2) {
    this(makeBar(arg1, arg2));
  }

  private Foo(Bar bar) {
    super(bar.baz());
    myBar = bar;
  }
}

合法的代码，它完成了在调用超级构造函数之前执行多条语句的任务。

这是官方回放: 从历史上看，this()或super()在构造函数中必须位于第一个。这 限制从来不受欢迎，被认为是武断的。有一个 一些微妙的原因，包括验证调用特殊， 这导致了这种限制。这些年来，我们已经解决了 这些都是虚拟机级别的，直到它变得实用 考虑取消这一限制，不只是对记录，而是对所有人 构造函数。

构造函数按照的顺序完成执行是有意义的 推导。因为父类不知道任何子类，任何 它需要执行的初始化与可能的初始化是分开的 子类执行任何初始化的先决条件。 因此，它必须首先完成它的执行。

一个简单的演示:

class A {
    A() {
        System.out.println("Inside A's constructor.");
    }
}

class B extends A {
    B() {
        System.out.println("Inside B's constructor.");
    }
}

class C extends B {
    C() {
        System.out.println("Inside C's constructor.");
    }
}

class CallingCons {
    public static void main(String args[]) {
        C c = new C();
    }
}

这个程序的输出是:

Inside A's constructor
Inside B's constructor
Inside C's constructor

我知道我有点晚了，但我已经用过几次这个技巧了(我知道这有点不寻常):

我用一个方法创建了一个泛型接口InfoRunnable<T>:

public T run(Object... args);

如果我需要在把它传递给构造函数之前做一些事情，我只需要这样做:

super(new InfoRunnable<ThingToPass>() {
    public ThingToPass run(Object... args) {
        /* do your things here */
    }
}.run(/* args here */));