JLS tweaks

[Archie Cobbs]

Hi Brian,

On Fri, Mar 14, 2014 at 9:57 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> As far as I can see, the only real argument raised in favor of this
> feature is "the language already allows partially-constructed instances to
> be exposed to arbitrary code, how much worse would it be if it exposed
> even-less-constructed objects?"


This comment made me realize this discussion is getting sideways.

There is one very simple and powerful argument in favor of this feature: it
would make life better for Java programmers. They would not have to jump
through ridiculous contortions to get their super() parameters in order all
in one statement. They would not have to choose between redundantly
calculating the same result vs. having to use factory methods instead of
constructors.

I have talked to several day-to-day programmers and every single one
expressed displeasure with this "super() first" restriction... everything
from "yeah that annoys me" to various unprintables. As a small objective
data point, this stackoverflow
question<http://stackoverflow.com/questions/1168345/why-does-this-and-super-have-to-be-the-first-statement-in-a-constructor>("why
does this() and super() have to be the first statement in a
constructor?") has been upvoted 153 times.

These folks are not language theoreticians, but they are all intuitively
smart enough understand that the current syntax-based rule is too
restrictive. Constructors should be allowed more room to get their
parameters in order prior to invoking super()/this(). It's obvious to
anyone who writes Java code for a living.

And FWIW, in my personal experience writing Java code over the past 15+
years, this is my number one annoyance with the JLS. I'm spending time
pushing this because I believe in "stop complaining and do something about
it". But trust me I'm representing lots of other folks too.

Of course, JLS change decisions should made by reasoned analysis, not mob
rule.

But to say there's no argument in favor of this proposal is just being in
denial. Moreover, there are many small JLS changes in Java 7 and Java 8
that had a much smaller benefit to the programmer than this one, yet were
still approved.

So I think the burden of proof here is on YOU any any other naysayers - to
demonstrate even just one good argument why we should NOT remove this
restriction. As soon as I hear one I'll drop it!

But so far here is what I've heard you and others say:

1. We already rejected that idea.

This is not, per se, relevant. However, if you can go back and retrieve a
good reason against this idea, fine - let's hear it.

Or are you saying that it's impossible previous decisions could be wrong? I
don't think you're saying that... otherwise there would be no such thing as
JSR process.

Or, are you implying that it would be too embarrassing for members of the
JLS team to been seen changing their minds on something. Well, I was under
the impression we optimizing here based on objective, technical language
criteria, not bureaucratic nonsense or saving face.

And in any case, those earlier suggestions may have been slightly different
from this one, e.g., in ways that actually would weaken type security. I'm
certain that this one, however, does not, so let's stay focused on it.

2. This makes an already questionable type safety worse.

Not true Now, I agree with you that the existing constructor type safety
situation has some flaws. Trust me, I am personally a big fan of Java's
strong type safety - it's why I use Java instead of python or whatever.

However, you are wrong to let dissatisfaction with the current situation
bleed over into this proposal. This proposal has absolutely no relation to,
or negative effect on, the problems you have described - on the contrary,
the very example you gave (constructor registering listener) can be fixed
by allowing this change! This proposal does not weaken type safety one
iota, in fact it makes it slightly better.

I've asked for an example of how this change would make type safety worse
but you have not provided one. That's because anyone can see with a
moment's reflection that no such example exists... because the proposed
change does not allow you to "do anything" with 'this' prior to
initialization.

Perhaps you had in mind a previous, slightly different version of this
proposal at first. I'm sure you've seen many variants.

Here's another way to look at it: any code that takes advantage of this
relaxed restriction can be transformed into equivalent code legal under the
current JLS, by "uninlining" all the code prior to super()/this() and
moving it into every constructor call site, and adding additional
constructor parameter(s).

For example, this:

  public Foo(boolean b) {
    int x = b ? 4 : 5;
    super(x);
  }

  public void caller1() {
    new Foo(true);
  }

  public void caller2() {
    new Foo(false);
  }

is equivalent to this:

  public Foo(boolean b, int x) {
    super(x);
  }

  public void caller1() {
    int x = true ? 4 : 5;
    new Foo(true, x);
  }

  public void caller2() {
    int x = false ? 4 : 5;
    x = new Foo(false, x);
  }

Therefore it can't possibly be any less type safe than what we currently
have.

So this objection needs to be put to rest. Either provide an example of how
this proposal makes the current situation any worse, or agree that one
doesn't exist so we can move forward.

3. Too much additional compiler complexity

This is easily debunked. The very same criteria and existing compiler code
that implements the current 'final' assignment logic ("initialize exactly
once, and only use after initialization") can be re-used to implement this
feature.

So in summary, we have at least one good reason to remove this restriction
(people are demanding it), maybe two (allows an improvement in type safety
when the superclass constructor invokes overridden method(s)), and zero
reasons not to remove it.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140315/72e2e68a/attachment.html>