FYI, getting Unsafe does not print a warning, as reflection is "open" on the jdk.unsupported module. This was decided in JEP 260.
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
