Allow data interface and use non-deterministic hashCode

[Per Minborg]

I am new to the mailing list so apologies if I'm asking questions 
already understood.

I have two questions/proposals:

1) I think it would make sense to allow data interfaces too. For 
example, if I have an immutable model of a Point then we could have:

__data interface Point(final int x, final int y) { }

This would trivially correspond to the de-sugered interface:

interface Point {
     int getX();
     int getY();
}

Now, one implementation of this interface would of course be:

__data class GerneralPoint(final int x, final int y) implements Point { }

and another could be

class OrigoPoint() implements Point { public getX() {return 0;} public 
getY() {return 0;} // Left out equals, hashCode and toString for brevity


2) How do we see the level of determinism on the generated hashCode() 
methods (and toString())? There are several alternatives including:

A) The hashCode() will always return the same value for the same input 
state vector always and forever and may be deterministically 
pre-computed and/or specified

B) The hashCode() will always return the same value for the same input 
state vector always and forever but the actual function is 
implementation specific and is not available a-priori

C) The hashCode() will always return the same value for the same input 
state vector for any given Java version

D) The hashCode() will always return the same value for the same input 
state vector for any given compiled JAR/class file

E) The hashCode() will always return the same value within a particular 
running JVM instance

It should be said that there are more alternatives. This is just a 
sub-set of the ample variants that exists.

I am inclined to favor committing to as little as possible (E) as they 
may come in "better" hash methods over time and to discourage bad usage 
of hashCode(). This is also supported by the general hashCode contract 
that  says "This integer need not remain consistent from one execution 
of an application to another execution of the same application.". If so, 
we could add a "salt" to the hashCode, making it different for any input 
state vector per JVM run. This is related to the order in which keys are 
returned for maps obtained via the static Map methods() in Java 9. To 
prevent people from assuming a certain order, the order is purposely 
changed between JVM runs.

Data classes have their particular field of use. For example, regarding 
the Point interface and considering the contract of hashCode: new 
GeneralPoint(0, 0).hashCode() must be equal to new 
OrigoPoint().hashCode() (provided that their equals method returns true 
when applied to the other one, which I take as an axiom). But how can we 
implement the hashCode() mehtod of OrigoPoint if we do not know how the 
hashCode() of GeneralPoint is implemented? The conclusion is that we 
cannot use data classes if we want full control of the hashCode 
function. I think this reasonable and even desirable. And I realize now 
that this is perhaps an argument against allowing data interfaces.

Best, Per Minborg



-- 

cid:F96D3A23-2EC0-48EF-9AD7-E8C2763D1551cid:00B98D15-D436-4C26-BFCF-B4FCCE0AACA4
*Per Minborg | CTO
*minborg at speedment.com
*US +*1 650 353 6579
*Skype: minborg
IM: @PMinborg
speedment.com <http://www.speedment.com/>*<http://www.speedment.com/>

JavaOne 2017 
<https://events.rainfocus.com/catalog/oracle/oow17/catalogjavaone17?search=minborg&showEnrolled=false>