Fix Version/s: 14
Compatibility Risk Description:There are two method name changes - which will require client code adjustments. All remaining methods are additions, so they should cause no issues.
Interface Kind:Java API
This CSR proposes few changes to the memory access API, which are aimed at addressing some comments received during the review process, as well as to improve the usability of the API.
During the review process, we kept track of some API issues (in the issue form which this CSR is derived). Some of the issues have to do with API naming inconsistencies (for instance, the fact that
MemoryAddress::offset(long) have very similar names, yet perform radically different operations). Other issues cover some usability problems when working with the API, especially in conjunction with unbound sequence layouts, as there's no way in the API to tell as to whether a memory layout has a defined size.
To address the aforementioned issues, first we propose the following two cosmetic changes:
- replace the
MemorySegment::isAccessiblepredicate with the
And, to address the usability issues when working with layout with unspecified size, we propose to add the following methods:
- add a predicate
MemoryLayout::hasSize, which allows client to tell whether
MemoryLayout::bitSizewill throw or not.
- add the method
SequenceLayout::withElementCount(long), to allow clients to obtain new sequence layouts with given new size (which is useful to turn an unbounded sequence layout into a bounded sequence layout)
- add a method
MemoryLayout::map(UnaryOperator<MemoryLayout>, PathElement...)which allow clients to create a copy of the current layout where the element selected by the layout path passed as argument is replaced by a new layout
- add a method
MemoryLayout::select(PathElement...)which allow clients to select a (possibly nested) layout at a given path in the current layout
A specdiff of the proposed changes is attached in this CSR request. A javadoc including the changes is also available here: