[datum] initial public push (IPP)

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Nov 8 11:15:10 UTC 2017

That's a nice idea - not sure if @Override is the right name for it 
(after all, it's not overriding anything, it's more of an explicit 
definition), but some mechanism like that would be helpful, yes.


On 08/11/17 05:35, Tagir Valeev wrote:
> Hello!
> Thank you for pushing this!
>> If the user provides any of the above members explicitly, it will be used instead of the default defined by the compiler
> Suppose we provide an explicit getter implementation. How can we
> assert an intention to override the default implementation, so we will
> get a compilation error if later field name is changed, but method
> name stays the same? Can we use @Override on the getter?
> With best regards,
> Tagir Valeev.
> On Wed, Nov 8, 2017 at 1:11 AM, Vicente Romero
> <vicente.romero at oracle.com> wrote:
>> Hi all,
>> We have just made public the development of data classes [1]. The
>> development will continue in the "datum" branch in the amber repo [2]. Data
>> classes allow for more compact class declarations. Basically for classes for
>> which the state of the class can be declared in the class header. The basic,
>> informal, data class syntax is:
>>    __datum Name(Fields) { BODY } or for a body-less data class:
>>      __datum Name(Fields);
>> here Fields is a list of fields, and each field can be:
>> [@Annos] [ __nonfinal ] type name
>> *Note:* __datum and __nonfinal are just place holders, the final keyword to
>> be used is still to be defined
>> The fields are implicitly lifted onto fields of the class, with the default
>> accessibility of "package final", unless noted as non-final. Any additional
>> field declarations in the body are prohibited. Non-abstract data classes are
>> final. Data classes can be generic and can implement arbitrary interfaces.
>> Every non-abstract data class acquires:
>>   - a public constructor that takes fields in the order specified by the
>> field list, and initializes all fields;
>>   - public getters for each field, whose name is same as the field;
>>   - public equals(), hashCode(), and toString().
>> If the user provides any of the above members explicitly, it will be used
>> instead of the default defined by the compiler. Abstract data classes are
>> permitted; but they get only a public constructor.  By default the field
>> access of abstract data classes is protected and they are final.  In
>> addition, data classes can extend abstract data classes.  Also, data classes
>> with no parent class have the new class java.lang.DataClass as its parent.
>> Extension looks like:
>> abstract __datum X(int x);
>>      __datum Y(int x, int y) extends X(int x);
>> that is, the fields of X must be a proper prefix (arity, name, and types) of
>> Y's fields. For example the compiler won't accept this declaration for Bad
>> data class:
>>      abstract __datum Sup(int x, int y);
>>      __datum Bad(int x, int y, int z) extends Sup(x, z); // field name
>> mismatch should be Sup(x, y)
>> The current implementation doesn't allow data classes with an empty list of
>> fields, so:
>>      __datum D2();  // compiler error
>> we can relax this constraint in the future if there are sensible use cases
>> for which it makes sense to declare an empty data class.
>> Please try it out and get back to us with your feedback!
>> Thanks,
>> Vicente
>> PS. this code is under active development and bugs are being chased out but
>> still lurking, thanks a lot in advance for any bug report!
>> [1] http://hg.openjdk.java.net/amber/amber/rev/04260073c6bd
>> [2] http://hg.openjdk.java.net/amber/amber

More information about the amber-dev mailing list