RFR: 8221397 Support implementation-defined Map Modes

[Andrew Dinn]

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

Testing:
Submit repo: in progress

regards,

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.