Experimental: Easier compiler level switching in Groovy-Eclipse

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Experimental: Easier compiler level switching in Groovy-Eclipse

Andrew Eisenberg
Hi all,

I would like to get some feedback on an experimental new feature in
Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level
on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17
or
eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should
be possible to open two instances of Eclipse at the same time using
different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line
mucking around with the OSGi runtime is finicky and so I would like to
hear from some users if they have any problems.  Thanks and please let
me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

IllegalAccessException at runtime

Thomas Hofmann
Hi there,

I have been trying to find out what the cause for this problem is for some hours now and I think it is the right time to ask for help from the experts now:)

I am getting the following exception at runtime:

java.lang.IllegalAccessError: tried to access class com.ibm.imediade.rft.TestScript$_closure1 from class com.ibm.imediade.rft.TestScript

Now this of course sounds strange since the closure in the TestScript class should be accessible by the class itself.

I googled and found some solutions that implied that multiple classloaders were used when the problem occurred. I figured that if the closure class would have been loaded by a different class loader than the TestScript class the package private visibility would not work out.

So I took a heap dump to see which class is loaded by which classloader. Unfortunatley, the TestScript$_closure1 is not part of the dump. I'm not sure if this is normal when an IlegalAccessError is thrown.

I have attached the class files to this post. I already used javap to see what is going on but could not see anything wrong with the byte code.

I have a similar class called Init, which adds some methods to meta classes. It too has some closure classes being generated by the compiler. The Init class is able to access the contained closures. I have attached them too any from the javap output I could not determine any difference that would cause the problem.

I tried to run with different JREs (Oracle, an older version of the JDK 6.22 and IBM J9 VM) and all give me the same result.
I add the -XX:+TraceClassLoading switch to the Oracle JRE I noticed some strangeness regarding the class loading of the TestScript classes:

[Loaded com.ibm.imediade.rft.TestScript from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded resources.Script3Helper from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded Script3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure4 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure5 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2_closure6 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andrew Eisenberg
Sent: Dienstag, 19. Juli 2011 23:39
To: [hidden email]; [hidden email]
Subject: [groovy-eclipse-plugin-user] Experimental: Easier compiler level switching in Groovy-Eclipse

Hi all,

I would like to get some feedback on an experimental new feature in Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17 or eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should be possible to open two instances of Eclipse at the same time using different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line mucking around with the OSGi runtime is finicky and so I would like to hear from some users if they have any problems.  Thanks and please let me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

IllegalAccessException at runtime - reposting complete message

Thomas Hofmann
In reply to this post by Andrew Eisenberg
Sorry, for the not complete mail I posted a few minutes ago. Here is the complete one:


Hi there,

I have been trying to find out what the cause for this problem is for some hours now and I think it is the right time to ask for help from the experts now:)

I am getting the following exception at runtime:

java.lang.IllegalAccessError: tried to access class com.ibm.imediade.rft.TestScript$_closure1 from class com.ibm.imediade.rft.TestScript

Now this of course sounds strange since the closure in the TestScript class should be accessible by the class itself.

I googled and found some solutions that implied that multiple classloaders were used when the problem occurred. I figured that if the closure class would have been loaded by a different class loader than the TestScript class the package private visibility would not work out.

So I took a heap dump to see which class is loaded by which classloader. Unfortunatley, the TestScript$_closure1 is not part of the dump. I'm not sure if this is normal when an IlegalAccessError is thrown.

I have attached the class files to this post. I already used javap to see what is going on but could not see anything wrong with the byte code.

I have a similar class called Init, which adds some methods to meta classes. It too has some closure classes being generated by the compiler. The Init class is able to access the contained closures. I have attached them too any from the javap output I could not determine any difference that would cause the problem.

I tried to run with different JREs (Oracle, an older version of the JDK 6.22 and IBM J9 VM) and all give me the same result.
I add the -XX:+TraceClassLoading switch to the Oracle JRE I noticed some strangeness regarding the class loading of the TestScript classes:

[Loaded com.ibm.imediade.rft.TestScript from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded resources.Script3Helper from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded Script3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.UseCaseInteractionTestScript from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure4 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure5 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2_closure6 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.TestScript$_closure1 from file:/C:/ws/vedoc%20functional%20tests%202.1/vedoc%20functional%20tests/bin/]

