RFR: 8221397 Support implementation-defined Map Modes

Andrew Dinn adinn at redhat.com
Tue Apr 9 16:02:17 UTC 2019

In response to Alan's suggestion (included below) I have reverted the
constructor for MapMode to private and will use behind the scenes access
to construct the extended enum values.

This change removes the need to modify the test in MapTest.java (no new
API to exercise).

It still requires javadoc changes in FileChannel.map and implementation
changes in FileChannelImpl.java. Reveiews for the udpated webrev would
be welcome. I'll post a separate request for review of the CSR changes.

JIRA:       https://bugs.openjdk.java.net/browse/JDK-8221397
new webrev: http://cr.openjdk.java.net/~adinn/8221397/webrev.03

Submit repo: in progress


Andrew Dinn
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

On 09/04/2019 13:47, Alan Bateman wrote:
> What would you think about not promoting the constructor to public? The
> original motivation for that was to be able to create additional map
> modes in jdk.internal.misc.ExtendedMapMode but we can use shared secrets
> or other skullduggery to do that. The advantage is that we avoid
> creating expectation in the API that developers can create their own map
> modes. The rest of the solution doesn't change, it's just eliminating
> the ability to create modes beyond the standard and extended modes.

More information about the core-libs-dev mailing list