Closed RussiaVk closed 1 year ago
I don't think it's possible because the library relies on certain functionalities that are not available in Java 17, such as Math.unsignedMultiplyHigh.
It can be solved using "JEP238". We can copy source of unsignedMultiplyHigh method Into NumberParser:
Yes, but this function is annotated with @IntrinsicCandidate, which means that if we copy it, we will lose support from the JVM in terms of optimization.
Yes, but this function is annotated with @IntrinsicCandidate, which means that if we copy it, we will lose support from the JVM in terms of optimization.
What I mean is, in order to comply with the “Multi Release” feature, we should create a separate duplicate file for the NumberParser class (as well as the source code for unsignedMultiplyHigh) for Java 17. It will not conflict with Java 20.
OK, I get it. Have you tried applying the changes you mentioned and testing the library's performance on Java 17? I'm asking because it would be good to know if there is any advantage over other JSON parsers in terms of performance and, thereby, if there is a reason to add support for Java 17. The library highly relies on the advancements in the Vector API, so the newer the Java version, the better the performance we should expect.
OK, I get it. Have you tried applying the changes you mentioned and testing the library's performance on Java 17? I'm asking because it would be good to know if there is any advantage over other JSON parsers in terms of performance and, thereby, if there is a reason to add support for Java 17. The library highly relies on the advancements in the Vector API, so the newer the Java version, the better the performance we should expect.
Not yet. I'm a gradle noob, so I'm currently using maven, and I don't know how to run the code in the src/jhm/java directory through maven.
Is it possible to update the target Java version of the project to Java 17 in the next Maven release, considering that Java 17 can run SIMD API without any issues?