groovy

Instantiation exception in Groovysh when creating an enum type

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 1.1-rc-1
  • Fix Version/s: 1.1-rc-2
  • Component/s: Groovysh
  • Labels:
    None
  • Environment:
    JVM 1.6.0, Windows Vista
  • Number of attachments :
    0

Description

When I try to create an enum in Groovysh an exception occurs. Apparently, the enum type is being properly created, but groovysh uselessly tries to instantiate it.

Session transcript:

Groovy Shell (1.1-rc-1, JVM: 1.6.0-b105)
Type 'help' or '\h' for help.
------------------------------------------------------
groovy:000> enum E {A,B,C}
ERROR java.lang.InstantiationException: E
groovy:000> println E.A
A
===> null

BTW you get a similar problem when defining a class with a private default constructor that also cannot be instantiated:

groovy:000> class K { private K(){} }
ERROR java.lang.IllegalAccessException: Class org.codehaus.groovy.runtime.InvokerHelper can not access a member of class K with modifiers "private"

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jason Dillon added a comment -

I'm not really sure what the proper fix for this puppy is.... but I have found that if we insert an expression into the bufferer when evaluating (after imports, before user code) that things seem to be much happier.

Show
Jason Dillon added a comment - I'm not really sure what the proper fix for this puppy is.... but I have found that if we insert an expression into the bufferer when evaluating (after imports, before user code) that things seem to be much happier.
Hide
Permalink
Jason Dillon added a comment -

This may be fixed now in trunk. I was not really sure what the best solution was... and the wee hack I added might actually cause other strangeness... I'm not sure. Seems to be harmless so far. Basically, I just added a dummy true statement to the evaluated buffer after imports and before the user's code when evaluating (when parsing to detect a complete buffer this isn't used).

So, for example if you entered:

groovy:000> enum E {A,B,C}

Internally, it will parse out:

enum E {A,B,C}

and then since this is complete it will evaluate:

true
enum E {A,B,C}

And if imports were added, then a enum, like:

groovy:000> import java.*
groovy:000> enum E {A,B,C}

It will parse out:

import java.*
enum E {A,B,C}

And then it will evaluate:

import java.*
true
enum E {A,B,C}
Show
Jason Dillon added a comment - This may be fixed now in trunk. I was not really sure what the best solution was... and the wee hack I added might actually cause other strangeness... I'm not sure. Seems to be harmless so far. Basically, I just added a dummy true statement to the evaluated buffer after imports and before the user's code when evaluating (when parsing to detect a complete buffer this isn't used). So, for example if you entered: 
groovy:000> enum E {A,B,C}
Internally, it will parse out: 
enum E {A,B,C}
and then since this is complete it will evaluate: 
true
enum E {A,B,C}
And if imports were added, then a enum, like: 
groovy:000> import java.*
groovy:000> enum E {A,B,C}
It will parse out: 
import java.*
enum E {A,B,C}
And then it will evaluate: 
import java.*
true
enum E {A,B,C}

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.