What are the pros and cons of using XML to transfer data in this Java program? [closed]

Question

I've been asked to write a GUI for an existing shell/cmdline program written in Java, and I want to create a layer of abstraction between the GUI and the original program that makes it easy to add a different GUI (a web interface, for example, rather than a desktop application). At the moment, the structure of the program is as follows:

The command line options are immediately translated into a Java hashtable (taking an option such as -f opt to the hash "-f=>opt". These options are then used to set up the environment object, which the program uses.

The structure I have in mind is:

Following the solid lines, this means that the GUI produces an XML file holding the same information as the shell/cmdline options, which is then used to set up the environment option.

The thing is, I'm not quite sure if that's the best way for things to work (whence the dotted lines, signifying alternative structures) and I also don't know if XML is the right choice here.

As it stands, the parts of the program that set up the environment object from the options are located in the same methods as the parts that use the environment to get the results. So it would be easier to implement something that fed the shell/cmdline arguments directly into the program than it would to implement a structure where the information was passed through as an XML file. I certainly don't want to create the XML file and then translate it into shell options and transfer those to the program, but it might make more sense for the GUI to generate the shell options itself rather than creating an XML.

The main advantage of using an XML file as far as I can see is that it makes the job of future developers easier as they can use existing libraries to create the XML files rather than have to worry about getting the -a opt1 -b opt2 -c opt3 [...] syntax right.

On the other hand, I've heard that trying to create your own XML language is not to be taken lightly (though the program as it stands stores data in XML files with no DTD or even a schema as far as I can tell).

Is my approach more or less right? Or am I using completely inappropriate tools for the job I'm trying to do?

Answer 1

In XML approach, you would be taking the user options, create an XML, pass it to main program, parse the XML and extract values to set the environment. These efforts will be too much unless you are passing options from one process to another process or over the wire (Even in that case you can use json too)

If we are talking about a single process where these options are passed either through GUI or command line, we can simply encapsulate these parameters into a Java object, populate it by using the command-line / GUI and pass it to main program. For instance Command Line or GUI -> Populate EnvironmentOptions object -> Main program

And to provide require abstraction, you can create an interface say IEnvironmentOption and use it to set required properties.

interface IEnvironmentOption {
    public static final String OPTION_NAME = "-t";

    public void setOption(String name, String value);

    public String getOption(String name);
}

class EnvironmentOptions implements IEnvironmentOption {
    private Properties envProperties;

    @Override
    public void setOption(String name, String value) {
        envProperties.setProperty(name, value);
    }

    @Override
    public String getOption(String name) {
        return envProperties.getProperty(name);
    }
}

Answer 2

It seems like you have a solid plan. It's a pretty common paradigm to load options from command line arguments and/or a configuration file. There is no problem using XML, but JSON and YAML are a couple of alternatives with terser syntax that will work just as well.

Java already has Properties and Preferences, which can be used to accomplish this. You should take a look into those before reinventing the wheel.