Re: Tracking Methods used in runtime bytecode (WAS: Re: Next releases)

Yes, that seems to go in the right direction. in other words... I would 
not know what to add to this and it looks very usable!

bye Jochen

On 6/17/26 12:10, Paul King wrote:
> This is what AI suggests for BytecodeInterfacing. Is that the kind of
> thing you had i mind?
> 
> package org.apache.groovy.lang.annotation; // next to @Incubating
> 
> @Documented
> @Retention(RetentionPolicy.RUNTIME)              // matches
> @Internal/@Incubating; enables a build-time check
> @Target({ElementType.METHOD, ElementType.TYPE, ElementType.FIELD})
> public @interface BytecodeInterfacing {
>      /** Groovy version whose compiler first emitted references to this
> entry point. */
>      String since();
>      /** Groovy version that stopped emitting references; "" = still emitted.
>          Set this when the compiler no longer generates the reference
> but old bytecode still needs it. */
>      String obsoleteSince() default "";
>      /** Earliest Groovy version in which this may be removed (once min
> supported bytecode passes obsoleteSince). */
>      String removableIn() default "";
>      /** Frozen JVM method descriptor, so a test can assert the live
> signature never drifts. */
>      String descriptor() default "";
> }
> 
>    Why these choices:
> 
>    - Where: org.apache.groovy.lang.annotation, alongside @Incubating —
> that's the established home for framework-level (non-transform)
> annotations.
>    - The version range is exactly Jochen's "introduced → no longer used
> but still maintained." since + obsoleteSince captures the live span;
> removableIn encodes the cleanup trigger so it's not lost. This
> directly maps onto reality: staticArrayAccess would be since="2.5.0",
>    obsoleteSince="6.0.0"; the v7 entry points since="2.5.0",
> obsoleteSince="3.0.0"; bootstrap since="2.1.0" with no obsolete date.
>    - RUNTIME + descriptor() unlocks the real payoff over a doc comment:
> a tiny test (or extend the existing binary-compatibility subproject)
> can reflect over all @BytecodeInterfacing members and assert the
> descriptor still matches — so an accidental signature change to a
> frozen method fails
>    CI, while everything not annotated is understood to be freely
> mutable. That's the enforcement @Internal can't give you.
>    - It's orthogonal to @Internal/@Deprecated: a method can be
> @Internal (don't call from source) and @BytecodeInterfacing (but the
> signature is frozen for old class files). @Deprecated is wrong for the
> live bootstrap — it's not deprecated, it's permanent-by-contract;
> conversely
>    fromCache/selectMethod are @Deprecated but not @BytecodeInterfacing,
> which instantly tells you they're removable. That contrast is the
> whole argument for a distinct annotation.
> 
> On Wed, Jun 17, 2026 at 8:46 AM Jochen Theodorou <[email protected]> wrote:
>>
>> Actually I have one question...
>>
>> Can we make all the indy callsite code, including IndyInterface
>> internal, to allow us to freely change the public method signatures?
>> Plus I was thinking that maybe we should add another such annotation,
>> that we could call BytecodeInterfacing or something like that, to mark a
>> method as directly called from compiled bytecode. Even better with a
>> version range for when it was introduced to when it was no longer used,
>> but still needs to be maintained to support older Groovy versions.
>>
>> bye Jochen
>>
>> On 6/16/26 14:53, Paul King wrote:
>>> Hi folks,
>>>
>>> I have just a few things to tidy up (maybe a day or two) then I plan
>>> to do releases 5.0.7 and 6.0.0-alpha-2.
>>>
>>> Let me know if you are working on something that should be included or
>>> anything which we should wait for.
>>>
>>> Thanks, Paul.
>>