All classes in the class hierarchy are loaded from  file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar which does not really make sense since they are not in this jar file.
The TestScript$_closure1 is loaded from a bin directory where all the other class files that are mentioned above also exist.
Now, I suspect that this is the problem. Probably, different class loaders are used which would explain why the closure cannot be accessed.
I could run the program without any problems until a few days ago. I then started to work on some related things and wanting to see if everything still works I noticed the problem with the IllegalAccessError. I am not aware of any breaking changes I made but there must of course be something that is different now.

Maybe someone can verify that at least the class files are OK or even better provide me with some more hints on how to find out what exactly is causing this.

Thanks, Thomas

BTW: What does Groovy do when I call a closure from a subclass in a different package? How does access to the package private closure class work in that case?


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andrew Eisenberg
Sent: Dienstag, 19. Juli 2011 23:39
To: [hidden email]; [hidden email]
Subject: [groovy-eclipse-plugin-user] Experimental: Easier compiler level switching in Groovy-Eclipse

Hi all,

I would like to get some feedback on an experimental new feature in Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17 or eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should be possible to open two instances of Eclipse at the same time using different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line mucking around with the OSGi runtime is finicky and so I would like to hear from some users if they have any problems.  Thanks and please let me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

TestScript.class (82K) Download Attachment
TestScript$_closure1.class (4K) Download Attachment
Init.class (7K) Download Attachment
Init$__clinit__closure1.class (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: IllegalAccessException at runtime - reposting complete message

Thomas Hofmann
Hi again,

I found the problem. Apparently, I decided to use a bin subdirectory of project for the compiler output (nothing unusual). When I switched back to the default configuration of my project (which places the class files directly in the project dir) everything works. Now, the closure class is also loaded throught the same file path / classloader. I don't know what that specific classloader is doing but in essence it is clear now that this in fact was a classloader issue.

Thanks anyway, Thomas

-----Original Message-----
From: Thomas Hofmann [mailto:[hidden email]]
Sent: Mittwoch, 20. Juli 2011 14:52
To: [hidden email]; [hidden email]
Subject: [groovy-eclipse-plugin-user] IllegalAccessException at runtime - reposting complete message

Sorry, for the not complete mail I posted a few minutes ago. Here is the complete one:


Hi there,

I have been trying to find out what the cause for this problem is for some hours now and I think it is the right time to ask for help from the experts now:)

I am getting the following exception at runtime:

java.lang.IllegalAccessError: tried to access class com.ibm.imediade.rft.TestScript$_closure1 from class com.ibm.imediade.rft.TestScript

Now this of course sounds strange since the closure in the TestScript class should be accessible by the class itself.

I googled and found some solutions that implied that multiple classloaders were used when the problem occurred. I figured that if the closure class would have been loaded by a different class loader than the TestScript class the package private visibility would not work out.

So I took a heap dump to see which class is loaded by which classloader. Unfortunatley, the TestScript$_closure1 is not part of the dump. I'm not sure if this is normal when an IlegalAccessError is thrown.

I have attached the class files to this post. I already used javap to see what is going on but could not see anything wrong with the byte code.

I have a similar class called Init, which adds some methods to meta classes. It too has some closure classes being generated by the compiler. The Init class is able to access the contained closures. I have attached them too any from the javap output I could not determine any difference that would cause the problem.

I tried to run with different JREs (Oracle, an older version of the JDK 6.22 and IBM J9 VM) and all give me the same result.
I add the -XX:+TraceClassLoading switch to the Oracle JRE I noticed some strangeness regarding the class loading of the TestScript classes:

[Loaded com.ibm.imediade.rft.TestScript from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded resources.Script3Helper from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded Script3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.UseCaseInteractionTestScript from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure3 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure4 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure1_closure5 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.shared.util.Init$__clinit__closure2_closure6 from file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar]
[Loaded com.ibm.imediade.rft.TestScript$_closure1 from file:/C:/ws/vedoc%20functional%20tests%202.1/vedoc%20functional%20tests/bin/]

All classes in the class hierarchy are loaded from  file:/C:/SDPShared/plugins/com.ibm.rational.test.ft.util_8.1.1.v20110309_0553.jar which does not really make sense since they are not in this jar file.
The TestScript$_closure1 is loaded from a bin directory where all the other class files that are mentioned above also exist.
Now, I suspect that this is the problem. Probably, different class loaders are used which would explain why the closure cannot be accessed.
I could run the program without any problems until a few days ago. I then started to work on some related things and wanting to see if everything still works I noticed the problem with the IllegalAccessError. I am not aware of any breaking changes I made but there must of course be something that is different now.

