[
https://issues.apache.org/jira/browse/GROOVY-9736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17510922#comment-17510922
]
Paul King commented on GROOVY-9736:
-----------------------------------
Yes, [~blackdrag] is correct. The general rule here is that if you want to use
the ASM library, go ahead and use whatever version you want (adding the
dependency to your build). That way you can use a different version to what we
are using.
Of course, if you want to align more closely with our built-in version (which
is a somewhat internal implementation detail), then you can use the
{{groovyjarjarasm.asm.Opcodes}} class. Using that comes with the risk that you
might need to refactor if we change that internal detail. Not likely but it
falls into the area where we make less guarantees about backward compatibility.
It would be interesting to know your use case.
> Remove org.objectweb.asm.Opcodes as implemented interface in most (all?)
> places
> -------------------------------------------------------------------------------
>
> Key: GROOVY-9736
> URL: https://issues.apache.org/jira/browse/GROOVY-9736
> Project: Groovy
> Issue Type: Improvement
> Affects Versions: 3.0.5
> Reporter: Paul King
> Assignee: Paul King
> Priority: Major
> Labels: breaking
> Fix For: 4.0.0-alpha-1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Back before Java had static imports, a common usage pattern for using
> `org.objectweb.asm.Opcodes` was just to implement that interface. Then,
> referencing the constants within that interface was simply a matter of
> referencing them directly rather than requiring them to be prefixed with the
> class name. Since static imports, it is generally better to statically import
> the required constants. This avoids that class from leaking into our public
> API. It is even slightly more problematic than normal for us since that class
> is one of the ones we jarjar, so the leaked class might have a different
> package (groovyjarjarasm) than the one some might expect.
> This issue is to consider removing all such usage (targeting Groovy 4). Code
> which extends any impacted classes might now need to add additional static
> imports. One the plus side, the jarjar side of things will then remain better
> hidden.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
