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