Maybe someone can verify that at least the class files are OK or even better provide me with some more hints on how to find out what exactly is causing this.

Thanks, Thomas

BTW: What does Groovy do when I call a closure from a subclass in a different package? How does access to the package private closure class work in that case?


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andrew Eisenberg
Sent: Dienstag, 19. Juli 2011 23:39
To: [hidden email]; [hidden email]
Subject: [groovy-eclipse-plugin-user] Experimental: Easier compiler level switching in Groovy-Eclipse

Hi all,

I would like to get some feedback on an experimental new feature in Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17 or eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should be possible to open two instances of Eclipse at the same time using different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line mucking around with the OSGi runtime is finicky and so I would like to hear from some users if they have any problems.  Thanks and please let me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

John Bito
In reply to this post by Andrew Eisenberg
Hey Andrew,

We have code that doesn't work when compiled by the Groovy 1.8.0 compiler. It seems to be OK with 1.8.1. Can we configure Groovy-Eclipse to use the compiler from the new release?

Thanks!
John

On Tue, Jul 19, 2011 at 14:39, Andrew Eisenberg <[hidden email]> wrote:
Hi all,

I would like to get some feedback on an experimental new feature in
Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level
on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17
or
eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should
be possible to open two instances of Eclipse at the same time using
different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line
mucking around with the OSGi runtime is finicky and so I would like to
hear from some users if they have any problems.  Thanks and please let
me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Andy Clement
Hi John,

You need to wait for Groovy-Eclipse to upgrade to Groovy 1.8.1.  This
should happen this week.  The compiler switching feature Andrew
mentioned is just for choosing between supported version of the
patched groovy compilers we use (so 1.7.10 or 1.8.0 right now), it
isn't for plugging in any groovy build.

cheers
Andy

On 26 July 2011 17:16, John Bito <[hidden email]> wrote:

> Hey Andrew,
>
> We have code that doesn't work when compiled by the Groovy 1.8.0 compiler.
> It seems to be OK with 1.8.1. Can we configure Groovy-Eclipse to use the
> compiler from the new release?
>
> Thanks!
> John
>
> On Tue, Jul 19, 2011 at 14:39, Andrew Eisenberg <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I would like to get some feedback on an experimental new feature in
>> Groovy-Eclipse that allows easier switching between compiler levels.
>> Download the latest dev build and you can specify the compiler level
>> on the command line.  Eg-
>>
>> eclipse -vmargs -Dgroovy.compiler.level=17
>> or
>> eclipse -vmargs -Dgroovy.compiler.level=18
>>
>> You can also specify this option in the eclipse.ini file.  It should
>> be possible to open two instances of Eclipse at the same time using
>> different compiler levels (but they must use different workspaces).
>>
>> I have tried this out on my machine, but this kind of command line
>> mucking around with the OSGi runtime is finicky and so I would like to
>> hear from some users if they have any problems.  Thanks and please let
>> me know if you try it.
>>
>> Andrew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Matthew Passell
In reply to this post by Andrew Eisenberg
Hi Andrew,

Would there be a way to tie such a setting to a workspace rather than to the Eclipse startup settings?  I have separate workspaces for two different versions of a project, one using Groovy 1.7.x and the other Groovy 1.8.x.  It would be great if I could continue to launch the same Eclipse installation, but use the appropriate Groovy version for the selected workspace.

Thanks,
Matt


On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]> wrote:
Hi all,

I would like to get some feedback on an experimental new feature in
Groovy-Eclipse that allows easier switching between compiler levels.
Download the latest dev build and you can specify the compiler level
on the command line.  Eg-

eclipse -vmargs -Dgroovy.compiler.level=17
or
eclipse -vmargs -Dgroovy.compiler.level=18

You can also specify this option in the eclipse.ini file.  It should
be possible to open two instances of Eclipse at the same time using
different compiler levels (but they must use different workspaces).

I have tried this out on my machine, but this kind of command line
mucking around with the OSGi runtime is finicky and so I would like to
hear from some users if they have any problems.  Thanks and please let
me know if you try it.

