JLS tweaks

[Archie Cobbs]

On Tue, Mar 4, 2014 at 2:38 AM, Remi Forax <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.

This proposal is like the change in Java8 allowing variables used in
anonymous inner classes to no longer be required to be 'final'. Both
changes are simply relaxing an unnecessary source code restriction. I'd
even argue this proposal has much more unambiguous semantics than that
change does.

And those semantics are not anything new really. Think of the restrictions
that apply to a final field: you must set it exactly once, and you must set
it before you use it. This proposal would have the same restriction on
'this': you must initialize it exactly once, and you must initialize it
before you use it.

By the way, your suggested workaround is missing something: the only
workaround (as Brian mentioned) is not not use a constructor at all,
replacing it with a static factory method. Otherwise there's no way to
avoid e.g. redundant calculation without changing from constructor-based
creation to factory-method-based creation.

In any case, I don't see how the existence of an imperfect workaround makes
the proposal any less correct (at least in theory).


>     *Idea #5: Allow enum types to have generic type parameters*
>>
>>     Another frequent suggestion.  I agree it would have been better if
>>     it were done this way initially, and the cost would have been
>>     low.  The cost of doing this now in a binary-compatible way would
>>     be higher.
>>
>>
>> Ah, I didn't realize there was a binary compatibility problem here. What
>> specifically is the problem?
>>
>
>
> There is another problem. You don't want an enum in your example.
> You want some properties of an enum but not others. An enum in Java is not
> only a type of a serie of values,
> it's a serie of values with a name, a unique number, a common type and a
> way to get an array of all these values (with Foo.values()).
>
> In your example, you don't want a common type and if an enum type is a
> generic type values() will return array of wildcard making values() (and
> valueOf) useless from the typing point of view. It seems you want only one
> part of the enum and not the other, so an enum is the wrong language
> construction for your problem.
>

Not sure what you mean by "You don't want an enum in your example" and I
don't really understand your counter-argument. Why do you say I don't want
a common type? What part of an enum are you saying I don't really want?

Of course values() will return array of Primitive<?>. That's not useless,
and certainly no more useless than array of Primitive (non-generic) which
is all you get with the current enum.

Also, nobody has yet explained what the binary compatibility problem is.
That certainly doesn't mean there isn't one, but I just don't see it yet.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20140311/9bf88fa5/attachment-0001.html>