> have we ever seen a feature like this that is explicitly not usable from Java?
Loads. Invoke dynamic and Nest-Based Access Control come to mind.
This sort of thing is also about tightening the VM specification so things like Valhala are possible. Value classes really can't function reasonably without strict field initialization. That's because these value classes can have multiple copies while an application is running. If there's a way to go in and tinker with the fields before, after, or during initialization it could lead to very hard to fix and debug issues. 1 object in 2 parts of the code with different field values.
And the reason for this tightening is because, from java, there are routes to violate this strict field initialization.
> have we ever seen a feature like this that is explicitly not usable from Java?
Loads. Invoke dynamic and Nest-Based Access Control come to mind.
This sort of thing is also about tightening the VM specification so things like Valhala are possible. Value classes really can't function reasonably without strict field initialization. That's because these value classes can have multiple copies while an application is running. If there's a way to go in and tinker with the fields before, after, or during initialization it could lead to very hard to fix and debug issues. 1 object in 2 parts of the code with different field values.
And the reason for this tightening is because, from java, there are routes to violate this strict field initialization.
It's a VM feature - value classes will use it when they land eventually. https://openjdk.org/projects/valhalla/
invokedynamic comes to mind.
It was later used to implement lambda expressions but originally had no use in the Java language and isn't tailored to lambda expressions.
All the time. Oracle and the OpenJdk team do VM changes way more than language changes.
This is required in order to implement value classes in Java (project valhala).