[datum] initial public push (IPP)

Robert Gibson robbie_usenet at yahoo.co.uk
Thu Nov 9 17:41:10 UTC 2017

The idea is to remove the possibility of ‘always false’ equals comparisons “Hello”.equals(3) for data classes.  Your IDE might currently warn about them, but can we do better?

The simplest approach is just

__data class Point(int x, int y);
// implies public boolean equals(Point p), maybe with a bridge method from equals(Object o)

Point p = new Point(1, 2);
assert p.equals(new Point(1, 2));
// Doesn’t compile, hooray!
//assert !p.equals(“point”);

But that very quickly runs into problems

// Oops, we lost transitivity
assert !”point”.equals(p);
Object o = p;
// Oops, we got a ClassCastException (probably)
assert !o.equals(“point”);

And there are more pitfalls of course around inheritance, although the rule of “only one concrete class in a hierarchy” eases the pain a little.

I suspect that backwards compatibility is going to win out pretty quickly (for example, Scala case classes and Kotlin data classes both define equals in terms of Any), but I note that C# records implement IEquatable<T>, an interface which has ‘only’ existed since C# 2.0

I’m just interested to know if you have done any exploration of this space, or if it is completely out of scope and off the radar (to mix my metaphors a little)?


> On 9 Nov 2017, at 18:02, Vicente Romero <vicente.romero at oracle.com> wrote:
> Hi Robert,
> On 11/09/2017 11:40 AM, Robert Gibson wrote:
>> Hi,
>> This looks promising.  I read Brian’s note [1] and I wondered if you have given any consideration to the idea of attempting to generify the equals() method for data classes?
> Interesting question, we haven't spoken about it. Could you please provide a test case for this feature?
>> Thanks,
>> Robert
> Thanks,
> Vicente
>> http://cr.openjdk.java.net/~briangoetz/amber/datum.html
>>> On 8 Nov 2017, at 12:28, amber-dev-request at openjdk.java.net wrote:
>>> Date: Tue, 7 Nov 2017 13:11:40 -0500
>>> From: Vicente Romero <vicente.romero at oracle.com>
>>> To: Amber dev <amber-dev at openjdk.java.net>
>>> Subject: [datum] initial public push (IPP)
>>> Message-ID: <a00cffb6-217b-7e04-ffd3-37f51934352e at oracle.com>
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>> 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