So your saying that this configuration storage is something that will not be part of Apache Beam and that backwards compatibility is not being changed then this sounds fine to me.
On Fri, Jan 19, 2018 at 9:51 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Luke, > > I don't think we have a huge drawback here. The byte code will contain > additional information for methods parameters. > > The only impact is for third parties using Beam by reflection (which is > rare, only the project build on top of Beam might be impacted). > > Regards > JB > > On 01/19/2018 06:41 PM, Lukasz Cwik wrote: > >> 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 >> <mailto: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 >> <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>> >> >> 2018-01-14 19:25 GMT+01:00 Romain Manni-Bucau < >> rmannibu...@gmail.com >> <mailto:rmannibu...@gmail.com> <mailto: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> >> <mailto: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> >> <https://twitter.com/rmannibucau >> <https://twitter.com/rmannibucau>>> | Blog >> <https://rmannibucau.metawerx.net/ >> <https://rmannibucau.metawerx.net/> >> <https://rmannibucau.metawerx.net/ >> <https://rmannibucau.metawerx.net/>>> | Old Blog >> <http://rmannibucau.wordpress.com >> <http://rmannibucau.wordpress.com> >> <http://rmannibucau.wordpress.com >> <http://rmannibucau.wordpress.com>>> | Github >> <https://github.com/rmannibucau >> <https://github.com/rmannibucau> <https://github.com/rmannibucau >> <https://github.com/rmannibucau>>> | >> LinkedIn <https://www.linkedin.com/in/rmannibucau >> <https://www.linkedin.com/in/rmannibucau> >> <https://www.linkedin.com/in/rmannibucau >> <https://www.linkedin.com/in/rmannibucau>>> >> >> >> >> -- Jean-Baptiste Onofré >> jbono...@apache.org <mailto:jbono...@apache.org> >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >> >> > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com >
