We could use a multi-release jar to still provide a faster option for pre jdk9 users but avoiding that added complexity would also be a good thing.
On Sat, Oct 14, 2017 at 12:28 AM, John Wagenleitner < [email protected]> wrote: > I would be in favor of removing Unsafe from the groovy-json subproject > which I think is the only place where it's used. I had planned to propose > this to the dev list but never got around to it. With compat strings in > Java 9 I believe it will no longer be a viable optimization (at least not > without quite a bit of effort) and while there may be some performance (or > memory) impact for those using Java 7/8 I suspect it wont be that > noticeable for most all workloads. > > I not sure var handles will help much given the work that would be needed > to decode the new byte array that String uses in 9. I definitely think > offset can be removed since now we are Java 6 minimum, though I would > propose Unsafe be removed altogether from 2.5 onwards. > > On Thu, Oct 12, 2017 at 8:41 PM, Paul King <[email protected]> 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? >> >> 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? >> >> What tests were being run to ensure that performance wasn't lost? >> >> Can we remove the OFFSET enum in FastStringUtils described as applicable >> for JDK4/5? >> >> >> Cheers, Paul. >> >> >
