[
https://issues.apache.org/jira/browse/GROOVY-7204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18140253#comment-18140253
]
ASF GitHub Bot commented on GROOVY-7204:
----------------------------------------
github-actions[bot] commented on PR #3261:
URL: https://github.com/apache/groovy/pull/3261#issuecomment-6706852909
### JMH summary — indy (commit `e6e0826`)
Speedup vs trailing 90-day baseline on gh-pages. Higher = faster.
`1.00` = in line with history. Per-benchmark ratio, geomean within group.
Time-per-op units inverted so direction is consistent. The *calibrated*
column divides out this runner's speed vs the baseline hardware, as
measured by Groovy-independent pure-Java ruler benchmarks.
| Group | Speedup | Calibrated | n |
|--------|---------|------------|---|
| bench | 1.183 × | 1.036 × | 124 |
| core | 4.105 × | 3.149 × | 108 |
| grails | 1.013 × | 1.130 × | 80 |
No benchmark is ≥1.5× slower than its 90-day baseline.
> ⚠️ Runner speed differs ≥15% from the historical baseline hardware for:
bench, core-ag, core-hz. Raw speedups are not meaningful for those parts — use
the calibrated column.
<sub>Runner calibration (this run vs baseline hardware): bench 1.15× (27
rulers) · core-ag 1.30× (3 rulers) · core-hz 1.32× (3 rulers) · grails-ad 0.90×
(3 rulers) · grails-ez 0.89× (3 rulers)</sub>
<sub>Baseline: <code>dev/bench/jmh/<part>/indy/data.js</code> on
gh-pages, trailing 90 days. <a
href="https://apache.github.io/groovy/dev/bench/jmh/summary.html";>Daily
dashboard</a> · <a
href="https://apache.github.io/groovy/dev/bench/jmh/";>Per-suite raw
data</a></sub>
<!
> Static type checking and compilation fail when multiple generics in use
> -----------------------------------------------------------------------
>
> Key: GROOVY-7204
> URL: https://issues.apache.org/jira/browse/GROOVY-7204
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
> Affects Versions: 2.3.8
> Reporter: Mauro Molinari
> Assignee: Daniel Sun
> Priority: Critical
> Fix For: 3.0.0-alpha-3, 2.5.0-rc-3
>
>
> Consider the following interfaces:
> {code:title=CrudRepository.java}
> package f;
> import java.io.Serializable;
> public interface CrudRepository<T, S extends Serializable> {
> void delete(S arg);
> void delete(T arg);
> }
> {code}
> {code:title=MyRepository.java}
> package f;
> public interface MyRepository extends CrudRepository<String, Long> {
> }
> {code}
> The following implementation class:
> {code:title=MyRepositoryImpl.java}
> package f;
> public class MyRepositoryImpl implements MyRepository {
> @Override
> public void delete(String arg) {
> System.out.println("String");
> }
> @Override
> public void delete(Long arg) {
> System.out.println("Long");
> }
> }
> {code}
> And the following Groovy class:
> {code:title=MyClass.groovy}
> package f
> import groovy.transform.CompileStatic;
> import groovy.transform.TypeChecked;
> @TypeChecked
> class MyClass {
> static MyRepository factory() {
> return new MyRepositoryImpl()
> }
>
> static void main(String[] args) {
> MyRepository r = factory()
> r.delete('foo')
> }
> }
> {code}
> Static type checking returns the following error:
> {noformat}
> MyClass.groovy: 15: [Static type checking] - Cannot call
> f.MyRepository#delete(S) with arguments [java.lang.String]
> {noformat}
> The same applies if you use {{@CompileStatic}} instead of {{@TypeChecked}}.
> Note that if, In the previous code, you change the method {{main}} by
> replacing:
> {code}
> MyRepository r = factory()
> {code}
> with:
> {code}
> MyRepository r = new MyRepositoryImpl()
> {code}
> compilation succeeds. However in real code this might not be possible (the
> {{MyRepository}} instance may be injected and auto-generated, think of Spring
> Data for instance).
> The only workaround is (yet again...) to disable static type checking and
> static compilation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
