JLS tweaks

[Peter Levart]

On 03/11/2014 07:09 PM, Archie Cobbs wrote:
> On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax <forax at univ-mlv.fr 
> <mailto:forax at univ-mlv.fr>> wrote:
>
>
>         It seems like the JVM spec gets it right - i.e., you can do
>         (mostly) whatever you want prior to super()/this() as long as
>         it doesn't try to make use of an uninitialized 'this', and no
>         uninitialized 'this' can escape. It seems reasonable to want
>         the JLS to more closely mirror this sensible stance.
>
>         I must be missing something...
>
>
>     The rules of Java the language are less permissive than the rules
>     of the JVM regarding uninitialized instance, that's true.
>     But at least, the Java rules is simple to understand to anyone.
>     Adding complexity here will not worth it and as Brian mention,
>     you can still call a static method inside this() or super().
>
>
> I don't see how any complexity would be added (that is, for the 
> programmer). What's being added is flexibility. If someone wants to 
> continue to make super()/this() the first line of every constructor, 
> they can happily continue do so.

Hi Archie,

Would you want this to be allowed too:

     public class C extends B {
         public C(boolean b) {
             if (b) {
                 super("YES");
                 // we may now use this...
                 this.method();
             } else {
                 // we may not use this before call to super
                 super("NO");
                 // we may now use this...
             }
         }
     }

What about the following:

     public class C extends B {
         public C() {
             try {
                 super();
                 if (Math.random() > 0.5L) throw new RuntimeException();
             } catch (RuntimeException e) {
                 // can we use 'this' here?
             }
             // is 'this' fully initialized here?
         }
     }

...and similar cases?

Just to illustrate this is not a simple problem. But there might be a 
solution that is similar to a feature already present in Java language. 
Namely: the final variables and definitive assignment rules. We could 
treat 'this' (explicit and implicit) as a final instance field that is 
definitely not assigned at the start of a constructor. Any call to 
super(...) or this(...) is only possible in parts of constructor flow 
where 'this' is definitely not assigned and has the effect of making 
'this' definitely assigned after the call. 'this' should either be 
definitely assigned or definitely unassigned at all non-exceptional exit 
paths from the constructor or else there is a compile-time error. If it 
is definitely assigned, nothing is done, if it is definitely unassigned, 
a synthetic call to super() is generated as the first instruction in the 
constructor.

So if we threat 'this' as a final instance field for which the 
assignment state is tracked by the compiler, every explicit or implicit 
use of 'this' should only be allowed in parts of constructor flow where 
it is definitely assigned.

I don't see this as any more complex or unsafe as the rules for final 
fields. But I don't know if it is compatible with JVM rules.

Regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140313/e020eba0/attachment.html>