The problem is that our setters/getters were never 1-to-1. Some setters set
a group of related config, but the getters need to read them individually,
to perform different functions. For instance, setting the connector
information... you'd pass username and password information, but the code
inside (or a subclass) may need just the username, or the instanceName, or
(in the past) the default table name, etc. Or, for example, when we've
deprecated some setters in favor of others, the corresponding getters no
longer made sense. For instance, when we added the ability to specify a
password file, the entire concept of getting a password back wouldn't make
sense... you never gave a password in the first place. It's now no longer
just deserialization, but you'd have to add new functionality to read the
password file and return a password, that has nothing to do with needs
internal to the class... but would just be providing a complete
setter/getter API for the sake of doing it.

I'm not going to argue that a particular field is or isn't going to
change... I'm just explaining the history of why it's like that, and the
kinds of changes that have occurred in the past. Personally, I don't think
people should be depending on our serialization. They launched the job,
they should know what they put in it. If they need to pass state to
different components of their code, they shouldn't depend on our
serialization to carry that state, even if it seems like there's some
Christopher L Tubbs II
On Wed, Jul 16, 2014 at 9:48 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB