groovy

Stub compilation cannot handle spaces in method names

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.6.4
  • Fix Version/s: 1.6.5, 1.7-beta-2
  • Component/s: Compiler
  • Labels:
    None
  • Number of attachments :
    0

Description

SomeGroovyClass.groovy:

class SomeGroovyClass {
  SomeJavaClass java = new SomeJavaClass()

  def " some spaces in a method name"() {}
}

SomeJavaClass.java:

public class SomeJavaClass {
  SomeGroovyClass groovy = new SomeGroovyClass();
}

Joint compilation produces:

SomeGroovyClass.java:16: ';' expected
public  java.lang.Object  some spaces in a method name() { return null;}

GMaven stub compilation has the same problem. IDEA stub compilation handles this fine.

On a related note, I'm wondering why stub compilation generates code for private members. Seems like lots of work for nothing to me (e.g. all the internal Groovy stuff). Or is it on purpose, maybe to get an error of the kind "this member is private" when trying to access such a member from Java?

Activity

Ascending order - Click to sort in descending order
Peter Niederwieser made changes -
Field Original Value New Value
Summary Stub compilation cannot handle special characters in method names Stub compilation cannot handle spaces in method names
Peter Niederwieser made changes -
Assignee Peter Niederwieser [ pniederw ]
Hide
Permalink
Peter Niederwieser added a comment -

I would like to make the following changes:

  • Do not generate stub methods for private methods (wasted effort, especially for all the Groovy internal methods)
  • Do not generate stub method if method name contains spaces

Comments?

Show
Peter Niederwieser added a comment - I would like to make the following changes: Do not generate stub methods for private methods (wasted effort, especially for all the Groovy internal methods) Do not generate stub method if method name contains spaces Comments?
Hide
Permalink
blackdrag blackdrag added a comment -

For private methods I agree. For the other one... we should probably not generate the method stub if the name is not valid in Java. That is unless we define a way to transcribe that.

Show
blackdrag blackdrag added a comment - For private methods I agree. For the other one... we should probably not generate the method stub if the name is not valid in Java. That is unless we define a way to transcribe that.
Hide
Permalink
Peter Niederwieser added a comment -

As of rev. 17572, stubs no longer contain private methods and methods whose name is invalid in Java.

Show
Peter Niederwieser added a comment - As of rev. 17572, stubs no longer contain private methods and methods whose name is invalid in Java.
Peter Niederwieser made changes -
Fix Version/s 1.7-beta-2 [ 15540 ]
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s 1.6.5 [ 15539 ]
Resolution Fixed [ 1 ]
Paul King made changes -
Status Resolved [ 5 ] Closed [ 6 ]
Hide
Permalink
Ali Yang added a comment -

When I use GMaven, groupId is "org.codehaus.gmaven", artifactId is "gmaven-plugin", version is "1.3", stub compilation still cannot handle spaces in method names.

Show
Ali Yang added a comment - When I use GMaven, groupId is "org.codehaus.gmaven", artifactId is "gmaven-plugin", version is "1.3", stub compilation still cannot handle spaces in method names.
Hide
Permalink
Paul King added a comment -

The current expected behavior is that such methods are dropped from the class as Java wouldn't allow them anyway - is that what you are seeing? If not I suggest you open a new bug Jira with your error and stacktrace.
Alternatively, if you have a scenario where the current policy doesn't work for you, then perhaps an enhancement request Jira could be added - though we would need to put together a proposed strategy for transcribing/mangling the name so that it was valid Java.

Show
Paul King added a comment - The current expected behavior is that such methods are dropped from the class as Java wouldn't allow them anyway - is that what you are seeing? If not I suggest you open a new bug Jira with your error and stacktrace. Alternatively, if you have a scenario where the current policy doesn't work for you, then perhaps an enhancement request Jira could be added - though we would need to put together a proposed strategy for transcribing/mangling the name so that it was valid Java.

People

  • Assignee:
    Peter Niederwieser
    Reporter:
    Peter Niederwieser
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: