Re: Start shell/REPL without launching java monitor?
Any thoughts? Tzu-Li Chen 于2018年10月12日周五 上午10:54写道： > Hi Groovy community, > > I am new to Groovy and when running `groovysh` with "3.0.0-alpha-3, JVM: > 1.8.0_171" on macOS, I see a, hmm, Java monitor(?), named "GroovyShell" > launched. > > If I kill it, process `groovysh` quit with exception below. I'd like to > know if we can suppress the launch of "GroovyShell" process. It switch the > focus of cursor and quite annoying for me. > > Best, > tison. > > [printStackTrace]: > > ➜ ~ groovysh > Groovy Shell (3.0.0-alpha-3, JVM: 1.8.0_171) > Type ':help' or ':h' for help. > > --- > groovy:000> 2018-10-12 10:51:09.084 java[34387:1479007] > java.lang.SecurityException: Use of System.exit() is forbidden! > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at > org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83) > at > org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105) > at > org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:59) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:238) > at > org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:250) > at > org.codehaus.groovy.tools.shell.util.NoExitSecurityManager.checkExit(NoExitSecurityManager.groovy:51) > at java.lang.Runtime.exit(Runtime.java:107) > at java.lang.System.exit(System.java:971) > at com.apple.eawt._AppEventHandler.performQuit(_AppEventHandler.java:145) > at com.apple.eawt.QuitResponse.performQuit(QuitResponse.java:51) > at > com.apple.eawt._AppEventHandler$_QuitDispatcher.performDefaultAction(_AppEventHandler.java:390) > at > com.apple.eawt._AppEventHandler$_AppEventDispatcher.dispatch(_AppEventHandler.java:512) > at > com.apple.eawt._AppEventHandler.handleNativeNotification(_AppEventHandler.java:202) > >
Re: @Immutable backwards compatibility
Hi Cédric, Paul told me what had happened. We should try our best to keep binary compatibility between minor versions. Cheers, Daniel.Sun - Daniel Sun Apache Groovy committer Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Re: @Immutable backwards compatibility
Gotcha :-) - Daniel Sun Apache Groovy committer Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
Re: @Immutable backwards compatibility
On Sun, Oct 14, 2018 at 1:41 AM Daniel.Sun wrote: > Hi Cédric, > > > However, we discovered several regressions (in @CompileStatic, in > > covariant return type checking, ...) that may make the migration > painful. > According to the changed files shown in the PR ( > https://github.com/gradle/gradle/pull/6903/files ), it seems that the > migration is not that painful ;-) > > BTW, all changes for 2.5.x pass all existing tests in Groovy project. > If you find some breaking change, feel free to submit JIRA ticket to track. > The problem is that none of our tests in 2.5.x include tests against 2.4.x compiled code. This is what impacts Gradle, Grails and Micronaut plugins. They might be compiled with 2.4.x and then used with 2.5.x. The checkBinaryCompatibility task helps somewhat but we could no doubt also add some cross version integration tests as well. > > Cheers, > Daniel.Sun > > > > > - > Daniel Sun > Apache Groovy committer > Blog: http://blog.sunlan.me > Twitter: @daniel_sun > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html >
Re: @Immutable backwards compatibility
The "migration" may not be painful but breaking user builds or plugins when they upgrade Gradle is not cool. Several issues have been filed already as I understand. Le sam. 13 oct. 2018 à 17:41, Daniel.Sun a écrit : > Hi Cédric, > > > However, we discovered several regressions (in @CompileStatic, in > > covariant return type checking, ...) that may make the migration > painful. > According to the changed files shown in the PR ( > https://github.com/gradle/gradle/pull/6903/files ), it seems that the > migration is not that painful ;-) > > BTW, all changes for 2.5.x pass all existing tests in Groovy project. > If you find some breaking change, feel free to submit JIRA ticket to track. > > Cheers, > Daniel.Sun > > > > > - > Daniel Sun > Apache Groovy committer > Blog: http://blog.sunlan.me > Twitter: @daniel_sun > > -- > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html >
Re: @Immutable backwards compatibility
Hi Cédric, > However, we discovered several regressions (in @CompileStatic, in > covariant return type checking, ...) that may make the migration painful. According to the changed files shown in the PR ( https://github.com/gradle/gradle/pull/6903/files ), it seems that the migration is not that painful ;-) BTW, all changes for 2.5.x pass all existing tests in Groovy project. If you find some breaking change, feel free to submit JIRA ticket to track. Cheers, Daniel.Sun - Daniel Sun Apache Groovy committer Blog: http://blog.sunlan.me Twitter: @daniel_sun -- Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
