STS support for verifying method signatures

[tnabil]

Hi,

I just spent quite some time trying to figure out why some method on an injected service was not working. The error was clearly stating that the method signature did not exist, but since I was not aware that I had misspelled the method name, I was focused on finding out if the parameter data types were correct.

I believe if STS was able to provide autocomplete for such variables, that would have helped. Will this ever be possible or is it impossible to provide such functionality with such a dynamic language?

I had defined the service to be injected using

def springSecurityService

I changed that to

SpringSecurityService springSecurityService

And now STS can provide autocomplete. But I'm not sure if that is the right approach since the implementation class name of such a service could change from version to version.

But even with that approach, if I mis-spell the method name, STS will not give me a complication error.

I think the fact that there are no javadocs for plugin classes also adds to this problem.

Regards,
Tarek

[pledbrook]

I changed that to

SpringSecurityService springSecurityService

And now STS can provide autocomplete. But I'm not sure if that is the right approach since the implementation class name of such a service could change from version to version.

The class is unlikely to change unless there is another new major version released. It's perfectly sensible to use static types, particularly when you're starting out and aren't familiar with the classes and their methods.

But even with that approach, if I mis-spell the method name, STS will not give me a complication error.

I think the fact that there are no javadocs for plugin classes also adds to this problem.

There will be no compilation error, but STS will mark the method with an underline to tell you that it doesn't know about it. Also, API documentation is generated for the plugins, but it is not yet published. That's something we need to fix.

Hopt that helps,

Peter

[tnabil]

Thanks, Peter. It does underline the unknown methods once I use the static type. That should be helpful.

I think the reason I'm wary about using the static type is that it's actually an implementation class; not an interface. Being used to separating interfaces from their implementation classes, I miss this approach in Grails. Is it because Groovy is a dyanmic language it does not require this separation?

I'm not really experienced with dynamic languages so maybe that concept is not clear to me.

[pledbrook]

Interfaces are typically used less in dynamic languages, particularly when you use untyped variables. Since methods are resolved at runtime, you can replace one object with another and as long as the method exists, the method call will succeed.

There isn't anything stopping you from using interfaces and some features such as remoting only work with interfaces. You could always raise an issue with the Spring Security plugin to have the service implement an interface.