Andrew

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email
Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Andrew Eisenberg
Unfortunately, no.  The reason is that the choice between using the
1.7 or 1.8 compiler needs to be made very early on, before most other
plugins have been started.  By the time the plugins that allow access
to the workspace settings have been started the groovy compiler level
has already been chosen.

The best that I can do is just to have 2 different startup commands,
one for each workspace.  Also, note that you can hard-code the
workspace to use by running with the '-data <workspace_loc'> option
set.

On Wed, Jul 27, 2011 at 10:04 AM, Matt Passell
<[hidden email]> wrote:

> Hi Andrew,
> Would there be a way to tie such a setting to a workspace rather than to the
> Eclipse startup settings?  I have separate workspaces for two different
> versions of a project, one using Groovy 1.7.x and the other Groovy 1.8.x.
>  It would be great if I could continue to launch the same Eclipse
> installation, but use the appropriate Groovy version for the selected
> workspace.
> Thanks,
> Matt
>
>
> On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Hi all,
>>
>> I would like to get some feedback on an experimental new feature in
>> Groovy-Eclipse that allows easier switching between compiler levels.
>> Download the latest dev build and you can specify the compiler level
>> on the command line.  Eg-
>>
>> eclipse -vmargs -Dgroovy.compiler.level=17
>> or
>> eclipse -vmargs -Dgroovy.compiler.level=18
>>
>> You can also specify this option in the eclipse.ini file.  It should
>> be possible to open two instances of Eclipse at the same time using
>> different compiler levels (but they must use different workspaces).
>>
>> I have tried this out on my machine, but this kind of command line
>> mucking around with the OSGi runtime is finicky and so I would like to
>> hear from some users if they have any problems.  Thanks and please let
>> me know if you try it.
>>
>> Andrew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Matthew Passell
OK, no big deal.  I can live with that restriction.  However, when I tried launching with the 1.7 compiler, I got a stacktrace including the following:

java.lang.IllegalArgumentException: Specified version of Groovy not found. Available versions are: null
at org.codehaus.groovy.frameworkadapter.CompilerHook.checkVersionFound(CompilerHook.java:155)
at org.codehaus.groovy.frameworkadapter.CompilerHook.frameworkStart(CompilerHook.java:134)
at org.eclipse.osgi.baseadaptor.BaseAdaptor.frameworkStart(BaseAdaptor.java:242)

I'm using the latest Groovy Eclipse dev snapshot in Eclipse 3.6.  Is this only working in the version for 3.7?

Thanks,
Matt


On Wed, Jul 27, 2011 at 2:47 PM, Andrew Eisenberg <[hidden email]> wrote:
Unfortunately, no.  The reason is that the choice between using the
1.7 or 1.8 compiler needs to be made very early on, before most other
plugins have been started.  By the time the plugins that allow access
to the workspace settings have been started the groovy compiler level
has already been chosen.

The best that I can do is just to have 2 different startup commands,
one for each workspace.  Also, note that you can hard-code the
workspace to use by running with the '-data <workspace_loc'> option
set.

On Wed, Jul 27, 2011 at 10:04 AM, Matt Passell
<[hidden email]> wrote:
> Hi Andrew,
> Would there be a way to tie such a setting to a workspace rather than to the
> Eclipse startup settings?  I have separate workspaces for two different
> versions of a project, one using Groovy 1.7.x and the other Groovy 1.8.x.
>  It would be great if I could continue to launch the same Eclipse
> installation, but use the appropriate Groovy version for the selected
> workspace.
> Thanks,
> Matt
>
>
> On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Hi all,
>>
>> I would like to get some feedback on an experimental new feature in
>> Groovy-Eclipse that allows easier switching between compiler levels.
>> Download the latest dev build and you can specify the compiler level
>> on the command line.  Eg-
>>
>> eclipse -vmargs -Dgroovy.compiler.level=17
>> or
>> eclipse -vmargs -Dgroovy.compiler.level=18
>>
>> You can also specify this option in the eclipse.ini file.  It should
>> be possible to open two instances of Eclipse at the same time using
>> different compiler levels (but they must use different workspaces).
>>
>> I have tried this out on my machine, but this kind of command line
>> mucking around with the OSGi runtime is finicky and so I would like to
>> hear from some users if they have any problems.  Thanks and please let
>> me know if you try it.
>>
>> Andrew
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Andrew Eisenberg
I just tried it again on 3.6 and didn't have any troubles with the switching.

