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/rmannibuca >> u> | 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 >
