Spring Boot with Groovy config

While working on converting a Grails application to a SpringBoot based application, I was trying to understand how the auto configurations and custom configurations work under the hood. Just like CoC of Groovy/Grails, there seems to be a lot of hide-and-seek going on under the Spring boot hood. Admittedly its been a while for me with good ol’ raw Spring, so the many different ways of skinning the configuration felt a bit overwhelming. I counted several concepts around configurations – application.properties, application.yaml, PropertySource, PropertyPlaceHolder, @Value, @EnableConfiguration, @EnableConfigurationProperties, @EnableAutoConfiguration, @Configuration, @ConfigurationProperties, pre-defined property name prefixes, creating classes specifically for holding configuration values – so much information just for accessing key-value pairs? Compare to Grails – one Config.groovy (or multiple externalized) and a simple grailsApplication injection takes care of making configuration available anywhere. When I read Spring Boot support for Groovy, I somehow assumed that support for a groovy config is automatically enabled.

My Grails application already had a groovy config, and I was not in a mood to convert them to .properties or .yaml. Groovy configs are DSLs in essence – it provides many advantages over the traditional properties file: key=value (like .properties), a structured format like .yaml – sans the indent-erasure-phobia, type-enriched config values like list/map etc, functions via closures and more.

So, here is a very simple way to expose the groovy config to your Spring Boot apps:

Create a Config.groovy in the same folder as the ConfigProperties class.

/** Config.groovy **/

//simple key-value
spring.boot.guide = 'https://github.com/spring-guides?page=1'
//formatted structure
google {
searchurl = 'http://www.google.com'
apiKey = '1234'
}

/** ConfigProperties.groovy **/

import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration

@Configuration
class ConfigProperties {

@Bean(name="configObject")
ConfigObject configObject() {
return new ConfigSlurper().parse(Config)
}

}
/** HelloController.groovy **/

import ConfigProperties
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.web.bind.annotation.RequestMapping
import org.springframework.web.bind.annotation.RestController

@RestController
class HelloController {
@Autowired
ConfigObject configObject

@RequestMapping("/")
String home() {
return "Hello World! " + configObject.spring.boot.guide
}

}

/** Application.groovy **/

@EnableAutoConfiguration
@ComponentScan
class Application {
static void main(String[] args) {
Object[] sources = [Application.class, ConfigProperties.class]
SpringApplication.run(sources, args)
}
}

Note: @Bean returns must be typed. Habitually, I wrote def configObject() { return new ConfigSlurper().parse(Config) } and the @Autowired did not wire it up.

The lite at the end of webservice tunnels

In the last post, I alluded to how shifting complexity from one area to another can actually improve perceived simplicity. Here is a concrete example of how we got rid of scores of wsdl-client generated jaxb classes and brought in a fresh wave of simplicity to our Grails applications.

Problem

One or more of our Grails application uses several our own plugins and each of them talk to several web services that share a lot of xsd schemas, the java client generation of which end up proliferating duplicated jaxb classes in each of our plugins and also in the applications which use them, thus resulting in multiple classpath conflicts.

Also we dont like the date conversions from Date to Calendar to GregorianCalendar to XmlGregorianCalendar or other conversions from Byte to Int to Shorts. Also jaxb does some non-intuitive magic with some of the xsd:any types in the schemas. If xsd schemas want strict type checking, fine. We from the “def” world, just look everything as plain data. And finally the jaxb classes look ugly.

Solution

With a combination of groovy-wslite, grails wslite plugin and MarkupBuilder and Config, the code become pretty straight-forward, almost.

From the grails command prompt, run install-plugin wslite

def grailsApplication

public def amazonBookListMania() {
  WsliteConnector.instance.withSoap(serviceURL: grailsApplication.config.amazonBookListManiaServiceUrl) {
    def soapResponse = send(SOAPAction: grailsApplication.config.amazonBookListManiaSoapAction) {
      //Get the namespaces, which is a simple Groovy map
      //['xmlns:amz':'http://www.amazon.com/ListMania']
      envelopeAttributes grailsApplication.config.amazonBookListManiaNamespaces
      body {
        //Get the raw xml and slap it into soap body
        mkp.yieldUnescaped(createXmlRequest())
      }
    }
    //Wslite automatically xmlslurps the result and gives you the closure
    def response = soapResponse.body.bookListManiaResponseRoot
    println response.Items.count()
  }
}

