RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package (original) (raw)
Doug Lea dl at cs.oswego.edu
Thu Nov 12 00:17:31 UTC 2015
- Previous message: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package
- Next message: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 11/11/2015 09:07 AM, Chris Hegarty wrote:
So I think the questions we need to answer are as follows: a) Is it desirable to have @Contended as part of Java SE? i) If so, is this doable for JDK 9? b) If ‘No’ to a or i, do we consider @Contended “critical”, as per JEP 260 ?
@Contended is something that only a very small number of developers directly use (sparingly), but the products of their efforts are used by many other developers.
The "very small number" is still greater than the number of java.util.concurrent maintainers. As the use of concurrency expands, java.util.concurrent itself can't (and shouldn't) supply all possible specialized components needed in applications, so external libraries are needed to fill in the gaps. I'm sure that every developer of such concurrent components would vote to be able to use @Contended.
I don't know of any argument not to expose it, beyond the usual concerns about supporting nichy esoteric stuff in jdk. Under the Unsafe-phase-out plans, public support for nichy esoteric stuff that has no other functional alternative will be more common.
Without some good argument against it, I think the only issue is where (what package) to place it. Carrying it out from there seems identical to your webrev diffs, just changing import statements and the like.
-Doug
- Previous message: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package
- Next message: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]