Plug-In - Return Generic CDT

According to the Appian Public API's, and the Custom Smart Service documentation, it is not supported to return the 'Object' type directly from a plugin.

Have you considered the "Excel Tools" shared component?

If Excel Tools does not work for you, my recommendation is to create a separate Appian-callable custom function in Java, one per CDT you need to ingest and pass arrays of the CDT's (not the XML) between Appian and Java.  While there's a bit of copy/paste boilerplate code, it would significantly reduce the complexity of your overall need and be more efficient in the longer-term.

If you still really think "generic" is the best way to go...

It is possible to meet your specific description in a less-generic way, but please read the caveats later.  You would want to use Java's XJC compiler to create a POJO with JAXB annotations that mirror the CDT's you expect to use in Appian.  Then, your plugin would have to know the type that each CSV line represents (presumably as an input).  Based upon the expected type and CSV read-in, you would class-load and fill in multiple POJO's in Java.  In Java you would then marshal the XML, return the string array of XML and do an apply(torecord(), ... ) on the result in Appian.  

There are some major caveats to attempting a generic approach like this, however.

• While unlikely in most cases, CDT fields with a @ManyToOne JPA annotation (as a foreign key lookup reference in the CDT), will always be blank after the torecord() call (untested after 16.3).
• Since a string XML is returned from the plugin for each row, the process data would be represented in Appian as both an XML array and as a CDT array.  In other words, the effective memory footprint for this process's data is doubled.
• Passing strings that specify types, while possible, masks the highly-coupled nature of plugin CDT's to their Appian counterparts.
  • With generic classloading of types, if something about an Appian CDT changes, there is no way to know there will be an error prior to digging into the runtime data of the plugin that threw an error.  
  • Conversely, if the design is non-generic and the CDT's themselves are passed as plugin inputs/outputs, usually a good verbose error is thrown either (a) when the CDT is saved or (b) as soon as the plugin is started.  No developer needs to care about the runtime data or plugin logs since the error happens before the data is populated.

Guide to generating POJO's from XSD's using XJC: https://docs.oracle.com/javase/8/docs/technotes/tools/unix/xjc.html

XML Marshalling: Google jaxb marshal pojo to xml