The “withSoap” is a DSL, that is supposed to be injected automatically into controllers, but on other classes it didnt seem to work. I tried using WsliteEnhancer, but that didnt help either. So the direct call to withSoap using WsliteConnector singleton.

The example shows all params injected from grailsApplication config, to allow webservice urls for different environments.

The interesting aspect is the envelopeAttributes, which is a map of namespaces. Since we are not using generated client classes, whcih does the work for us, the namespace prefixes must be specified somehow in the xml itself as part of soap request. Adding namespaces to envelopeAttributes will append the namespaces to the soap-env tag. No need to include the namespace for soap-env itself. The wslite plugin does that.

public String createXmlRequest() {
    def writer = new StringWriter()
    def builder = new MarkupBuilder(writer)
    builder.'amz:ListMania' {
      //tag attributes
      'amz:credentials'(username: 'vasya10', password: 'yeahright')
      //tag value
      'amz:dateRequested'(new SimpleDateFormat('yyyy/MM/dd').format(new Date()))
    }
    //Returns <amz:ListMania><amz:credentials username='vasya10' password='yeahright'></amz:credentials><amz:dateRequested>2013/01/01</amz:dateRequested></amz:ListMania>
    return writer.toString()
}

With the complexity of creating the xml shifted into MarkupBuilder, creating soap requests become trivial, even more so with the withSoap DSL.

Wsdl import generated classes
Pros
No need to worry about namespaces
Set and Get of values use Java-like syntax
Setting values does not matter as xml marshalling happens at a later time than setting the values
Setting tag attribute or tag value is no different (ie code doesn’t care)

Cons
Every minor change in wsdl forces wsdl client generation
Duplicated client generated classes could cause classpath conflicts
The hierarchy of the xml elements is not apparent in the code, the only way to know the hierarchy is to look at the xml samples

WSLite + MarkupBuilder
Pros
No confusion about which client to use: there are scores of them and each have some unique issue (jax-ws, jax-b, cxf and so on)
No wsdl import client generated sources and jars
No crazy xerces, xalan and other marshalling runtime errors, especially if deploying to different app servers (tomcat, weblogic etc)
If there are trivial changes to elements (saying adding a new optional element), will still work without changing client code (if that element is not used)
Creation of xml is very straight-forward
Code documents the hierarchy of the xml!
Response returns XmlSlurped data, so dot-notation can directly be applied on the objects

Cons
Code must be namespace-prefix aware
Must know tag attributes and tag values to create the xml correctly (this must be a Pro)
Code must generate xml in the same sequence of elements; blocks of elements can still be called out-of-order, but the final xml body must be created in a sequence
Unvalidated namespace prefixes increases testing time
Extra testing time for un-type-checked variables

Compared to our previous jaxb code (with ObjectFactory, creation of new Objects etc.), the code is now 40% smaller, and additionally got rid of the client sources too.

The motorcycle diaries of webservices

Software is a big grandpa pendulum clock. It oscillates between simplicity and complexity perpetually. Ideas and concepts that start off simple, rapidly become complex and eventually complex ideas are broken down into simple components and again these simple components evolve into complex creatures of their own. After all we evolved from a single cell into complex cell living beings, why blame the software for that?

Webservices necessitated from complex interaction between disparate systems (remember CORBA, JNI, DCOM, RPC, mainframe apis?). All those were dissolved into ‘simple’ wsdl based services, as long as client and server maintain the contract, everything was promised to be a simple hookup.

But it didnt end there. Generating wsdl clients either in Java or .NET were complex in its own terms. Java discovered its way, as usual, with hundreds of wsdl clients and xml jars (anyone still using xerces, xalan, sax4j directly?) – jaxb, jax-rs, jws, cxf and several more proprietary ones). .Net, was not a A-shot either: first asmx, then wcf and then several flavors of .net versions on top of that. Most of the time, its not a one-step process to call a WCF wsdl from a Java based client, there are always some surprises around the corner in terms of configurations. Its heartening to see nobody got it right the first time.

If you think about it, what was the necessity to generate classes from wsdl in order to send plain xml text data? The early xml apis described the xml in terms of hardcore hierarchy: root, nodes, parent, children, siblings, single. It could have been easily extended to represent a oh-so loveable joint-family: cousins, uncles, aunts, nephews and nieces:

public getAuntyNode() {
return currentNode.getParent().getFather().getSister().toNode();
}

public getDistantUncleNode() {
return currentNode.getParentNode().getMother().getSisterInLaw().getHusband().getSibling().toNode()
}

public getImMyOwnGrandpaNode() {
//Outsourced
}

Such family friendly APIs would have thrilled developers who often work only after the family goes to sleep.

I am also starting to see that xml and xsd schemas are not an ideal way to describe data models. Describing a model in xsd using the semantics of xml itself is over complicated. On top of that extensions, simpleTypes, complexType – are way too tedious and garrulous. If you are exposed to C++/Ruby/Groovy world, you can visualize the models pretty quickly in terms of encapsulations, compositions and interfaces. In the xml world, I only see tags and attribute names. Lots and lots of them. The content is lost in the tag-tsunami.

While reviewing a project recently, where all our models are xsd based, data models extending from base xsds, and several simple, complex and xsd:any types, pretty soon I found them going above my head. Im not even thinking how xsds maintain versions of models and references.

Coming to actually using them in our Grails project, a colleague of mine tried to generate the client classes using jaxb (before trying a few other clients) and pretty soon found himself in a maze of conflicting classpaths from different generated wsdls. Jaxb generates classes for all the dependent xsds (obviously) and generating them for different wsdls (in the same project) ended up with several classpath issues.

Taking a break, we decided to ask a fundamental question: “Why do we have to worry about all the xml types in the Grails code, if all we need is to send a plain textual xml data?”.

Who cares what the model hierarchy of xsd is? Most of the time that model is useless to the Grails code, where typically the representation of model is different from the xsd models. All those xsd generated classes, objects, factories, abstract factories were required because the complex familial Java APIs were the only way to process xml (unless using StringBuffer and appending data manually).

Enter Groovy’s MarkupBuilder, it is much easier to build an xml than generating the client. So if we all care is to send data and generating that data itself is easier than generating clients, why bother at all with the later. And we switched to Grails wslite plugin, with which we are directly creating soap requests and sending it to server.

So thats how the pendulum switched back to its other position, back to creating hand made soaps. Eventually this may get complex too. But again, the important thing to remember is that the original complexity is not the same level of complexity of the broken down components. The “absolute complexity” remains unaltered and the “perceived complexity” depends on how lazy or smart we are.

Xml Subtractor

A few weeks ago, had to work with two xmls where the first xml was a superset of the second xml and had to figure out only the xml nodes in first xml that were not in the second xml.

Mathematically expressed,

Given, xml2 Ε xml1
Find: xml1 – xml2

I had written a small program to do that and forgotten about it. Well today faced the same issue but with two substantially large xmls. Glad had the program earlier and it helped save a ton of time.

Groovy makes xml processing very simple and perhaps create an “xml arithmetic library”, using Groovy Categories et al, for what its worth.

void xmlMinus() {
String xmlText1 = new File("filename1.xml").text
String xmlText2 = new File("filename2.xml").text

def xml1 = new XmlParser().parseText(xml1)
def xml2 = new XmlParser().parseText(xml2)

xml2.each {
def uniqueId = it.'@uniqueId'
println "finding $uniqueId
def node = xml1.find { it.'@uniqueId' == uniqueId }
xml1.children().remove(node)
}

java.io.PrintWriter fw = new java.io.PrintWriter(new FileWriter("xml1-minus-xml2.xml"))
XmlNodePrinter xnp = new XmlNodePrinter(fw)
xnp.preserveWhitespace = true
xnp.print(xml1)
fw.close()
}

Example:

File List: filename1.xml

<Item uniqueId="1">
  <Details />
</Item>
<Item uniqueId="2">
  <Details />
</Item>
<Item uniqueId="3">
  <Details />
</Item>
<Item uniqueId="4">
  <Details />
</Item>

File Listing: filename2.xml

<Item uniqueId="3">
  <Details />
</Item>
<Item uniqueId="1">
  <Details />
</Item>

File Listing: xml1-minus-xml2.xml

<Item uniqueId="2">
  <Details />
</Item>
<Item uniqueId="4">
  <Details />
</Item>

The peekaboo column type

Alright, I will have to admit that the misuse of xml is irritating me quite a bit. Xml is reaching a critical desalination point (sorry Quaid) and is set to freeze the world over. I sincerely hope that xml abuse will be the cause of next Internet meltdown. Disproportionate amount of control information thrown along with a tiny amount of data is going to upset someone over the wire, causing a data-strife and leading to abrupt strike by tcp services.

That was pretty much my dream when I struggled over what I thought was a simple solution to a really simple problem. I was working on a data-migration project, you know, the routine thingy, read data from a legacy database, convert to xml and stuff down the throat of another database. I picked up Grails to get it done, uh well, with a premise that I do not have to handwrite a single query and can simply map tables to domains and magically invoke “save()”.

I was short-circuiting Grails by using it only for GORM features, but running as a grails script, and not for any ui, scaffolding and many of it’s “traditional” strenghts.

1. GORM hates tables with no keys

The legacy tables I dealt with did not have any PKs at all. And GORM does not like them because of required implicit id. Yes composite keys work fine, but the legacy tables did not have any unique rows either. So the solution the was to simply create a view on the table:

select rownum as uniquekey, t.* from table t

I could care a damn for what the rownum was, as long as it was unique. I mapped the GORM id to the uniquekey and all was okay.

2. Grails Spring Context in a script environment

Grails does an amazing job of injecting Spring beans whereever you expect to. All’s well when running as a web app, but I was running this as a grails script, so the Spring services were not getting injected.

MyScript.groovy

void eatPrayAndStuff() {
MyService service = new MyService()
service.eatFromLegacyDb()
service.prayConvertToXml()
service.stuffXmlDownTheThroatOfNewDatabase()
}

class MyService {

void eatFromLegacyDb()
def query = sessionFactory.currentSession().createSQLQuery(sql)
}
}

The script is run as following:

# grails –stacktrace dev run-script MyScript.groovy

Obviously, the service object was not null, but I was promptly getting null on currentSession. I understood Spring cannot inject its singleton service into the script, but I just didn’t know how.

Thanks to a quick response in stackoverflow:

MyService service = ctx.MyService

instead of new MyService(). That’s one of the great strenghts of grails, the spring context is available throughout the script environment (not just Web and Unit Test) and its easy to experiment with. It just takes a bit of hunting, and asking for help.

3. XMLType – The Clown Prince of Column types

I ran the script and it ran well about a 1000 records and I almost declared success. Almost. And then came the bouncer.

Colleges and Universities teach a lot about how to do programming. Sadly there are no professors who take a class on “How to write BAD code”. And set a test on some really professional-industry-level bad code. The experience gained from doing wrong things is hardly equivalent to making the right choices. Yeah, you know what Edison said.

Oracle’s SQL Errors (and JDBC Sql Exceptions) will always be dear to my heart in realizing how to write bad code. So I got the error:

ORA-01461: can bind a LONG value only for insert into a LONG column

I had a few long values in my domain, so I scratched off one by one, like a senile lottery ticket buyer, and after some debugging found that all numbers are good (Damn lottery pun!). By process of elimination I realized it was the XMLType column that wasn’t behaving. The reason was the size of the xml data was 4100 bytes in length. And Oracle’s XMLType is an “XMLType” if its data size < 4kb, but if its above 4kb its a CLOB. Good deal! A dynamically self-morphing peekaboo data column type, FWIW.

Someone suggested to use a stored procedure instead of domain mapping, so I cajoled my co-worker to quickly write a wrapper storedproc for me. Try what ever I could not get past the next error:

ORA-06553: PLS-306: wrong number or types of arguments in call.

When things go wrong, switch to basics, so they say. So I went back to basics of counting numbers by my fingers, nails and toes: all arguments are correct, all types are correct. Yet Oracle thinks I pass wrong arguments.

