--------------Original Comment History----------------------------
Comment from = cf126330 on 2014-12-15 03:46:44 +0000
Various script languages have extensive support for data procesing, which makes it easy to write batch components. It will be nice to support certain batch artifacts writting in scripting languages, and open up the Java batch framework to scripting developers as well.
For instance, a batchlet written as Groovy script to perform a short task. Or ItemReader, ItemProcessor, and ItemWriter written as JRuby script to process CSV resources.
We may also need to adjust job xml schema to accommodate scripting-related configurations.
Comment from = BrentDouglas on 2014-12-15 16:34:41 +0000
Is this really necessary? You can run Groovy batchlets the same way you would java batchlets, they are both going to produce regular class files. I just knocked up an example doing just that (https://github.com/BrentDouglas/groovy-batch-example) and it works as expected. Regarding scripts in other languages, it would be trivial to knock up a batchlet/other artifact that plugs a script loaded based on a property into a ScriptEngine as it it, it there really any need to change anything?
Regarding the job schema, section 10.6 is pretty clear that implementation specific loaders are allowed.
Comment from = cf126330 on 2014-12-16 15:47:08 +0000
While it is certainly possible to achieve all these within application space with the current spec, it will be even better to avoid any intermediary if the spec can standardize it in future releases. This way any batch spec implementation can implement it in a portable way, without resorting to any implementation-specific loader.
Originally opened as bug 6581 by cf126330
--------------Original Comment History---------------------------- Comment from = cf126330 on 2014-12-15 03:46:44 +0000
Various script languages have extensive support for data procesing, which makes it easy to write batch components. It will be nice to support certain batch artifacts writting in scripting languages, and open up the Java batch framework to scripting developers as well.
For instance, a batchlet written as Groovy script to perform a short task. Or ItemReader, ItemProcessor, and ItemWriter written as JRuby script to process CSV resources.
JSR 223 Scripting for the JavaTM Platform (https://www.jcp.org/en/jsr/detail?id=223) may be leveraged to plugin in various scripting engine.
We may also need to adjust job xml schema to accommodate scripting-related configurations.
Comment from = BrentDouglas on 2014-12-15 16:34:41 +0000
Is this really necessary? You can run Groovy batchlets the same way you would java batchlets, they are both going to produce regular class files. I just knocked up an example doing just that (https://github.com/BrentDouglas/groovy-batch-example) and it works as expected. Regarding scripts in other languages, it would be trivial to knock up a batchlet/other artifact that plugs a script loaded based on a property into a ScriptEngine as it it, it there really any need to change anything?
Regarding the job schema, section 10.6 is pretty clear that implementation specific loaders are allowed.
Comment from = cf126330 on 2014-12-16 15:47:08 +0000
While it is certainly possible to achieve all these within application space with the current spec, it will be even better to avoid any intermediary if the spec can standardize it in future releases. This way any batch spec implementation can implement it in a portable way, without resorting to any implementation-specific loader.