Follow up on Griffon/Groovy/Scala - No Fluff Just Stuff

Follow up on Griffon/Groovy/Scala

Posted by: Andres Almiray on February 3, 2009

This is a follow up on the previous post Griffon: Groovy & Scala working together. The first news is that the griffon-scala plugin has been released, it can be tested out with the sample application available at github: scalaSample :-D

Remember that the plugin will compile all your Scala sources first, which means you will not be able to reference Groovy classes (nor code placed on src/main) from your Scala code.

Back to the implementation details, Daniel points out that while Structural Types will solve the problem they carry a performance penalty, and that Traits would be a better solution. Traits can be seen as Java interfaces (though they actually do more than that) which back in Javaland are used to convey a contract, exactly what is needed in this case. Armed with that knowledge I happily added an Output trait into its own file, changed Greeter.greet()'s signature to take an instance of Output as parameter instead of the structural type, finally made the Model implement Output. I would be happy to say all this worked, sadly it didn't, perhaps I miss-configured something but the Scala compiler complained that setOutput was not a value on Output while the trait stayed on its own file, moving the trait definition to Greeter.scala solved that problem. The next one was the usage of the @BeanProperty annotation, when the Scala compiler sees that annotation it will generate the all-so-popular get/set pair for that particular bean property, unfortunately for Groovy, the compiler still generates the Scala required accessors (output_$eq() & output()) as it can be seen by decompiling the generated interface

This means implementing Output from the Groovy side would require providing an implementation for two more methods, ugh. Next tried changing Output to an abstract class as an alternative, and while the app compiled fine and ran it didn't pop up the dialog, meaning the event was getting lost somehow in the pipework :-( So if you peruse the git repo you will still see the usage of structural types.

It occurred to me while writing this post that perhaps dropping to the common layer, Java the language, would also help. Scala has a joint compiler option similar to Groovy's, this means you could compile a version of Output as a Java interface along with the Scala code, then have the Groovy Model implement said interface.
Andres Almiray

About Andres Almiray

Andres is a Java/Groovy developer and a Java Champion with more than 20 years of experience in software design and development. He has been involved in web and desktop application development since the early days of Java. Andres is a true believer in open source and has participated on popular projects like Groovy, Griffon, and DbUnit, as well as starting his own projects (Json-lib, EZMorph, GraphicsBuilder, JideBuilder). Founding member of the Griffon framework and Hackergarten community event. https://ch.linkedin.com/in/aalmiray

Why Attend the NFJS Tour?

  • » Cutting-Edge Technologies
  • » Agile Practices
  • » Peer Exchange

Current Topics:

  • Languages on the JVM: Scala, Groovy, Clojure
  • Enterprise Java
  • Core Java, Java 8
  • Agility
  • Testing: Geb, Spock, Easyb
  • REST
  • NoSQL: MongoDB, Cassandra
  • Hadoop
  • Spring 4
  • Cloud
  • Automation Tools: Gradle, Git, Jenkins, Sonar
  • HTML5, CSS3, AngularJS, jQuery, Usability
  • Mobile Apps - iPhone and Android
  • More...
Learn More »