I abandoned the stored procedure route and turned to using Oracle XDB for the XMLType. Oracle does not respect Maven community and somehow I located an xdb.jar and dropped into the grails lib directory. But STS Eclipse has issues with properly refreshing libraries. So I had to clean, close, sweep, brush the project from both STS and command line to get it included in the classpath. But surprise, xdb.jar has its own SAXParser classes which interfere with the Grails scripts.

Googling around, there was a suggestion to use xmlparserv2.jar in grails/lib. I again I hunted the jar down, but If I put it in the lib directory, grails wouldn’t even compile Then I put it in the classpath at runtime, but I simply got ClassNotFoundException.

# grails –stacktrace -cp lib/xmlparserv2.jar dev run-script MyScript.groovy

I guess the -cp option works fine if running as a run-app, but while invoke the gant scripts, the -cp is not honored (Grails 2.1.0). I realized I may have to tweak the Run-Script, but I didnt want to go that far, because the script will be run in environments I dont even know and didnt want to assume a lot.

I abandoned the XMLType route. Oracle’s half-cooked XMLType implementation and its support api isnt for someone who likes to be productive. I took a break, wondering whats the need for storing a 200 byte data – yes, thats what the actual datasize was, but ended up  as a 4100 byte xml with all kinds of tags. Thats the anguish about xml abuse and the internet meltdown that I fervently hope.

4. When in Rome, treat everybody like British

Finally I found a piece of code, which converted the XMLType into a Clob in a round-about way. Not sure why converting one data type to another needs a javax.sql.Connection parameter. This is like, if you want to pour water from one container to another container, you need to send it to a hydro-electric plant.

private CLOB getCLOB(String xmlData, OracleConnection oracleConnection) throws SQLException{
CLOB clob = null
try {
clob = CLOB.createTemporary(oracleConnection, true, CLOB.DURATION_SESSION)
clob.open(CLOB.MODE_READWRITE)
Writer clobWriter = clob.getCharacterOutputStream()
clobWriter.write(xmlData)
clobWriter.flush()
clobWriter.close()
clob.close()
} catch(SQLException sqlx){
sqlx.printStackTrace(System.out)
clob?.freeTemporary()
} catch(Exception x){
x.printStackTrace(System.out)
clob?.freeTemporary()
}
return clob
}

Only to discover that the second parameter OracleConnection is not a javax.sql.Connectin per se, and certainly not what I have in the Hibernate’s sessionFactory.currentSession().connection() which is Proxy19 – a connection proxy. So how do I get an OracleConnection from a proxy connection?

5.Droid to the Rescue

Connection connection = sessionFactory.currentSession.connection()
PreparedStatement ps = connection.prepareStatement(SQL)
C3P0NativeJdbcExtractor cp30NativeJdbcExtractor = new C3P0NativeJdbcExtractor();
OracleConnection oc = (OracleConnection) cp30NativeJdbcExtractor.getNativeConnection(ps.getConnection());
CLOB c = getCLOB(xml, oc)
ps.setObject(3, c)

And so I finally after a long self-guided tour of google, oracle, stackoverflow and several more sites that even my browser history could not remember, got the xmltype working, but not before I scratched around to fix the sql statement itself:

String SQL = /insert into table1(?,?,?) values (?,?,xmltype(?))/

And so the conspiracy was settled – Grails, Hibernate, Script, Spring, Oracle, XMLType, CLOB, Connection Proxy – all concocted together to make a nightmare of a simple insert statement.

Extensions via metaclass in Grails

Even after several releases and wrapper utilities, representation of time in Java seems to be an unconquerable mess that it originally was. At the same time, surprisingly, web services have been there for a long time now, still there is no magic wand to create webservices and clients.

Webservices is something Groovy/Grails should have made it ridiculously easy to work with, by default. When xml, json, http and so on have been outrageously simplified, the natural expectation is that the webservice call would be like:

WebServiceObject ws = new WebServiceSlurper().parse('http://someweathersite.com/weather.wsdl')
WeatherObject w = ws.getWeatherObject()
Temperature[] temperatures = w.findTemperature(zipcode: '11505', days: 5, unit: 'farenheit')

