fast-serialization
fast-serialization copied to clipboard
RuedigerMoeller
Java 9 support
I used the new Java9 tool called "jdeps" to analyze "fst-2.55.jar", and I got several dependencies on internal or removed JDK API (see attached file). Will you update FST to be Java9 compatible?
BTW, I used to following command to analyze "fst-2.55.jar" and associatted libraries: jdeps -jdkinternals -classpath ./ -recursive -profile fst-2.55.jar*
I will move to JDK 9 as i find time. It will be possible as the "private" API fst uses just has been package-moved (ReflectionFactory, Unsafe + some mmapped file related stuff). Instrinsic modules support might be in a second step, as serialization requires Reflection of private fields, fst will be made runnable via classpath initially.
Using FST with jdk9 i get the following warnings:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.nustaq.serialization.FSTClazzInfo (file:/C:/Users/Crigges/.gradle/caches/modules-2/files-2.1/de.ruedigermoeller/fst/2.48/a04da9aca9ecc7dcf19c5e25b89bc21468e2a3e7/fst-2.48.jar) to field java.lang.String.value
WARNING: Please consider reporting this to the maintainers of org.nustaq.serialization.FSTClazzInfo
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release
I guess you are aware of that issue. I just wanted to add it here as reference, if more people going to experience theese warnings.
there is a jdk9 branch up and running. However as i plan to split up fst (serialization, off-heap, json serialization) it's not a drop-in replacement. I managed to move to jdk9 without any warnings (by using unsafe, basically jdk9 forces unsafe in order to avoid warnings :) ).
Thank you very much for the information.
--
Eduardo Ostertag Jenkins
mailto:[email protected] mailto:[email protected]
De: moru0011 [mailto:[email protected]] Enviado el: martes, 13 de febrero de 2018 12:55 Para: RuedigerMoeller/fast-serialization [email protected] CC: Eduardo Ostertag [email protected]; Author [email protected] Asunto: Re: [RuedigerMoeller/fast-serialization] Java 9 support (#226)
there is a jdk9 branch up and running. However as i plan to split up fst (serialization, off-heap, json serialization) it's not a drop-in replacement. I managed to move to jdk9 without any warnings (by using unsafe, basically jdk9 forces unsafe in order to avoid warnings :) ).
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RuedigerMoeller/fast-serialization/issues/226#issuecomment-365309876 , or mute the thread https://github.com/notifications/unsubscribe-auth/ADy1K3BHTcUTNUthYlPxAoFvXddF-4rVks5tUbBggaJpZM4QvAyF . https://github.com/notifications/beacon/ADy1K3BpZeBsUip0DzzWKexYbDfkIbsVks5tUbBggaJpZM4QvAyF.gif
However as i plan to split up fst (serialization, off-heap, json serialization) it's not a drop-in replacement.
I tried this out and it works. Is it possible to jar up that branch and use it from an internal repo and just don't declare maven loading for it - and use it directly until you finish your re-organization?
EDIT: NOT WORKING NOW. Can't get this to work...
Hi @RuedigerMoeller! Did you find any time to work on the JDK9 migration? My project uses your great library and we are planning to move to JDK11. FST is the last dependency in our build that is not compatible with JDK9+ yet.
just tried FSTAsciiStringOffheapMap in de.ruedigermoeller:fst:2.56. When constructing an instance, it throws:
Caused by: java.lang.ClassNotFoundException: sun.misc.Cleaner
The warning seems to be thrown when you try and force a field to be accessible via reflection. FSTClazzInfo.java:503
field.setAccessible(true);
Do we need to be doing this? As if you're serialising a class, I would expect all fields that were to be serialised to be accessible by default?
I'm not sure if this helps, and I agree pure Java 9 support would probably be best, but I was able to get rid of all the warnings and didn't see any noticeable issues by adding the following options to the command to launch my JAR
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.math=ALL-UNNAMED --add-opens java.base/java.net=ALL-UNNAMED --add-opens java.base/java.text=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.util.concurrent=ALL-UNNAMED
Further explanation: https://blog.codefx.org/java/java-11-migration-guide/#Illegal-Access-To-Internal-APIs
