What might some random Spring config (in this case a Spring-batch example) look like if JSON were the configuration/injection message format? What is good, what is bad?
<bean id="taskletJob" parent="simpleJob">
<property name="steps">
<list>
<bean id="deleteFilesInDir" parent="taskletStep">
<property name="tasklet">
<bean
class="org.springframework.batch.sample.tasklet.FileDeletingTasklet">
<property name="directoryResource"
ref="directory" />
</bean>
</property>
</bean>
<bean id="executeSystemCommand" parent="taskletStep">
<property name="tasklet">
<bean
class="org.springframework.batch.sample.common.SystemCommandTasklet">
<property name="command" value="echo hello" />
<!-- 5 second timeout for the command to complete -->
<property name="timeout" value="5000" />
</bean>
</property>
</bean>
</list>
</property>
</bean>
<bean id="directory"
class="org.springframework.core.io.FileSystemResource">
<constructor-arg value="target/test-outputs/test-dir" />
</bean>
My swing at JSON, using JSON-ish features and advantages (lists, maps/objects, etc)
{
"taskletjob":
{"#t":"BEAN", "id":"taskletJob", "parent": "simpleJob",
"properties": {
"steps": [
{"#t": "BEAN",
"id":"deleteFilesInDir",
"parent":"taskletStep",
"properties":
{"tasklet":
{"#t":"BEAN", "class":"org.springframework.batch.sample.tasklet.FileDeletingTasklet",
"properties": {"directoryResource" : {"#ref":"directory"}}
}
}
},
{"#t": "BEAN",
"id":"executeSystemCommand",
"parent":"taskletStep",
"properties":
{"tasklet":
{"#t":"BEAN", "class":"org.springframework.batch.sample.common.SystemCommandTasklet",
"properties": { "command": "echo hello", "timeout": 5000}
}
}
}
]
}
},
"directory": {
"#t":"BEAN", "id":"directory",
"class":"org.springframework.core.io.FileSystemResource",
"constructor-args": ["target/test-outputs/test-dir"]
}
}
So what I found out:
Size in LOC was mostly identical. No real big savings there.
Spring utilizes namespaces implicitly or explicitly... No real JSON mechanism, so I invented the "#t" which is supposed to indicate the object type if it is typed, to give guidance to some parser/bean construction code as to required fields, etc.
In other places, like properties, the JSON object is used more as a map, since it is more intuitive that way. The JSON format here seems much more natural, and seem to save lots of keystrokes. I mean would you rather type:
<property name="command" value="echo hello" />
<property name="timeout" value="5000" />
or
"properties": { "command": "echo hello", "timeout": 5000}
Clear win for the JSON there.
However, JSON has some weird corner cases in formatting, such as arrays of objects. How do you render that without wasting extra tabs or lines? Granted, the <list> construct in spring xml wastes a tab and a line...
And all the double-quotes in JSON. Annoying. Not as annoying as xml ending tags. And why are commas even needed?
Other JSON problems: Getting lost in curly-brace land. WHile annoying verbose, at least closing tags in XML let you see what's being ended/closed. But considering most modern editors have curly brace features for C and Java code, this isn't a huge deal.
But if I had my druthers with a variation on JSON, where you don't need double-quotes on the object keys, values are optional, and drop the commas, why can't JSON be this?
{
taskletjob:
{#BEAN id:"taskletJob"
parent: "simpleJob"
properties: {
steps: [
{#BEAN" id:"deleteFilesInDir"
parent:"taskletStep"
properties
{tasklet:
{#BEAN class:"org.springframework.batch.sample.tasklet.FileDeletingTasklet"
properties: {"directoryResource" : {"#ref":"directory"}}
}
}
}
{#BEAN id:"executeSystemCommand"
parent:"taskletStep"
properties:
{tasklet:
{#BEAN "class":"org.springframework.batch.sample.common.SystemCommandTasklet"
properties: { command: "echo hello" timeout: 5000}
}
}
}
]
}
}
directory: {
#BEAN id:"directory" class:"org.springframework.core.io.FileSystemResource"
constructor-args: ["target/test-outputs/test-dir"]
}
}
... Not a huge difference, but it would make reorganizing and moving object chunks around without worrying about breaking the commas in a list, or the fields inside an object. I think the parser would be about the same, no impacts to speed. But JSON the format spec, that ship has sailed... Maybe it looks too much like S-expr...
