Banning constructors in value classes (JDK-8198749) (original) (raw)
Srikanth srikanth.adayapalam at oracle.com
Tue Feb 27 13:29:35 UTC 2018
- Previous message (by thread): hg: valhalla/valhalla: [lworld] Where statically discernible, javac should reject null assignments to, null casts to and null comparisons with value instances.
- Next message (by thread): Banning constructors in value classes (JDK-8198749)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
There has been some discussion about banning methods in value classes - with tentative semantics being discussed for invokespecial to throw an exception if it encounters an method in a value class.
(See http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003709.html and http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003712.html <http://mail.openjdk.java.net/pipermail/valhalla-dev/2018-January/003712.html:> and https://bugs.openjdk.java.net/browse/JDK-8198749)
Already, any attempt to create a value class instance via the new operator is forbidden by javac and neither __MakeDefault not withfield operation make use of the constructors. So any constructors are dead code and it makes sense at the outset to get rid of them.
I prototyped this in javac and this is what this means:
- All instance fields of value classes must be blank final variables. No initialization can be allowed. (With methods going away, there is no place to stick these initializers) - For the same reason, there cannot be instance initializer blocks in a value class. - Value classes may not declare any constructors - The compiler may generate a default constructor to simplify its life, but such a generated constructor will not make it to the class file. - For value classes, the compiler will relax the requirement that all blank final instance variables must be initialized before any constructor finishes - there are no constructors, so this cannot/need not be/will not be enforced.
I am still testing this prototype, but at the moment I am not aware of any problems, but a question: I imagine it should be possible to invoke j.l.O methods on a value instance and have them be routed to j.l.O implementation or to the override - will this work without constructor chaining - (No such chaining is happening anyways already)
Frederic/John, is this something you want to see pushed to the branch ? (assuming further testing does not uncover any problems) Or should this wait ?
Thanks! Srikanth
- Previous message (by thread): hg: valhalla/valhalla: [lworld] Where statically discernible, javac should reject null assignments to, null casts to and null comparisons with value instances.
- Next message (by thread): Banning constructors in value classes (JDK-8198749)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]