Am 13.10.2017 um 10:47 schrieb Jochen Theodorou:
Am 13.10.2017 um 09:52 schrieb Uwe Schindler:
FYI,
getting Unsafe does not print a warning, as reflection is "open" on
the jdk.unsupported module. This was decided in JEP 260.
ups, yes, sorry, forgot that.
and of course while true for Unsafe, we still have this:
try {
return
UNSAFE.objectFieldOffset(String.class.getDeclaredField(fieldName));
} catch (NoSuchFieldException e) {
// field undefined
}
and this getDeclaredField field will cause a warning even with addopens.
And who knows if in JDK10/18.3 or how they want to call this, there will
be still unsafe like in JDK9. For me it is scheduled to go.
Uwe
-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: [email protected]
-----Original Message-----
From: Jochen Theodorou [mailto:[email protected]]
Sent: Friday, October 13, 2017 8:49 AM
To: [email protected]
Subject: Re: Removing our use of sun.misc.Unsafe
On 13.10.2017 05:41, Paul King wrote:
I was going to try to progress removing Unsafe but I am a little unsure
where others might have gotten up to in previous investigations. So, I
have a bunch of questions in case others have some answers/ideas.
Does anyone know whether variable handles might work for us? Inside
some
kind of jdk9 plugin I guess?
in my opinion no. Not to operate on private fields of java.lang.String
without a Lookup object that has the rights to operate on the fields,
which would come from java.lang.String itself. As such a thing is not
provided, there will be no possibility.
Has anyone looked into how we might package up our unsafe usage in such
a way that it could be used in pre-jdk9 environments where var handles
aren't available but not result in errors/warnings in jdk9?
to avoid the warning we would have to not even try to get Unsafe. I
would extend our vmplugin system for this then.
What tests were being run to ensure that performance wasn't lost?
None... but what are you going to do if there is a performance loss? If
there is no alternative, then there is no alternative. And then there is
nothing to compare against, thus there is no performance loss, as a loss
requires a base, which then does not exist anymore.
Can we remove the OFFSET enum in FastStringUtils described as
applicable
for JDK4/5?
Well... officially we do not JDK4... I think our minimum for 2.4 was
JDK6? In that case... yeah I guess so ;)
bye Jochen