There are so many wrapper api-s, every webservice client generation is lacking in someway, making a new comer to Grails to try and find what works. axis, axis2, groovyws, xfire, cxf, jws, jaxb – there are so many acronyms and some of them are just wrappers over others, the choice may be overwhelming. Forums do provide lot of answers, but most times what works for one goose, does not work for even for its goose twin.

So after my friend pointed out the pot-holes of webservices in Grails, I started using the jws. All good until I hit the xs:date object in our wsdl, which translates to XMLGregorianCalendar. Like we all wanted a new class to represent date and time. I seriously hope Java/Groovy will deprecate and delete all its Date and Calendar classes and introduce just one class with a philosophical outlook:

/**
* Dead yesterday, unborn tomorrow, why fret about them, if today be sweet?
*/
class StarDate{
public double day;
public double increment(double unit) { day += unit }
public String toString() { return "Captain's log, stardate $day"  }
}

Conversion between a date in String to XMLGregorianCalendar goes like this:

SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy")
Date d = sdf.parse(dateString)
GregorianCalendar g = new GregorianCalendar()
g.setTime(d)
def date = DatatypeFactory.newInstance().newXMLGregorianCalendar(g)

So much for a date? I tried to generate the client classes with a custom binding to Date instead of XMLGregorianCalendar. No matter what I tried, the value inside the webservice always ended up as long format “Sun Dec 4 …”. Fed up, I changed it back to XMLGregorianCalendar and now I saw the date as 1995-03-28T06:00:00. So where did the timezone come from and how do I avoid it? Stackoverflow had an answer:

dob.setTimezone(DatatypeConstants.FIELD_UNDEFINED)

Seriously, DatatypeConstants? Minimum integer value to specify undefined? Anyway, with that undefining of the timezone, the webservice was correctly seeing the date as just 1995-03-28. But I still dont like the fact that I had to convert this in the service class or that I had to put this in an utility class.

And all this while I was developing a Grails plugin. I wanted to make the conversion as an extension to String, so that my call is like:

dateString.toXmlGregorianCalendar()

Recall that Grails plugin will load the *BootStrap.groovy when it starts up. We need to inject a metaclass method into java.lang.String so Grails runtime knows about it. (Only when run standalone, not after installing within an application).

public class MyPluginBootStrap {
def init = { servletContext ->
println "booting the plugin"
new GroovyShell(this.getClass().getClassLoader()).evaluate(new File("grails-app/conf/MetaFunctions.groovy"))
}
}

And define the MetaFunctions.groovy:

String.metaClass.toXmlGregorianCalendar = {
SimpleDateFormat sdf = new SimpleDateFormat("MM/dd/yyyy")
Date d = sdf.parse(delegate)
GregorianCalendar gcal = new GregorianCalendar()
gcal.setTime(d)
def dob = DatatypeFactory.newInstance().newXMLGregorianCalendar(gcal)
dob.setTimezone(DatatypeConstants.FIELD_UNDEFINED)
return dob
}

In .Net doing this may be simpler – just define StringExtensions. But they are static methods and cannot override existing methods. But in Groovy that is entirely possible, which makes a powerful feature, because if you don’t like the behaviour of a plugin class, just override it via metaclass using the above technique.

Groovy #7 – if there is no if

The most minimal high level programming language just needs three statements:

  1. assignment
  2. if
  3. goto

All other syntaxes can be replaced with a combination of these. As programming languages evolved, goto bore the ignominy of being the first to lose favor with the programmer-theorists. It was replaced with various sophisticated constructs like for, while, do, switch, subroutines and functions.

The next one is the ‘if’ condition. With the applications growing in complexity, the if-s also drive the cyclomatic complexity. But to some extent, OOP languages eliminate if conditions at a higher-level.

Consider a simple example:

abstract class Animal {
abstract string voice();
}

class Dog extends Animal {
string voice() { return "Bark" }
}

class Cat extends Animal {
string voice() { return "meow" }
}

Animal a = new Dog()
assert a.voice() == 'Bark'

