From notifications-return-14437-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Fri Nov 2 07:53:12 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 9CB5A18062B for ; Fri, 2 Nov 2018 07:53:11 +0100 (CET) Received: (qmail 88734 invoked by uid 500); 2 Nov 2018 06:53:04 -0000 Mailing-List: contact notifications-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list notifications@groovy.apache.org Received: (qmail 88715 invoked by uid 99); 2 Nov 2018 06:53:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Nov 2018 06:53:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id AAB4C1A315B for ; Fri, 2 Nov 2018 06:53:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 3tqy32bSNXYu for ; Fri, 2 Nov 2018 06:53:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 158F25F437 for ; Fri, 2 Nov 2018 06:53:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 1133BE0E87 for ; Fri, 2 Nov 2018 06:53:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 8C03927766 for ; Fri, 2 Nov 2018 06:53:00 +0000 (UTC) Date: Fri, 2 Nov 2018 06:53:00 +0000 (UTC) From: "Paul King (JIRA)" To: notifications@groovy.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (GROOVY-8864) Backwards compatibility of traits MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King resolved GROOVY-8864. ------------------------------- Resolution: Fixed Assignee: Paul King Fix Version/s: 2.5.4 3.0.0-alpha-4 I have made our extra checks on generics not apply to traits. This retains the desired behavior from Groovy 2.4. I think we should look to improving the underlying approach to achieve this behavior since it is relying on generics information existing within the helper class that wouldn't be allowed for Java. It isn't a problem with existing JDKs but could leave us exposed if the strictness of class checking changed in future versions. > Backwards compatibility of traits > --------------------------------- > > Key: GROOVY-8864 > URL: https://issues.apache.org/jira/browse/GROOVY-8864 > Project: Groovy > Issue Type: Task > Affects Versions: 2.5.3 > Reporter: Paul King > Assignee: Paul King > Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.4 > > > In Groovy 2.4 we allow: > {code} > trait Foo { > static T get() { > ... > } > } > class Bar implements Foo {} > assert Bar.getMethod("get").returnType.name == 'Bar' > {code} > This produces some useful type information in the generated class: > {code} > class Bar implements Foo { > ... > static Bar get() { > ((Foo$Trait$Helper.get(this)) as Bar) > } > ... > } > {code} > It's a little strange in that a spurious generics type appears in the trait helper class for 2.4 but we ignore it: > {code} > static java.lang.Object get(java.lang.Class $static$self) { > ... > } > {code} > In 2.5, we tightened this up to behave more like Java where you can't use a class's generic type parameters in static methods or static fields. However, a trait isn't a class but rather a mechanism for creating classes. > This issue is to look at whether we can provide the 2.4 benefit of having type information in the generated class but avoid any spurious generics info appearing where it shouldn't. > As some additional information, the following example shows that even in 2.4, not all cases worked: > {code} > trait Foo { > static T get() { ... } > } > class Baz implements Foo {} > def bz = new Baz() > assert bz.getClass().getMethod("get").returnType == Object > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)