groovy

Accessors for boolean properties are not generated properly

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.5.6
  • Fix Version/s: 1.6.6, 1.7-rc-1
  • Component/s: class generator
  • Labels:
    None
  • Environment:
    Suse/Vista, Java6, Eclipse
  • Number of attachments :
    0

Description

see original post here: http://www.nabble.com/POGO-properties-redefined-in-G1.0.3-tt17751775.html

In a class like:

import org.springframework.security.userdetails.UserDetails

class UserAccount implements UserDetails {

String username

String password

boolean accountNonExpired = true

boolean accountNonLocked = true

boolean credentialsNonExpired = true

/* other stuff */

}

I'm getting a compile error:

.grails\1.0.3\projects\wextent\generated-java-source\UserAccount.java:10: UserAccount is not abstract and does not override abstract method isCredentialsNonExpired() in org.springframework.security.userdetails.UserDetails
public class UserAccount

I assume that instead of isCredentialsNonExpired() for the property credentialsNonExpired the getCredentialsNonExpired() is generated.

As a hacky work-around I replaced the groovy-all-1.5.6.jar with the groovy-all-1.5.4.jar, but the issue shall be fixed officially, so that the improvements in groovy 1.5.6 are accessible in Grails 1.0.3

Issue Links

This issue depends upon:
GROOVY-2696 Joint compiler does not honour JavaBean spec for boolean properties Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

The way boolean getters are generated has changed in between 1.5.4 and 1.5.6. In 1.5.4 they were generated with "is" like isCredentialsNonExpired() now they are generated as "get" like getCredentialsNonExpired(). This is a breaking change.

As I mentioned before we should be generating both a "is" and a "get" if they don't already exist

Show
Graeme Rocher added a comment - The way boolean getters are generated has changed in between 1.5.4 and 1.5.6. In 1.5.4 they were generated with "is" like isCredentialsNonExpired() now they are generated as "get" like getCredentialsNonExpired(). This is a breaking change. As I mentioned before we should be generating both a "is" and a "get" if they don't already exist
Hide
Permalink
Peter Ledbrook added a comment -

Also, if you try to add the "is...()" methods manually you get compilation errors like this:

grails-1.1-dev/ant/build/compile.xml:24: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, /home/pal20/dev/tools/grails-1.1-dev/src/web/org/codehaus/groovy/grails/web/pages/ext/jsp/JspTagImpl.groovy: 167: Repetitive method name/signature for method 'boolean isBodyTag()' in class 'org.codehaus.groovy.grails.web.pages.ext.jsp.JspTagImpl'.
 @ line 167, column 5.
       public boolean isBodyTag() {
Show
Peter Ledbrook added a comment - Also, if you try to add the "is...()" methods manually you get compilation errors like this: 
grails-1.1-dev/ant/build/compile.xml:24: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed, /home/pal20/dev/tools/grails-1.1-dev/src/web/org/codehaus/groovy/grails/web/pages/ext/jsp/JspTagImpl.groovy: 167: Repetitive method name/signature for method 'boolean isBodyTag()' in class 'org.codehaus.groovy.grails.web.pages.ext.jsp.JspTagImpl'.
 @ line 167, column 5.
       public boolean isBodyTag() {
Hide
Permalink
Michael Cameron added a comment -

The automatic "is" accessors for booleans appear to be generated both by the groovyc compiler and Ant task. They get compiled in the binaries, but they are not visible from java code during joint compiliation.

For instance:

Class1.groovy
class Class1
{
boolean activeMonday
}

Class2.java:
public class BaseClass
{
public boolean method()

{ Class1 c = new Class1(); return c.isActiveMonday(); }

}

However, if class2 is a groovy class then it compiles without failure. Also, as peter noted above if you explicitly add the is...() method then while there will be no problem during joint compilation with the java side, but the compiler will complain that the groovy class has repetitive methods.

It's as if the stub created by the joint compilation does not add the is...() methods,b ut the compiler does. If you have all groovy this is not an issue, but if you have both groovy and java sources this is an issue.

Show
Michael Cameron added a comment - The automatic "is" accessors for booleans appear to be generated both by the groovyc compiler and Ant task. They get compiled in the binaries, but they are not visible from java code during joint compiliation. For instance: Class1.groovy class Class1 { boolean activeMonday } Class2.java: public class BaseClass { public boolean method() { Class1 c = new Class1(); return c.isActiveMonday(); } } However, if class2 is a groovy class then it compiles without failure. Also, as peter noted above if you explicitly add the is...() method then while there will be no problem during joint compilation with the java side, but the compiler will complain that the groovy class has repetitive methods. It's as if the stub created by the joint compilation does not add the is...() methods,b ut the compiler does. If you have all groovy this is not an issue, but if you have both groovy and java sources this is an issue.
Hide
Permalink
Konstantyn Smirnov added a comment -

I dropped into grails install folder a groovy-all-1.5.7.jar, and the 'is' getters appear to be generated properly.
Also missing methods, like splitEachLine() appeared as well

Show
Konstantyn Smirnov added a comment - I dropped into grails install folder a groovy-all-1.5.7.jar, and the 'is' getters appear to be generated properly. Also missing methods, like splitEachLine() appeared as well
Hide
Permalink
Michael Cameron added a comment -

As I noted above, it works fine for me as well when I calling a groovy class with a boolean accessor from another groovy class, or even using a compiled groovy class file from a java class. The issue I'm running into involves joint compilation from a java class to a groovy class that exposes a boolean accessor. I added my issues and comments on this existing ticket since it seemed like the same issue. If you feel this issue is separate, I can open another ticket. The problem I presented still exists in 1.5.7 and can be tested with 2 simple files that I showed above (i.e. no need for grails).

Show
Michael Cameron added a comment - As I noted above, it works fine for me as well when I calling a groovy class with a boolean accessor from another groovy class, or even using a compiled groovy class file from a java class. The issue I'm running into involves joint compilation from a java class to a groovy class that exposes a boolean accessor. I added my issues and comments on this existing ticket since it seemed like the same issue. If you feel this issue is separate, I can open another ticket. The problem I presented still exists in 1.5.7 and can be tested with 2 simple files that I showed above (i.e. no need for grails).
Hide
Permalink
Roshan Dawrani added a comment -

This issue does not seem to be there anymore. Tried with the code below both in trunk and 1.6.x (1.6.3).

import org.springframework.security.userdetails.UserDetails
import org.springframework.security.GrantedAuthority

class UserAccount implements UserDetails { 
	String username 
	String password 
	boolean accountNonExpired = true 
	boolean accountNonLocked = true 
	boolean credentialsNonExpired = true 
	boolean enabled = true
	GrantedAuthority[] authorities
} 
println new UserAccount()
Show
Roshan Dawrani added a comment - This issue does not seem to be there anymore. Tried with the code below both in trunk and 1.6.x (1.6.3). 
import org.springframework.security.userdetails.UserDetails
import org.springframework.security.GrantedAuthority

class UserAccount implements UserDetails { 
	String username 
	String password 
	boolean accountNonExpired = true 
	boolean accountNonLocked = true 
	boolean credentialsNonExpired = true 
	boolean enabled = true
	GrantedAuthority[] authorities
} 
println new UserAccount()
Hide
Permalink
blackdrag blackdrag added a comment -

issued had been fixed already

Show
blackdrag blackdrag added a comment - issued had been fixed already

People

Vote (5)
Watch (6)

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.