uschindler commented on PR #14651: URL: https://github.com/apache/lucene/pull/14651#issuecomment-2875430075
> the compiler and also introduced an - undocumented? - 'ct.sym' file, which is part of the JDK and is a zip file with class signatures from previous Java version. Couldn't find the docs on this file anywhere and ecj's source is a fun reading too: This is well documented in the source code of the JDK; I don't remember if there's also a JEP. The ct.sym file is generated by the JDK build and later committed when they start a new release. Actually the way how it is generated was my inspiration for the stub-only APIJAR files we have for compilation of MR-JARs. Basically it is more or less exactly the same: The ct.sym file is just a ZIP file with empty stubs and (in addition to Lucene's approach) with some additional logic to only record the differences between API versions. Because of this it is accessing the filesystem provider many times, because it has to load a symbol from many files until it has gotten all symbols by adding up all incremental changes. This is the reason for the file exists. It looks up for every previous Java relaese if a sym file exists. And as we are at 24 already it goes down to 7 or 8. This does not scale, so they should improve the lookup structure by having a pointer to previous release of a specific file in each class stub. The most important question here: Did you find out if "compliance" flag uses release or not? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
