More last minute changes for the ClassFile API

[Maurizio Cimadamore]

On 02/12/2024 16:50, Brian Goetz wrote:
> My main concern with the single-purpose components is that I think 
> they are in the wrong place.  Co-locating them with the classfile API 
> feels like it is promising more than we deliver, and users might feel 
> they have to understand what they do.
>
> I agree that the printing functionality is essential, and perhaps it 
> doesn’t belong in components, especially if the rest off components is 
> going away.

While I agree that some of the stuff in here seems useful, I'm not sure 
how much we want to commit to it.

Even if I look at ClassPrinter only, there's XML, Yaml and JSON output. 
These probably use a custom schema, which might, or might not fit the 
user needs. The fact that we even say:

> * Printing is for debugging purposes only. Printed text schema, tree 
> content and structure * not guaranteed. It may change anytime in a future.
Is, IMHO, a big red herring.

I think having a way to dump a class model in a textual form is a good 
thing (but I'd say that something like this can be achieved by adding 
some method to ClassModel, rather than having a separate component?). 
But the stuff in this package seems relatively niche-y, and we'd be 
perhaps better off to leave this out, at least for now. If, in the 
future, we think that some of the components are sufficiently general to 
be added to the API, we can consider it? (e.g. we don't have to decide now?)

Cheers
Maurizio

>
>
>
>> On Dec 2, 2024, at 2:51 AM, Adam Sotona <adam.sotona at oracle.com> wrote:
>>
>> ClassRemapper, CodeLocalsShifter, CodeRelabeler and CodeStackTracker 
>> are single-purpose components standing on top of Class-File API and 
>> they have been carefully selected to support more complex use cases 
>> (like for example code instrumentation). I partly agree they may be 
>> turned into examples. However, the learning curve will be extremely 
>> steep for users forced to implement them first instead of just use them.
>> ClassPrinter is a different beast. This tool raised from serious 
>> needs and become significant complement to the API. It has been 
>> cleaned and simplified to its bare bones to avoid any confusion about 
>> its purpose. Maybe the components package location for ClassPrinter 
>> is not ideal however it works to differentiate it from the core API.
>> I have no objections to unify sub-int return types to int.
>> Thanks,
>> Adam
>>
>> *From:*classfile-api-dev <classfile-api-dev-retn at openjdk.org> on 
>> behalf of Chen Liang <liangchenblue at gmail.com>
>> *Date:*Monday, 2 December 2024 at 0:03
>> *To:*Brian Goetz <brian.goetz at oracle.com>
>> *Cc:*classfile-api-dev <classfile-api-dev at openjdk.org>
>> *Subject:*Re: More last minute changes for the ClassFile API
>>
>> Hmm, for components package, I did a quick rundown ingrep.app 
>> <http://grep.app/>search (previously used for terminally deprecating 
>> ZipError) and a search within JDK source:
>> 1. A search ongrep.app <http://grep.app/>shows there are no non-JDK 
>> usages of the components package; in contrast, all other classfile 
>> packages (attribute, instruction, constantpool) and the 
>> java.lang.constant package have usages beyond the JDK. A search on 
>> GitHub shows there is no actual usages of components package, yet 
>> ClassPrinter.ListNode is frequently used in imports due to the name 
>> similarity with a class offered by Leetcode.
>> 2. A search within the JDK itself shows there is no use of these 
>> components, besides ClassPrinter in JFR, outside of ClassFile API and 
>> its tests.
>> I think the removal at this point is safe; even for the ClassPrinter, 
>> its huge amount of data exposed is very prone to unintended 
>> dependencies, which can turn it into a monolith that we cannot 
>> adjust at all later down the road.
>> Also for the 2 return types: Is it fine for us to promote the return 
>> types to `int` to promote consistency with the constant fields?
>> Chen
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20241202/31168fc2/attachment.htm>