RFD: JDK-8221477, JDK-8221397, JDK-8221696, JDK-8224974
Andrew Dinn
adinn at redhat.com
Thu Nov 21 12:04:31 UTC 2019
On 21/11/2019 08:25, Andrew Haley wrote:
> On 11/19/19 3:51 PM, Gil Tene wrote:
>> As a rule, any in-version changes to the public Java SE APIs, including
>> the addition of new methods, are a “don’t do this” sort of thing. In the
>> extremely rare cases where they are necessary (e.g. security driven)
>> a rev to the spec (and often to the TCKs) is required.
>
> I don't think we need to do that. As I understand it, we can make the changes
> to jdk.internal.misc.Unsafe without breaching anything. We can use these
> Unsafe methods in an external library, and we can do the mapping itself
> in a library too.
Yes, I have had a talk with Jonathan Halliday about this and I believe
we can ensure that the functionality can be made available via a 3rd
party library without changing JDSK11 SE at all i.e. without the
addition of any new modules or packages and without modifying any of the
public API surface of the JDK11 class base. We can follwo Gil's lead and
do this via a library that will work on jdk11u and continue to work on
jdk14+.
I will prepare a new patch that includes much the same changes to the
underlying implementation. However, it will make be tweaked to make the
new FileChannel map and MappedByteBuffer force behaviours available via
private methods only (these methods will also be exposed in private
method handle fields). This mode of proceeding will mean we can omit the
need for any changes to the public FileChannel MapMode enum.
Access to this new, fully private functionality will then be provided by
a non-SE module library. On jdk11u it will need to use Unsafe to access
the private method handles and employ them to provide a safe public API
for invoking the required map and force behaviours. Making that work
will require the user to explicitly export access to Unsafe to the
library. Obviously on jdk14+ the same library can simply call the
relevant public APIs directly and the need to export access to Unsafe
will disappear.
Regarding Martin's comments, I will be happy to delay this backport
until the relevant functionality was available in a jdk14 release. I
understand why he would prefer for the current behaviour to have baked a
bit longer in jdk14.
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
More information about the jdk-updates-dev
mailing list