What exactly is the command line that you used?  Also, can you send
over your configuration details?

Eclipse -> About Eclipse -> installation details -> Configuration ->
Copy to clipboard.

Hopefully, we can figure out what is going on.

On Wed, Jul 27, 2011 at 1:45 PM, Matt Passell
<[hidden email]> wrote:

> OK, no big deal.  I can live with that restriction.  However, when I tried
> launching with the 1.7 compiler, I got a stacktrace including the following:
> java.lang.IllegalArgumentException: Specified version of Groovy not found.
> Available versions are: null
> at
> org.codehaus.groovy.frameworkadapter.CompilerHook.checkVersionFound(CompilerHook.java:155)
> at
> org.codehaus.groovy.frameworkadapter.CompilerHook.frameworkStart(CompilerHook.java:134)
> at
> org.eclipse.osgi.baseadaptor.BaseAdaptor.frameworkStart(BaseAdaptor.java:242)
> I'm using the latest Groovy Eclipse dev snapshot in Eclipse 3.6.  Is this
> only working in the version for 3.7?
> Thanks,
> Matt
>
>
> On Wed, Jul 27, 2011 at 2:47 PM, Andrew Eisenberg <[hidden email]>
> wrote:
>>
>> Unfortunately, no.  The reason is that the choice between using the
>> 1.7 or 1.8 compiler needs to be made very early on, before most other
>> plugins have been started.  By the time the plugins that allow access
>> to the workspace settings have been started the groovy compiler level
>> has already been chosen.
>>
>> The best that I can do is just to have 2 different startup commands,
>> one for each workspace.  Also, note that you can hard-code the
>> workspace to use by running with the '-data <workspace_loc'> option
>> set.
>>
>> On Wed, Jul 27, 2011 at 10:04 AM, Matt Passell
>> <[hidden email]> wrote:
>> > Hi Andrew,
>> > Would there be a way to tie such a setting to a workspace rather than to
>> > the
>> > Eclipse startup settings?  I have separate workspaces for two different
>> > versions of a project, one using Groovy 1.7.x and the other Groovy
>> > 1.8.x.
>> >  It would be great if I could continue to launch the same Eclipse
>> > installation, but use the appropriate Groovy version for the selected
>> > workspace.
>> > Thanks,
>> > Matt
>> >
>> >
>> > On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]>
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> I would like to get some feedback on an experimental new feature in
>> >> Groovy-Eclipse that allows easier switching between compiler levels.
>> >> Download the latest dev build and you can specify the compiler level
>> >> on the command line.  Eg-
>> >>
>> >> eclipse -vmargs -Dgroovy.compiler.level=17
>> >> or
>> >> eclipse -vmargs -Dgroovy.compiler.level=18
>> >>
>> >> You can also specify this option in the eclipse.ini file.  It should
>> >> be possible to open two instances of Eclipse at the same time using
>> >> different compiler levels (but they must use different workspaces).
>> >>
>> >> I have tried this out on my machine, but this kind of command line
>> >> mucking around with the OSGi runtime is finicky and so I would like to
>> >> hear from some users if they have any problems.  Thanks and please let
>> >> me know if you try it.
>> >>
>> >> Andrew
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe from this list, please visit:
>> >>
>> >>    http://xircles.codehaus.org/manage_email
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Andrew Eisenberg
OK Matt,

Thanks for the configuration files.  As we talked about, it looks like
MyEclipse may be causing some strange things to happen.  I was able to
install MyEclipse and get it to respect the groovy.compiler.level
property by editing the myeclipse.ini file.  This appears to work for
me.  However, since it is associated directly with the executable, you
would need two installations to have this work properly.  Instead, you
would need to launch from the command line and include the
groovy.compiler.level on the command line.

However, I'm finding it a bit cryptic to launch MyEclipse from the
command line.  Perhaps you have more familiarity with this and would
know how.

I'm on mac.  This shouldn't make a difference, but you never know with
these kinds of things.

--a

On Wed, Jul 27, 2011 at 10:14 PM, Andrew Eisenberg <[hidden email]> wrote:

> I just tried it again on 3.6 and didn't have any troubles with the switching.
>
> What exactly is the command line that you used?  Also, can you send
> over your configuration details?
>
> Eclipse -> About Eclipse -> installation details -> Configuration ->
> Copy to clipboard.
>
> Hopefully, we can figure out what is going on.
>
> On Wed, Jul 27, 2011 at 1:45 PM, Matt Passell
> <[hidden email]> wrote:
>> OK, no big deal.  I can live with that restriction.  However, when I tried
>> launching with the 1.7 compiler, I got a stacktrace including the following:
>> java.lang.IllegalArgumentException: Specified version of Groovy not found.
>> Available versions are: null
>> at
>> org.codehaus.groovy.frameworkadapter.CompilerHook.checkVersionFound(CompilerHook.java:155)
>> at
>> org.codehaus.groovy.frameworkadapter.CompilerHook.frameworkStart(CompilerHook.java:134)
>> at
>> org.eclipse.osgi.baseadaptor.BaseAdaptor.frameworkStart(BaseAdaptor.java:242)
>> I'm using the latest Groovy Eclipse dev snapshot in Eclipse 3.6.  Is this
>> only working in the version for 3.7?
>> Thanks,
>> Matt
>>
>>
>> On Wed, Jul 27, 2011 at 2:47 PM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> Unfortunately, no.  The reason is that the choice between using the
>>> 1.7 or 1.8 compiler needs to be made very early on, before most other
>>> plugins have been started.  By the time the plugins that allow access
>>> to the workspace settings have been started the groovy compiler level
>>> has already been chosen.
>>>
>>> The best that I can do is just to have 2 different startup commands,
>>> one for each workspace.  Also, note that you can hard-code the
>>> workspace to use by running with the '-data <workspace_loc'> option
>>> set.
>>>
>>> On Wed, Jul 27, 2011 at 10:04 AM, Matt Passell
>>> <[hidden email]> wrote:
>>> > Hi Andrew,
>>> > Would there be a way to tie such a setting to a workspace rather than to
>>> > the
>>> > Eclipse startup settings?  I have separate workspaces for two different
>>> > versions of a project, one using Groovy 1.7.x and the other Groovy
>>> > 1.8.x.
>>> >  It would be great if I could continue to launch the same Eclipse
>>> > installation, but use the appropriate Groovy version for the selected
>>> > workspace.
>>> > Thanks,
>>> > Matt
>>> >
>>> >
>>> > On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I would like to get some feedback on an experimental new feature in
>>> >> Groovy-Eclipse that allows easier switching between compiler levels.
>>> >> Download the latest dev build and you can specify the compiler level
>>> >> on the command line.  Eg-
>>> >>
>>> >> eclipse -vmargs -Dgroovy.compiler.level=17
>>> >> or
>>> >> eclipse -vmargs -Dgroovy.compiler.level=18
>>> >>
>>> >> You can also specify this option in the eclipse.ini file.  It should
>>> >> be possible to open two instances of Eclipse at the same time using
>>> >> different compiler levels (but they must use different workspaces).
>>> >>
>>> >> I have tried this out on my machine, but this kind of command line
>>> >> mucking around with the OSGi runtime is finicky and so I would like to
>>> >> hear from some users if they have any problems.  Thanks and please let
>>> >> me know if you try it.
>>> >>
>>> >> Andrew
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe from this list, please visit:
>>> >>
>>> >>    http://xircles.codehaus.org/manage_email
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Experimental: Easier compiler level switching in Groovy-Eclipse

Matthew Passell
Hi Andrew,

I tried launching MyEclipse from the command line with the following:
C:\eclipse\MyEclipse 9>myeclipse.exe -vmargs -Dgroovy.compiler.level=17

After selecting the workspace, my machine worked hard for a while and eventually said an error had occurred.  I looked at the referenced .log file and saw that it was warning about running out of PermGen space.  Given that I normally run with a max perm size of 384m (as specified in my myeclipse.ini), that leads me to believe that specifying the -vmargs at the command line is bashing the vmargs settings in my .ini file.  I'll try adding the compiler level to the .ini file and see if it works.  If it does, I'll get in touch with the MyEclipse people and try to find out if there's a way I can append new settings from the command line rather than overriding the ones in the .ini file.

Thanks,
Matt


On Thu, Jul 28, 2011 at 2:12 PM, Andrew Eisenberg <[hidden email]> wrote:
OK Matt,

