Home | About | Sematext search-lucene.com search-hadoop.com
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
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # user >> schema defaults not reflected in generated objects (1.3.2)


Copy link to this message
-
Re: schema defaults not reflected in generated objects (1.3.2)
I'm on a remarkably slow internet connection, so updating the Confluence FAQ
is not happening for me. Could someone please add "Why doesn't the Java
specific compiler generate a constructor with all fields for records?" to
the FAQ with Philip's answer below? I asked this question two weeks ago, and
I'm guessing we'll only get it more regularly.

> If the specific compiler generated a couple constructors --
> > * A default empty argument constructor -- fills fields with defaults.
> > * A constructor with all fields passed in -- assigns fields from the
> constructor and does nothing with defaults.
>
> Unfortunately, the latter is bad for compatibility.  If there are two
> fields of the same time, it's pretty easy (since there's not
> necessarily a canonical order) for this to introduce a nasty
> incompatibility.  This is not theoretical: Thrift ran smack into this.
>  PBs have "Builder" objects, which I imagine don't satisfy your
> performance worries.
>
> If you have getters and setters, you can implement setFoo() with
> "this.fieldsSet.setBit(FOO); this.foo = foo);" (i.e., use a bitmap to
> remember what has and hasn't been set).  The current API doesn't use
> setters, I think, though, so this wouldn't be easily backwards
> compatible.
>
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