You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@groovy.apache.org by "Paul King (Jira)" <ji...@apache.org> on 2022/05/29 03:14:00 UTC

[jira] [Updated] (GROOVY-10643) CLONE - Consolidation of VMPlugin didn't account for API calls in the Groovy runtime

     [ https://issues.apache.org/jira/browse/GROOVY-10643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King updated GROOVY-10643:
-------------------------------
    Description: 
*{color:#DE350B}Addendum{color}*: it seems like the protected method {{}}

A change in Groovy 3 (see GROOVY-9380 for details) was to consolidate classes from the legacy Java5 through Java7 classes into Java8. Those classes are part of Groovy's plugin mechanism and aren't meant to be used directly. The legacy classes were deprecated in Groovy 3 and removed in Groovy 4. This was an intended breaking change for anyone using those classes directly. Remember the change is transparent for anyone using the plugin mechanism as intended. A subset of those classes are also directly called by the bytecode for Groovy 2.5 compiled code with Indy enabled, i.e. were part of the Groovy runtime for that version. Removing backwards compatibility for those classes was unintended.

This would mostly impact folks who might create applications from a mixture of dependencies, e.g. maybe a helper classes, library or plugin compiled under Groovy 2.5 with Indy enabled and then used in conjunction with another application compiled under Groovy 4. This will be fixed in the next point release.

  was:
A change in Groovy 3 (see GROOVY-9380 for details) was to consolidate classes from the legacy Java5 through Java7 classes into Java8. Those classes are part of Groovy's plugin mechanism and aren't meant to be used directly. The legacy classes were deprecated in Groovy 3 and removed in Groovy 4. This was an intended breaking change for anyone using those classes directly. Remember the change is transparent for anyone using the plugin mechanism as intended. A subset of those classes are also directly called by the bytecode for Groovy 2.5 compiled code with Indy enabled, i.e. were part of the Groovy runtime for that version. Removing backwards compatibility for those classes was unintended.

This would mostly impact folks who might create applications from a mixture of dependencies, e.g. maybe a helper classes, library or plugin compiled under Groovy 2.5 with Indy enabled and then used in conjunction with another application compiled under Groovy 4. This will be fixed in the next point release.


> CLONE - Consolidation of VMPlugin didn't account for API calls in the Groovy runtime
> ------------------------------------------------------------------------------------
>
>                 Key: GROOVY-10643
>                 URL: https://issues.apache.org/jira/browse/GROOVY-10643
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 4.0.0
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Blocker
>             Fix For: 4.0.1
>
>
> *{color:#DE350B}Addendum{color}*: it seems like the protected method {{}}
> A change in Groovy 3 (see GROOVY-9380 for details) was to consolidate classes from the legacy Java5 through Java7 classes into Java8. Those classes are part of Groovy's plugin mechanism and aren't meant to be used directly. The legacy classes were deprecated in Groovy 3 and removed in Groovy 4. This was an intended breaking change for anyone using those classes directly. Remember the change is transparent for anyone using the plugin mechanism as intended. A subset of those classes are also directly called by the bytecode for Groovy 2.5 compiled code with Indy enabled, i.e. were part of the Groovy runtime for that version. Removing backwards compatibility for those classes was unintended.
> This would mostly impact folks who might create applications from a mixture of dependencies, e.g. maybe a helper classes, library or plugin compiled under Groovy 2.5 with Indy enabled and then used in conjunction with another application compiled under Groovy 4. This will be fixed in the next point release.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)