You are viewing a plain text version of this content. The canonical link for it is here.

Posted to notifications@groovy.apache.org by "Jochen Theodorou (Jira)" <ji...@apache.org> on 2023/08/17 14:33:00 UTC

[jira] [Commented] (GROOVY-11158) Explore whether we should deprecate/delete any generated callsite caching related classes

    [ https://issues.apache.org/jira/browse/GROOVY-11158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17755580#comment-17755580 ] 

Jochen Theodorou commented on GROOVY-11158:
-------------------------------------------

My wish would be to "long term" to take the all classes in org.codehaus.groovy.runtime.callsite, make them deprecated and move them to a groovy-lagacy kind of jar, that is then only required if you want to run groovy with callsite caching. I think only CachedClass#getCallSiteLoader would also have to be moved, causing a breaking change in the public api. Though I think the risk is really low

> Explore whether we should deprecate/delete any generated callsite caching related classes
> -----------------------------------------------------------------------------------------
>
>                 Key: GROOVY-11158
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11158
>             Project: Groovy
>          Issue Type: Task
>            Reporter: Paul King
>            Priority: Major
>             Fix For: 5.x
>
>
> See the mailing list discussion:
> https://lists.apache.org/thread/hvfxv7j9bnrj6l48c1hnd7px4qhdn7b7
> We want to retain any classes needed for backwards compatibility, e.g. classes embedded in the bytecode generated from older groovy versions. But we should deprecate classes as appropriate. Some may be possible to delete altogether.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)