Hi Chris, I think I've got another way to do this, you can see in my pr( https://github.com/apache/tsfile/pull/3). I found that all the constants have already been calculated and defined in the `RamUsageEstimator` of lucene and we can directly use that instead of defining it again.
Best regards, -------------------------- Yuan Tian On Thu, Jan 4, 2024 at 11:59 PM Christofer Dutz <[email protected]> wrote: > Hi all, > > so today we stumbled over a new type of problem (and I thought I had seen > all types). > In order to replace the GPL licensed library, direct usages of > sun.misc.Unsafe were added for getting the sizes of types and arrays in JMV > memory. > > The main problem is: If we want to compile true Java 8 libraries with any > java version greater than 8, we need to set the “release” config option in > the maven plugin. This tells the compiler to cross compile for that java > version. It does this by checking an index file for that given java > version. Problem seems to be that for java 8 the sun.misc.Unsafe is not > included in this index and the compiler therefore fails. > > Now there are multiple options to resolve this issue: > > We could not use the “release” option, but that could produce Jars that > have the right java class version, but can’t work on Java 8 because of > missing types. (Sub-Ideal) > > We could create a library, that wraps these calls and which is compiled on > Java 8. So Instead of using the direct calls, we’d use that library > instead. However this is just tricking the compiler and if in any future > version of Java this file is moved/removed, things will explode. > > As a third option, I see that we could simply define the constants to > fixed values. These values are really not going to change and I will do a > check with what the values are on various JDKs and OSes. This option has > the advantage, that if any of these values would change in future versions, > the old data-files would not be corrupt. And if we want to Provide TsFiles > on other systems than Java, we probably need constants anyway. > > I have therefore defined these constants in order to get the build working > again and we’ll continue this discussion to which path we want to go. > > > Chris >
