[jira] [Resolved] (GROOVY-8864) Backwards compatibility of traits
[
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)
[jira] [Updated] (GROOVY-8864) Backwards compatibility of traits
[
https://issues.apache.org/jira/browse/GROOVY-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8864:
--
Affects Version/s: 2.5.3
> 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)
[jira] [Resolved] (GROOVY-8865) Specifying initial heap size results in an error
[
https://issues.apache.org/jira/browse/GROOVY-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King resolved GROOVY-8865.
---
Resolution: Fixed
Assignee: Paul King
Fix Version/s: 2.5.4
3.0.0-alpha-4
I have removed our explicit setting. Reading up on the default value for that
setting on current JVMs, I suspect it will be set to a higher value on most
folks systems.
> Specifying initial heap size results in an error
>
>
> Key: GROOVY-8865
> URL: https://issues.apache.org/jira/browse/GROOVY-8865
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.3
> Environment: Windows 10, OpenJDK 11.0.1
>Reporter: Rostyslav Smirnov
>Assignee: Paul King
>Priority: Major
> Labels: contrib
> Fix For: 3.0.0-alpha-4, 2.5.4
>
>
> On Windows, setting initial heap size greater than 128MB without setting
> maximum heap size, e.g. JAVA_OPTS=-Xms1G, results in the following error:
> {quote}Error occurred during initialization of VM
> Initial heap size set to a larger value than the maximum heap size
> {quote}
> This works fine on Linux. And it is a valid JVM parameter, since JVM will set
> its maximum heap to be the greater of its default value and initial heap size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GROOVY-8865) Specifying initial heap size results in an error
[
https://issues.apache.org/jira/browse/GROOVY-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-8865:
--
Labels: contrib (was: )
> Specifying initial heap size results in an error
>
>
> Key: GROOVY-8865
> URL: https://issues.apache.org/jira/browse/GROOVY-8865
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.3
> Environment: Windows 10, OpenJDK 11.0.1
>Reporter: Rostyslav Smirnov
>Priority: Major
> Labels: contrib
>
> On Windows, setting initial heap size greater than 128MB without setting
> maximum heap size, e.g. JAVA_OPTS=-Xms1G, results in the following error:
> {quote}Error occurred during initialization of VM
> Initial heap size set to a larger value than the maximum heap size
> {quote}
> This works fine on Linux. And it is a valid JVM parameter, since JVM will set
> its maximum heap to be the greater of its default value and initial heap size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8865) Specifying initial heap size results in an error
[
https://issues.apache.org/jira/browse/GROOVY-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672184#comment-16672184
]
Paul King commented on GROOVY-8865:
---
Okay, understood. Looks like we hard code a value for -Xmx:
https://github.com/apache/groovy/blob/master/src/bin/startGroovy.bat#L262
Obviously we should not do that if a user supplies their own -Xmx and/or the
value should be at least as big as any -Xms setting.
> Specifying initial heap size results in an error
>
>
> Key: GROOVY-8865
> URL: https://issues.apache.org/jira/browse/GROOVY-8865
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.3
> Environment: Windows 10, OpenJDK 11.0.1
>Reporter: Rostyslav Smirnov
>Priority: Major
>
> On Windows, setting initial heap size greater than 128MB without setting
> maximum heap size, e.g. JAVA_OPTS=-Xms1G, results in the following error:
> {quote}Error occurred during initialization of VM
> Initial heap size set to a larger value than the maximum heap size
> {quote}
> This works fine on Linux. And it is a valid JVM parameter, since JVM will set
> its maximum heap to be the greater of its default value and initial heap size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8865) Specifying initial heap size results in an error
[
https://issues.apache.org/jira/browse/GROOVY-8865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16672061#comment-16672061
]
Rostyslav Smirnov commented on GROOVY-8865:
---
The problem is with the way Groovy initializes JVM. There is no stacktrace, the
error is the only output.
> Specifying initial heap size results in an error
>
>
> Key: GROOVY-8865
> URL: https://issues.apache.org/jira/browse/GROOVY-8865
> Project: Groovy
> Issue Type: Bug
> Components: groovy-runtime
>Affects Versions: 2.5.3
> Environment: Windows 10, OpenJDK 11.0.1
>Reporter: Rostyslav Smirnov
>Priority: Major
>
> On Windows, setting initial heap size greater than 128MB without setting
> maximum heap size, e.g. JAVA_OPTS=-Xms1G, results in the following error:
> {quote}Error occurred during initialization of VM
> Initial heap size set to a larger value than the maximum heap size
> {quote}
> This works fine on Linux. And it is a valid JVM parameter, since JVM will set
> its maximum heap to be the greater of its default value and initial heap size.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
[ https://issues.apache.org/jira/browse/GROOVY-8866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16671814#comment-16671814 ] ASF GitHub Bot commented on GROOVY-8866: GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/818 GROOVY-8866: Implement `GProperties` to handle properties file smartly You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy gproperties Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/818.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #818 commit 26c11ead52c31992b4be5a66c841c585ddd4ca13 Author: danielsun1106 Date: 2018-11-01T16:11:23Z GROOVY-8866: Implement `GProperties` to handle properties file smartly > Implement `GProperties` to handle properties file smartly > - > > Key: GROOVY-8866 > URL: https://issues.apache.org/jira/browse/GROOVY-8866 > Project: Groovy > Issue Type: New Feature >Reporter: Daniel Sun >Assignee: Daniel Sun >Priority: Major > Fix For: 3.0.0-alpha-4, 2.5.4 > > > The `GProperties` supports interpolating in the values and importing other > properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] groovy pull request #818: GROOVY-8866: Implement `GProperties` to handle pro...
GitHub user danielsun1106 opened a pull request: https://github.com/apache/groovy/pull/818 GROOVY-8866: Implement `GProperties` to handle properties file smartly You can merge this pull request into a Git repository by running: $ git pull https://github.com/danielsun1106/groovy gproperties Alternatively you can review and apply these changes as the patch at: https://github.com/apache/groovy/pull/818.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #818 commit 26c11ead52c31992b4be5a66c841c585ddd4ca13 Author: danielsun1106 Date: 2018-11-01T16:11:23Z GROOVY-8866: Implement `GProperties` to handle properties file smartly ---
[jira] [Created] (GROOVY-8866) Implement `GProperties` to handle properties file smartly
Daniel Sun created GROOVY-8866: -- Summary: Implement `GProperties` to handle properties file smartly Key: GROOVY-8866 URL: https://issues.apache.org/jira/browse/GROOVY-8866 Project: Groovy Issue Type: New Feature Reporter: Daniel Sun Assignee: Daniel Sun Fix For: 3.0.0-alpha-4, 2.5.4 The `GProperties` supports interpolating in the values and importing other properties in classpath -- This message was sent by Atlassian JIRA (v7.6.3#76005)