Thanks for the configuration files.  As we talked about, it looks like
MyEclipse may be causing some strange things to happen.  I was able to
install MyEclipse and get it to respect the groovy.compiler.level
property by editing the myeclipse.ini file.  This appears to work for
me.  However, since it is associated directly with the executable, you
would need two installations to have this work properly.  Instead, you
would need to launch from the command line and include the
groovy.compiler.level on the command line.

However, I'm finding it a bit cryptic to launch MyEclipse from the
command line.  Perhaps you have more familiarity with this and would
know how.

I'm on mac.  This shouldn't make a difference, but you never know with
these kinds of things.

--a

On Wed, Jul 27, 2011 at 10:14 PM, Andrew Eisenberg <[hidden email]> wrote:
> I just tried it again on 3.6 and didn't have any troubles with the switching.
>
> What exactly is the command line that you used?  Also, can you send
> over your configuration details?
>
> Eclipse -> About Eclipse -> installation details -> Configuration ->
> Copy to clipboard.
>
> Hopefully, we can figure out what is going on.
>
> On Wed, Jul 27, 2011 at 1:45 PM, Matt Passell
> <[hidden email]> wrote:
>> OK, no big deal.  I can live with that restriction.  However, when I tried
>> launching with the 1.7 compiler, I got a stacktrace including the following:
>> java.lang.IllegalArgumentException: Specified version of Groovy not found.
>> Available versions are: null
>> at
>> org.codehaus.groovy.frameworkadapter.CompilerHook.checkVersionFound(CompilerHook.java:155)
>> at
>> org.codehaus.groovy.frameworkadapter.CompilerHook.frameworkStart(CompilerHook.java:134)
>> at
>> org.eclipse.osgi.baseadaptor.BaseAdaptor.frameworkStart(BaseAdaptor.java:242)
>> I'm using the latest Groovy Eclipse dev snapshot in Eclipse 3.6.  Is this
>> only working in the version for 3.7?
>> Thanks,
>> Matt
>>
>>
>> On Wed, Jul 27, 2011 at 2:47 PM, Andrew Eisenberg <[hidden email]>
>> wrote:
>>>
>>> Unfortunately, no.  The reason is that the choice between using the
>>> 1.7 or 1.8 compiler needs to be made very early on, before most other
>>> plugins have been started.  By the time the plugins that allow access
>>> to the workspace settings have been started the groovy compiler level
>>> has already been chosen.
>>>
>>> The best that I can do is just to have 2 different startup commands,
>>> one for each workspace.  Also, note that you can hard-code the
>>> workspace to use by running with the '-data <workspace_loc'> option
>>> set.
>>>
>>> On Wed, Jul 27, 2011 at 10:04 AM, Matt Passell
>>> <[hidden email]> wrote:
>>> > Hi Andrew,
>>> > Would there be a way to tie such a setting to a workspace rather than to
>>> > the
>>> > Eclipse startup settings?  I have separate workspaces for two different
>>> > versions of a project, one using Groovy 1.7.x and the other Groovy
>>> > 1.8.x.
>>> >  It would be great if I could continue to launch the same Eclipse
>>> > installation, but use the appropriate Groovy version for the selected
>>> > workspace.
>>> > Thanks,
>>> > Matt
>>> >
>>> >
>>> > On Tue, Jul 19, 2011 at 5:39 PM, Andrew Eisenberg <[hidden email]>
>>> > wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >> I would like to get some feedback on an experimental new feature in
>>> >> Groovy-Eclipse that allows easier switching between compiler levels.
>>> >> Download the latest dev build and you can specify the compiler level
>>> >> on the command line.  Eg-
>>> >>
>>> >> eclipse -vmargs -Dgroovy.compiler.level=17
>>> >> or
>>> >> eclipse -vmargs -Dgroovy.compiler.level=18
>>> >>
>>> >> You can also specify this option in the eclipse.ini file.  It should
>>> >> be possible to open two instances of Eclipse at the same time using
>>> >> different compiler levels (but they must use different workspaces).
>>> >>
>>> >> I have tried this out on my machine, but this kind of command line
>>> >> mucking around with the OSGi runtime is finicky and so I would like to
>>> >> hear from some users if they have any problems.  Thanks and please let
>>> >> me know if you try it.
>>> >>
>>> >> Andrew
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe from this list, please visit:
>>> >>
>>> >>    http://xircles.codehaus.org/manage_email
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email