JEP draft: No longer require super() and this() to appear first in a constructor

When the rule was made, it would not be uncommon to write Java in, say, Emacs. Nowadays it's practically guaranteed everyone writing Java will be using a fully fledged IDE (or if you did stick with Emacs, there are now packages to basically turn it into a Java IDE for all intents and purposes), so needing to remember the exact rule as you type is far less of a concern, as you get instant feedback vs feedback 10 minutes down the line when you try to compile your code.

Can you expand on this. does this change make it easy to communicate why a program was rejected?

Is there actually a tension there?

What's pushing for more possible correct programs?

Isn't it already possible to choose which constructor to overload?

Totally agree, and I also love that so much thought and consideration goes into how the platform gets improved over time. Doing it "right" means taking so many things into account -- many of which are subtle -- and picking the right tradeoffs. Hats off to the people quietly doing the deep work which makes everyone's lives better.

I guess Java caught up, but for a long time it was just too restrictive.

C# was so much more joy to program in for a long time, even though they were equivalent languages in safety/speed tradeoff.

I wish the JEP showed which company was behind it. It has an author but it’s just a username not a full name and doesn’t indicate the company they work for.

There's something to be said for making sure the parent constructor is the first call made. It means any method you call in the current constructor will work correctly or obviously be your fault, not the parent class's.

Yes, in your particular case, the compiler could figure out that you're not using "this," but you can only make a compiler so clever.

Yes, though in that case you can use

  public A(String s) {
    this(helpfulName(s));
  }

with a static method.

Yaeh, you end up having to write crazy one-liners to initialize some other object to pass to your super class.

Why are so many people writing something like "I haven't written java in a long time, but..." on Java related posts on HN? Is this trendy or what?

You can call methods from constructors, including methods overridden in unknown subclasses, or methods in superclasses whose implementation may change later, which complicates things. You can also pass this to foreign code from a constructor, which in turn may call arbitrary methods and/or access fields on the instance.

Java supports dynamic libraries. As long as the API hasn't changed, your class may be initialized using a different version of its superclasses than it had when it was compiled, so checking statically is not that valuable. And this is not just a theoretical possibility, it's quite common for Java libraries to be distributed in bytecode format, and to be run on various versions of the JVM - so at least any library which subclasses any standard library class is going to often run with various versions of its superclass.

You still have the problem that the super class might not be fully initialized when the overridden method is executed.

Calling overridable methods from a constructor is just a bad idea in general.

But that in itself is an anti-pattern isn't it? A Constructor should be the minimal amount of work to create a valid set of object data. Other work should not be hidden in the Constructor otherwise it fails the principle of surprising functionality.

As an example of where I have seen this used, your File object could open the file and truncate it in the constructor but this is non-obvious, it would be better to have another method like Init() or perhaps a factory method where calling e.g. File.OpenForWriting() is obvious.

I know not everyone has the same requirements but I can't remember a single time where this restriction was a problem for me in C#, the feature sounds like it will encourage worse behaviour.

> One more way to bypass this requirement is to add a private static method

This doesn’t work if it requires multiple arguments to be generated with common code, unless you’re okay with effectively running that common code twice, which in turn is problematic when it has side-effects (like logging). See https://news.ycombinator.com/item?id=34482908 for an alternative way of solving this.

Yes, inability to modify variables from the lambda is extremely frustrating and makes exactly zero sense as compiler can always convert variable to a wrapper object on the heap. I guess this is another improvement for the future. Too bad that Java's future is Lisp's infancy.

