@Lukasz: not really since if the parameters changes then the new version will get the new data so this is not a constraint on beam but on the configuration storage which must handle anyway versions compatibility somehow so not a big deal IMHO.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> 2018-01-19 18:41 GMT+01:00 Lukasz Cwik <lc...@google.com>: > Note that using the -parameters flag in javac will require that we never > change parameter names inside methods increasing the backwards > compatibility burden. > > On Thu, Jan 18, 2018 at 12:33 AM, Jean-Baptiste Onofré <j...@nanthrax.net> > wrote: > >> Great idea ! >> >> It sounds good to me. >> >> Regards >> JB >> >> On 01/18/2018 09:27 AM, Romain Manni-Bucau wrote: >> >>> @JB: thought about another option which can be almost hurtless for beam: >>> >>> 1. we ensure all "config" classes are public (would avoid nasty hacks) >>> 2. while migrating to java 8 you activate the javac -parameters flag >>> >>> does it sound better? >>> >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog < >>> https://rmannibucau.metawerx.net/> | Old Blog < >>> http://rmannibucau.wordpress.com> | Github < >>> https://github.com/rmannibucau> | LinkedIn < >>> https://www.linkedin.com/in/rmannibucau> >>> >>> 2018-01-14 19:25 GMT+01:00 Romain Manni-Bucau <rmannibu...@gmail.com >>> <mailto:rmannibu...@gmail.com>>: >>> >>> Works for me but forbids the usage of the abstract class cause of >>> final >>> fields. That said if beam can get a Factory.createIO(clazz, >>> configAsPrimitivesMap) Im happy whatever solution is used. >>> >>> >>> Le 14 janv. 2018 17:19, "Jean-Baptiste Onofré" <j...@nanthrax.net >>> <mailto:j...@nanthrax.net>> a écrit : >>> >>> >>> Hi Romain, >>> >>> I think the missing thing for automation projects is probably >>> more >>> around "documentation" for the setters/getters. >>> >>> So, why not: >>> 1. we don't change the usage and AutoValue itself >>> 2. we can imagine to add a new set of annotations in IO Common >>> with a >>> specific annotation processor that create another POJO class, not >>> actually used in the IO code, but "describing" the configuration >>> for >>> automation projects. This POJO will be public, no final. >>> >>> WDYT ? >>> >>> Regards >>> JB >>> >>> On 12/01/2018 19:26, Romain Manni-Bucau wrote: >>> >>> Hi guys >>> >>> I'd like to discuss the IO configuration. >>> >>> My goal is to be able to instrospect (or equivalent) the IO >>> to >>> instantiate them programmatically in a generic manner from a >>> generic >>> config - this is not yet linked to the system property topic >>> but can >>> benefit beam on this other topic too. >>> >>> Auto value loosing the final fields ordering is impossible >>> to use >>> until you parse sources. >>> >>> In other words: auto value is nice for programmatic usage >>> but is >>> blocking for any automotion on top of it - even using unsafe >>> is not >>> an option ATM :(. >>> >>> Can we try to get something to solve that need please? >>> >>> Here are the solutions I see (pick just one ;)): >>> >>> 1. migrate IO to IOOptions (based on pipeline options kind of >>> design). This is a breaking change - but I'm sure we can >>> mitigate it >>> in term of user compatibility - but it unifies the beam >>> config and >>> enables to not have IO specific configurations which can vary >>> between the IO if not developped by the same guy. >>> 2. Add an extension to @AutoValue to also generate the field >>> names >>> order in the create() (@Fields({"address","username" >>> ,"password"}). >>> Cheap but the way to instantiate an IO from a config is >>> still a pain >>> (think Factory.createIO(clazz, properties)) >>> 3. Also generate a plain pojo from the abstract @AutoValue >>> class - >>> this requires to modify the source class to make it working >>> but is >>> feasible with a processor >>> 4. drop autovalue and use plain pojo - writing it cause it >>> is a >>> technical option but it leads to break as much as 1 without >>> getting >>> all the benefit to have an agnostic config and the tooling >>> we can >>> build on top of it >>> 5. probably others >>> >>> >>> Wdyt? >>> >>> Personally I really like 1 cause it starts to create a clean >>> programming model we can then build other features on. >>> >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau >>> <https://twitter.com/rmannibucau>> | Blog >>> <https://rmannibucau.metawerx.net/ >>> <https://rmannibucau.metawerx.net/>> | Old Blog >>> <http://rmannibucau.wordpress.com >>> <http://rmannibucau.wordpress.com>> | Github >>> <https://github.com/rmannibucau < >>> https://github.com/rmannibucau>> | >>> LinkedIn <https://www.linkedin.com/in/rmannibucau >>> <https://www.linkedin.com/in/rmannibucau>> >>> >>> >>> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > >
