[External] : Re: New candidate JEP: 484: Class-File API

[Adam Sotona]

Class files conforming to the Chapter 4. “The class File Format” of the Java Virtual Machine Specification are supported. It covers class file versions far to the history.

Feel free to report cases where the support is insufficient.

Thank you,
Adam

From: Archie Cobbs <archie.cobbs at gmail.com>
Date: Tuesday, 27 August 2024 at 18:49
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Cc: Adam Sotona <adam.sotona at oracle.com>, jdk-dev at openjdk.org <jdk-dev at openjdk.org>
Subject: [External] : Re: New candidate JEP: 484: Class-File API
Question... would it be appropriate for this JEP to mention that support for older-than-current classfile versions is an explicit non-goal?

Otherwise I think there could be many repeats of this discussion<https://mail.openjdk.org/pipermail/core-libs-dev/2024-August/127982.html> from the other day.

To be clear, I don't disagree with the design choice, I just think it might be worthwhile to address that point directly and clarify the thinking behind it so there's no ambiguity.

As it's written today, a casual reading of the JEP comes across as if we're talking about a great new JDK-sanctioned tool with state of the art design that will help get all of the classfile manipulation libraries on the same page to allow analysis/transformation of any class file on the classpath. Or at least, it doesn't do anything to dispel that notion (unless I'm missing something).

-Archie

On Tue, Aug 27, 2024 at 8:58 AM Mark Reinhold <mark.reinhold at oracle.com<mailto:mark.reinhold at oracle.com>> wrote:
https://openjdk.org/jeps/484

  Summary: Provide a standard API for parsing, generating, and
  transforming Java class files.

- Mark


--
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20240828/976fc8dc/attachment-0001.htm>