Without the inheritance feature, a procedural language programmer would have to rely on if condition to make the above work. Obviously the if condition is still there somewhere down the line (compiler will have to determine the type of the object to know which method to invoke), but its not in the reviewed code. Yet, the above looks like an elaborate code-trap to just avoid one if condition.

By induction, can ‘if’ conditions be fully replaced by abstractions? Lets look a simple Groovy example, which uses the metaprogramming technique to do something like that.

Boolean.metaclass.methodMissing = { name, args -> println args[0].call() }

def find_nativity_by_greetings(def greetings) {
greetings in ['howdy', 'hiya'] { 'Texan!' }
greetings in ['hola', 'buenos dias'] { 'Mi amigo!' }
greetings == null { 'Yankee' }
}

find_nativity_by_greetings('howdy')
//Result
Texan!

Since if conditions evaluate to true/false and are automatically represented as Boolean in Groovy, by providing a missingMethod override implementation for the anonymous closure and calling that closure, the “if” keyword vanishes from code. The above construct is now equivalent to a if..elseif..elseif..elseif.. construct.

How is this helpful? The above constructs can actually be written in a configuration file by a business owner or it could even be in a excel spreadsheet. The core Groovy code just has to slurp the config file, evaluate and execute the statements as if there are no if-s.

Groovy OLC #3 – Perfect numbers

At a time when new JVM based languages are mushrooming as fast as frameworks were being written a few years ago, it is interesting to reflect upon a few trends. About 6th century CE, there were already several languages in India and several grammar works were being written. But there is one work outstanding in its contribution to the world of linguistics. A linguist named Bhartruhari wrote vAkyapadIya (Book of sentences and words). Instead of grammar, he pondered on the Philosophy of Languages, where he traces formation of a sentence all the way back to the abstractness of sound. This sixth century work contains some very fine abstraction thinking, which has formed the basis of much of 20th century linguistics.

An analogy can be seen with programming languages too. The underlying “language” of ‘em all is 1s and 0s, but the syntaxes and semantics vary vastly. With so many languages being created, one question to ask is the Philosophy of the Programming Language. Every language, every framework must have a philosophy, or in loose terms, the “why” behind it. Why did you select your syntax the way it is? Why did you name something this and not that? What can you solve with your language that the others cant?

The philosophy of Java is “Write once run anywhere. And screw the pointers”. The philosophy of C# is like “Something like Java, but sorry, no Js. And screw the conventions”. The philosophy of Groovy seems to be “You are a programmer, you know better. I will standby and hint functions, you do whatever you want with it. And screw the configurations”. The philosophy of TFS, the rich man’s poor version control, is like “I know everything. You programmers don’t know sh*t. Beg me to keep your source safe. And screw You”. In essence it is like “I dont like this feature in this language. So I am creating a new language without that feature”.

So on the lines of the philosophy of Groovy, in which simplicity and intuitiveness seem to be the gravest concern, there are three built-in closures, that I find extremely powerful – the find, collect and inject. If used correctly, they reduce some complex code to really trivial and make a mockery of standard loop syntaxes.

Perfect numbers are indeed a very fascinating math phenomenon. They are few and far between and whether there are infinite perfect numbers is a not yet solved mystery. I will spare writing about perfect numbers as there is an abundance of online literatue on them. Here’s a very simple Groovy OLC that finds perfect numbers upto a given number.

def find_perfect_numbers(def number) {
(2..number).findAll { x-> (1..(x/2)).findAll{ x % it == 0 }.sum() == x }
}

