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.
