On Thu, 17 Mar 2022 06:47:13 GMT, Rémi Forax <fo...@openjdk.org> wrote:
>> Change `CallSite` to a sealed class, as `CallSite` is an abstract class >> which does not allow direct subclassing by users per its documentation. >> Since I don't have a JBS account, I posted the content for the CSR in a >> GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and >> wish someone can submit a CSR for me. > > src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: > >> 86: */ >> 87: public >> 88: abstract sealed class CallSite permits ConstantCallSite, >> VolatileCallSite, MutableCallSite { > > Nitpicking with my JSR 292 hat, > given that the permits clause is reflected in the javadoc, > the order should be ConstantCS, MutableCS and VolatileCS, > it's both in the lexical order and in the "memory access" of setTarget() > order , from stronger access to weaker access. I agree that Constant, Mutable, Volatile order is better, ranked by the respective cost for `setTarget()` and (possibly) invocation, and earlier ones in the list are more preferable if conditions allow. However, in the current API documentation, the order is Constant, Mutable, and Volatile. Should I update that or leave it? /* * <ul> * <li>If a mutable target is not required, an {@code invokedynamic} instruction * may be permanently bound by means of a {@linkplain ConstantCallSite constant call site}. * <li>If a mutable target is required which has volatile variable semantics, * because updates to the target must be immediately and reliably witnessed by other threads, * a {@linkplain VolatileCallSite volatile call site} may be used. * <li>Otherwise, if a mutable target is required, * a {@linkplain MutableCallSite mutable call site} may be used. * </ul> */ ------------- PR: https://git.openjdk.java.net/jdk/pull/7840