assertEquals(find_perfect_numbers(10000), [1,6,28,8128]

The internal closure finds all the factors of a give number, while the outside closure finds all those whose sum is equal to that number.

Groovy #6 – Curious case of pedantic ignorance

If you know C, its easy to pickup C++.
If you know C++, its easy to pickup Java.
If you know Java, its easy to pickup Groovy.

We have all heard this. Yeah its easy to pickup something. But how easy it is to fit into it? Despite Java being touted as oo language, programmers still write a lot of procedural-type code in it. It is easy to ‘learn’ a language, but much more not easy to assimilate the philosophy of the language or familiarize with its idiosyncracies. I’m still somewhat finding difficulty in fitting into the philosophy of C#/.Net, where the Rate of Entropy (ie the time taken for the code to get into a disorderly or unorganized state) is way lower than that of Java.

When you realize that Groovy treats configuration files as yet another Groovy script, the concept of .properties is thrown out of the window. Along with that key=value pair, the .xml configs are also given a boot. Groovy allows a more compact, more predictable, less verbose, and a much more powerful way of handling configurations.

Consider the following snippet:

//Configuration.groovy
Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

//Person.groovy
class Person {
def config = new ConfigSlurper().parse(Eye)

boolean allowedEyeColor(def color) { color in config.Eye.colors }
}

//Test.groovy
Person p = new Person()
assert true == p.allowedEyeColor('black')

Ok, assuming that this is all the code, what is the most glaring mistake here?

a) In Person, parsing Eye is incorrect
b) Code will not work because allowedEyeColor is not a public method
c) Assert does not fail, the programmer is cheating
d) Assert should not have failed, the groovy compiler is cheating

If you had already spotted the bug, good for you. But you get bonus points if you say that Configuration.groovy is not unit tested :-)

Now lets add a unit test case to directly test the Eye configuration and see the value of Eye.colors:

def config = new ConfigSlurper().parse(Eye)
assert Eye.colors.size() == 5
//Result: assert fails!

The problem had me scratching my head for a few minutes, until I realized that the Orwellian theory applies to programming languages as well – All languages are equal. Some are more equal than others.

Literally more equal, yes.

The Configuration.groovy has the following line:

Eye = {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

Perfectly normal for the Java-tinted eyes.

But in Groovy, the above code is actually declaring a closure. In order to make it a “property”, it has to be declared like this:

Eye {
colors = ['black', 'blue', 'brown', 'green', 'gray']
}

Now, this is actually a config dsl, and Eye.colors can be accessed as expected.

But in the closure case, it has to be accessed like a method:

assert config.Eye().colors.size() == 5

The equals sign had creeped into the code while typing. Call it a habit, reflex or a case of pedantic ignorance.

Groovy #5 – Property reflection by map notation

Yet another nice feature of Groovy is the ability to access a member of an object instance using map notation. This may look like a syntactic sugar at first, but the sugar coat leads to a nice icing on the cake.

Consider a class

class KeyValuePair {
String name
String value
}

The usual notation to access the members would be k.name, k.value. But in Groovy, you can also do it like the following:

KeyValuePair k = new KeyValuePair()
k['name'] = 'searchSite'
k['value'] = 'http://www.google.com'

assert k.name == 'searchSite'
assert k.value == 'http://www.google.com'

So, whats the big deal? The big deal is, reflection made ridiculously easy. Note that ‘name’ is actually a string that evaluates to the member name of the class. Which means it can be a variable.

Consider a trivial ORM implementation – a csv file with a header-row which represent column names and the rows which represent values. How will you generically convert that csv file into an array of a specific object?

class CsvDb {
List data = new ArrayList()

public List load(String fileName, String className) {
FileReader fr = new FileReader(fileName)
String header = fr.readLine()
if (header == null) return data

List columns = header.tokenize(",")
String line
while ((line = fr.readLine()) != null) {
def object = Class.forName(className).newInstance()
List row = line.tokenize(",")
columns.eachWithIndex { col, index -> object[columns[index]] = row[index]?:"" }
data.add(object)
}

data
}
}

Look at line #14, columns.eachWithIndex {} closure, it sets the value of the given object’s property using map notation to the value of the row in the corresponding column.

Now given any csv formatted data and a class that has members matching the column names, the above snippet will generate a List of the given objects.

/** c:/data/flix.csv **/
actor,movie,genre
Ron Livingston,Office Space,Comedy
Joe Pesci,My Cousin Vinny,Comedy
Daniel Craig,Skyfall,Action
Jamie Bell,Tintin,Animation

and we want that mapped to an object called Flix.

package com.moviedb

class Flix {
String actor
String movie
String genre

static List flix

static void load() {
flix = new TextDb().load("c:/data/flix.csv", "com.moviedb.Flix")
}
}
Follow

Get every new post delivered to your Inbox.

Join 129 other followers