On Wed, 17 Jul 2024 08:59:07 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> Class-File API is leaving preview. >> This is a removal of all `@PreviewFeature` annotations from Class-File API. >> It also bumps all `@since` tags and removes >> `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`. >> >> Please review. >> >> Thanks, >> Adam > > Adam Sotona has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into JDK-8334714-final > - bumped @since tag > - 8334714: Class-File API leaves preview > Unfortunately, ClassFile API's scope is only to interpret correctly the Class > Files that are accepted by the current VM and support writing such class > files; for example, **for release N, we will not support correct _parsing_ or > writing of preview class files from N-1, N-2, etc.** I understand that there is no explicit goal for this API to be used for general purposes, but it seems really odd that I cannot safely assume that classes that are successfully loaded in the current runtime will be parsable. Oak classes are a notable exception, and nobody should realistically expect to see an oak class ever. However, if we only can guarantee that the current class file version will be supported and not even N-1 then no application/library expecting reliability _(without constant recompilation to ensure the class versions are current)_ should use the API. Again, its not a goal per-say but it seems really disappointing and odd. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308154137