> Another way to write the constructor, that works in current Java, might be to use the Streams API to make sure we are coding to the explicit and implicit design contracts:

    public FilteredSet(Predicate<? super E> filter, Collection<? extends E> elems) {
        super(checkElems(elems).stream()
                               .filter(filter)
                               .collect(Collectors.toList());
        this.filter = filter;
    }

I think you misunderstood the problem. Assuming you leave the add() method implemented exactly as in the JEP, this will still fail with the same NullPointerException, since super() will still call FilteredSet.add() before this.filter is provided.

The only way to avoid it without this JEP is to do something like this:

  public FilteredSet(Predicate<? super E> filter, Collection<? extends E> elems) {
        super(elems.size()); //initialize super as an empty HashSet, but with the proper capacity
        this.filter = filter;
        this.addAll(elems); //this will call this.add(), but this.filter will now be set
    }

Your description of the contract/purpose of HashSet.add() is also just wrong. The clear intention of the Java standard library designers is that any element added to the set, either by the constructor or later, is added using HashSet.add() - they are explicitly calling that method from the built-in HashSet constructor [0]. Also, it's an obvious design choice, while your proposal is just weird: why would you ever want to duplicate the implementation of adding elements between initialization and later modification?

In general, you seem to be arguing for keeping the language more clunky. Why does `7 instanceof int` or `switch(number)` or avoiding a new method definition just to check a variable before calling a constructor hurt the identity of Java in any way? Sure, all of these things could be achieved in various ways before as well, but always in a more clunky way. Many of these JEPs are pure cleanup of bizarre idiosyncrasies of Java - the precise opposite of how C++ is evolving.

[0] https://github.com/openjdk/shenandoah/blob/master/src/java.b... - note that the doc is not very explicit, but it does say that `c` is "the collection whose elements are to be placed into this set", not something like "the collection whose elements will be used to initialize this set".

As someone who has been using Java since 1.0, I welcome these little improvements but agree that the language is now a mess for a beginner. All of the little rules and corners make sense to someone who learned them gradually. To a beginner, they must seem nonsensical and intimidating.

Why does super need to go in a specific position? Isn’t “super calls the parent classes constructor” simpler than “ super calls the parent classes constructor and it must be the first statement in the child constructor.”

super() was never forced to be placed at the start.

Every expression that you call in super was called before it, obviously.

So you always was writing code like

    MyCtor() {
      int arg1 = calcArg1();
      int arg2 = calcArg2();
      super(arg1, arg2);
    }

And the fact that you wasn't able to write this code literally was confusing for every beginner.

Right now the rule is simple as it should be: you can't read `this`, explicitly or implicitly, before calling `super()`. Now it actually makes sense.

The only somewhat confusing thing about this JEP is that you can initialize fields before calling super. I don't see why this is needed and I'd treat it as code smell. I've read that example and I don't think that it's convincing. This code should be rewritten.

This is why I prefer the way C# did this:

    class Base {
        public int Count { get; set; } = 0;
    
        public Base(int counter) {
            Count = counter;
        }
    }
    
    class Sub : Base {
        public Sub(int number) : base(number) {
            System.Console.WriteLine($"This is the sub class constructor with {number} as an argument");
        }
    
        public Sub() : this(123) {
            System.Console.WriteLine("This is the sub class constructor with no arguments");
        }
    }

Rather than being a magical function call at a magical position, the call to the super constructor is part of a special bit of syntax that explicitly tells you what kind of call is being done. You can't call any method at that point of the program, you have to call a constructor by its special reference.

It also makes the reason why you can do `super(fn1(), fn2())` but not extract those two calls to variables; these calls are considered to be part of a different part of the execution flow than the rest of the constructor. A simple `base()` can be left out, of course; it only matters in cases where you need a specific super constructor.

Arbitrarily placing those bits of code at the beginning of the constructor is also confusing for a beginner. I think the way Kotlin does it (special syntax for this) is less confusing.

This is just a refinement of the original specification...

I went from using Java to Kotlin at work, and I hate the “?.” notation. I’m sure it’s nice when used correctly, but it seems that people just use it everywhere and now the program went from “When I do x and it crashes” -> “When I do x nothing happens”. It hides errors and makes debugging more difficult.

I love null being apart of the type system, but the safe call operator seems like a huge step backwards.

You and me both. Java programmers don't seem to want it for some reason.

However, Java has instead received `Optional` (in the shape of `Optional.ofNullable(variable).map(Clazz::getProperty).map(Clazz2::getProperty).orElseGet( () -> 42 );` rather than `variable?.getProperty()?.getProperty() ?: 42`).

I don't know what the JCP EC was thinking going for this approach rather than the much more readable, modern approach, but I can't be too surprised about a language designed by committee refusing such improvements.

> (...) instead of this kind of stuff that really doesn't improve life all that much for most development

There are comments in this very discussion praising this change due to how this stuff really improves their life as a developer.

Anyway, can you pass the link to your JEP with a proposal for "?." ?

This is useless operator. I can't imagine many places where it could be useful.

It's because if you had

    final Foo foo;
    try {
        foo = bar(baz);
        otherFunction();
    } catch (SomeException ex) {
        foo = SOME_DEFAULT;
    }

that'd truly be invalid - the first assignment could run, otherFunction errors, and foo gets reassigned. Even if SomeException is a checked exception that otherFunction doesn't declare in its throws, it's still possible to get the jvm to throw it, and things do rely on that - see Lombok @SneakyThrows.

So the only case that such final field assignment can work is if it's the last evaluated expression in the try case (plus some guaranteed non-throwing arithmetic or boring assignments), which is quite the weird thing to have as specified behavior in a language.

I'm having trouble constructing a specific example that doesn't work, can you provide a minimal example that fails to compile? This compiles fine in Java 11, for example:

    import java.io.IOException;

    class Test {
        int g() throws IOException {
            throw new RuntimeException("aaa");
        }

        int f() throws IOException {
            int x;

            try {
                x = g();
            } catch (IOException e) {
                x = 3;
            }

            return x;
        }
    }

So the compiler definitely believes that x is initialized because we can return it.

Not a Java expert so maybe there's some subtlety I'm missing.

This is why the statement/expression dichotomy is a bad idea. When try/catch is an expression just like everything else, the problem disappears - you compute however you want, and then assign once.

??? I just tried this on Java 8 and it compiles fine.

I personally don't like static factories that much. They have their place, but half the JDK is now `.of` or `.from` or `.newInstance` or `.get`.

I'd really like to be able to define a constructor on sealed interfaces:

    sealed interface Path permits WindowsPath, UnixPath {
        public Path(String p) {
            if (isWindows()) {
                return new WindowsPath(p);
            }

            return new UnixPath(p);
        }
    }

That way user code to construct an object is always the same:

    var p = new Path(s);

Instead of:

    var p = Paths.get(s);

One of the many reasons to prefer composition over inheritance.

Alternatively (in particular for subclassing), it can always be worked around with an intermediate object. For example:

  Constructor(A a, B b) { … }

  Constructor(C c, D d)
  {
      // A and B can be derived from C and D, and
      // we want to forward to the (A, B) constructor,
      // so we use an intermediate object to do the
      // conversion and provide A and B:
      
      this(new Intermediate(c, d));
  }

  private Constructor(Intermediate x)
  {
      this(x.a, x.b);
  }

Of course, with the JEP this will become much simpler.

How does that help the implementor of a subclass?