[jira] [Updated] (GROOVY-8591) Consider additional target bytecode checks and/or simplification in some areas
[
https://issues.apache.org/jira/browse/GROOVY-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8591:
--
Summary: Consider additional target bytecode checks and/or simplification
in some areas (was: Consider additional target bytecode checks)
> Consider additional target bytecode checks and/or simplification in some areas
> --
>
> Key: GROOVY-8591
> URL: https://issues.apache.org/jira/browse/GROOVY-8591
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> As part of fixing GROOVY-8579, I noticed that we don't do many checks for
> bytecode version. There are several areas that are possibly worth addressing:
> * In CompilerConfiguration we have a minimum bytecode version but we don't
> give an error or warning if the bytecode version is set to a value below the
> minimum version. If we did, would we even need the old, e.g. 1.4, 1.5 values
> in the allowed JDKs list? One option is to just check at the periphery, e.g.
> in groovyc/groovy options and assume people using the api know what they are
> doing?
> * There are some places where we produce very vanilla bytecodes and don't
> require a very high bytecode level, e.g. {{ProxyGeneratorAdapter}} (currently
> V1_5). Should we align those also with the minimum JDK version?
> * We have some checks that make sure we are using an annotation compatible
> JDK. These can surely be removed/simplified. Examples: ExtendedVerifier,
> JavaAwareCompilationUnit, JavaStubCompilationUnit.
> * We have some checks to ensure that we have a high enough bytecode level
> when using indy. Since our minimum (Groovy 2.5+) is now high enough to
> support indy, many of theose checks could be simplified/removed. One example
> is in {{WriterController#chooseBytecodeVersion}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8591) Consider additional target bytecode checks
[
https://issues.apache.org/jira/browse/GROOVY-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8591:
--
Description:
As part of fixing GROOVY-8579, I noticed that we don't do many checks for
bytecode version. There are several areas that are possibly worth addressing:
* In CompilerConfiguration we have a minimum bytecode version but we don't give
an error or warning if the bytecode version is set to a value below the minimum
version. If we did, would we even need the old, e.g. 1.4, 1.5 values in the
allowed JDKs list? One option is to just check at the periphery, e.g. in
groovyc/groovy options and assume people using the api know what they are doing?
* There are some places where we produce very vanilla bytecodes and don't
require a very high bytecode level, e.g. {{ProxyGeneratorAdapter}} (currently
V1_5). Should we align those also with the minimum JDK version?
* We have some checks that make sure we are using an annotation compatible JDK.
These can surely be removed/simplified. Examples: ExtendedVerifier,
JavaAwareCompilationUnit, JavaStubCompilationUnit.
* We have some checks to ensure that we have a high enough bytecode level when
using indy. Since our minimum (Groovy 2.5+) is now high enough to support indy,
many of theose checks could be simplified/removed. One example is in
{{WriterController#chooseBytecodeVersion}}.
> Consider additional target bytecode checks
> --
>
> Key: GROOVY-8591
> URL: https://issues.apache.org/jira/browse/GROOVY-8591
> Project: Groovy
> Issue Type: Improvement
>Reporter: Paul King
>Priority: Major
>
> As part of fixing GROOVY-8579, I noticed that we don't do many checks for
> bytecode version. There are several areas that are possibly worth addressing:
> * In CompilerConfiguration we have a minimum bytecode version but we don't
> give an error or warning if the bytecode version is set to a value below the
> minimum version. If we did, would we even need the old, e.g. 1.4, 1.5 values
> in the allowed JDKs list? One option is to just check at the periphery, e.g.
> in groovyc/groovy options and assume people using the api know what they are
> doing?
> * There are some places where we produce very vanilla bytecodes and don't
> require a very high bytecode level, e.g. {{ProxyGeneratorAdapter}} (currently
> V1_5). Should we align those also with the minimum JDK version?
> * We have some checks that make sure we are using an annotation compatible
> JDK. These can surely be removed/simplified. Examples: ExtendedVerifier,
> JavaAwareCompilationUnit, JavaStubCompilationUnit.
> * We have some checks to ensure that we have a high enough bytecode level
> when using indy. Since our minimum (Groovy 2.5+) is now high enough to
> support indy, many of theose checks could be simplified/removed. One example
> is in {{WriterController#chooseBytecodeVersion}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GROOVY-8591) Consider additional target bytecode checks
Paul King created GROOVY-8591: - Summary: Consider additional target bytecode checks Key: GROOVY-8591 URL: https://issues.apache.org/jira/browse/GROOVY-8591 Project: Groovy Issue Type: Improvement Reporter: Paul King -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #:
Github user danielsun1106 commented on the pull request: https://github.com/apache/groovy/commit/869c365161457c050d5a54c7ff43d73d3263f34e#commitcomment-29055018 I've synchronized your changes to https://github.com/danielsun1106/groovy-parser with your contribution info kept ;-) https://github.com/danielsun1106/groovy-parser/commit/757eace44e5764983332cca5cd9e2801396cae52 ---
[jira] [Comment Edited] (GROOVY-6167) Generics: within a single declaration, generic type definition order matters
[
https://issues.apache.org/jira/browse/GROOVY-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479373#comment-16479373
]
Daniel Sun edited comment on GROOVY-6167 at 5/20/18 11:46 PM:
--
Fixed by
[https://github.com/apache/groovy/commit/0f187102660593d9d95d486ba4b62f5091cc4580]
[https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394]
https://github.com/apache/groovy/commit/3ff3111fc033bf74ecdbbc4f69e0fc0f76fbdf26
was (Author: daniel_sun):
Fixed by
https://github.com/apache/groovy/commit/0f187102660593d9d95d486ba4b62f5091cc4580
https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394
> Generics: within a single declaration, generic type definition order matters
>
>
> Key: GROOVY-6167
> URL: https://issues.apache.org/jira/browse/GROOVY-6167
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.1.0, 2.4.0-beta-3
>Reporter: Davide Cavestro
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.0-rc-3
>
>
> The following is valid Java code, but the groovyc fails complaining
> {color:red}_unable to resolve class X_
> {color}
> {code:java}
> public class Foo, X extends Number>{}
> {code}
> while changing the generic type definition order it works
> {code:java}
> public class Foo>{}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GROOVY-6167) Generics: within a single declaration, generic type definition order matters
[
https://issues.apache.org/jira/browse/GROOVY-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16479373#comment-16479373
]
Daniel Sun edited comment on GROOVY-6167 at 5/20/18 4:19 PM:
-
Fixed by
https://github.com/apache/groovy/commit/0f187102660593d9d95d486ba4b62f5091cc4580
https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394
was (Author: daniel_sun):
Fixed by
https://github.com/apache/groovy/commit/48807d5b1ba094e2f0dc212b6c92b4b370fe8394
> Generics: within a single declaration, generic type definition order matters
>
>
> Key: GROOVY-6167
> URL: https://issues.apache.org/jira/browse/GROOVY-6167
> Project: Groovy
> Issue Type: Bug
> Components: Compiler
>Affects Versions: 2.1.0, 2.4.0-beta-3
>Reporter: Davide Cavestro
>Assignee: Daniel Sun
>Priority: Major
> Fix For: 2.6.0-alpha-4, 3.0.0-alpha-3, 2.5.0-rc-3
>
>
> The following is valid Java code, but the groovyc fails complaining
> {color:red}_unable to resolve class X_
> {color}
> {code:java}
> public class Foo, X extends Number>{}
> {code}
> while changing the generic type definition order it works
> {code:java}
> public class Foo>{}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
