Hi Romain
IMO the use cases are not the same, in CDI you have
SomeClass{
@Inject
private MyType type = Instance<MyType>;
Here the information about the target type is contained in the Field type.
The part defined in <MyType> is removed by type erasure.
In Tamaya this problem is even more simpler, since
a) the target type is explicitly passed, when accessing configuration
b) the PropertyConverter to be used is passed explicitly. If the user does
not use raw types, the compiler will ensure it will match.
Now the situation we have is:
public PropertyConverter<Integer>{...}
during runtime gets to
public PropertyConverter{}
(during runtime you have raw types). The information in <> is lost and not
accessible using reflection. You can simply imagine this is the case,
because without that, Java 5 would not be compatible with versions before
(that was the trick they applied to ensure binary compatibility).
If I miss something, I am happy to learn.
Best,
Anatole
2015-01-20 17:46 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> 2015-01-20 17:40 GMT+01:00 Anatole Tresch <[email protected]>:
> > Hi Romain
> >
> > see inline.
> >
> > 2015-01-20 17:29 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> >
> >> answered inline
> >>
> >> 2015-01-20 17:19 GMT+01:00 Anatole Tresch <[email protected]>:
> >> > Hi Romain
> >> >
> >> > 2015-01-20 17:02 GMT+01:00 Romain Manni-Bucau <[email protected]
> >:
> >> >>
> >> >>
> >> >> performance overhead at runtime = 0...you shouldn't do it at runtime
> >> >> but at registration time.
> >> >
> >> >
> >> > -> Base on what information?
> >> >
> >>
> >> the fact it is not called? if you use this when you register the
> >> converter then you dont need it anymore and you build your meta at
> >> registration and didnt pollute the API with new annotations.
> >
> >
> > I dont get the point. Again, please answer my questions.
> >
> > How do you want to evaluate the target type a converter is targeting
> > during registration?
> >
>
> answering in next answer
>
> >
> >
> >> >> > Also when we would add a method returning the expected formats
> (which
> >> I
> >> >> > think would be a very useful thing) we would loose the functional
> >> >> aspects,
> >> >> > if we add the
> >> >> This is why making the type the contract makes sense here.
> >> >>
> >> >> -> Dont get the point.
> >> >
> >>
> >> if I have MyPropertyConverter<Foo>. The type says me what I need (ie
> >> Foo) so why doing:
> >>
> >> @TamayaMeta(Foo.class)
> >> MyPropertyConverter<Foo>
> >>
> >> ?
> >>
> >
> > Simple because you dont have that information at runtime in Java 7.
> >
>
> oops so CDI is fully broken. Of course you have it - even in java 6.
>
> >
> > You'll surely speak about hierarchy etc? It is of course true but
> >> 1) most of the time you can deduce it counting the distance to the
> desired
> >> class
> >>
> > Already stated this will not work in all cases. Try thinking doing it
> > alternately please.
> >
> > 2) if you really want to specify it you can as you mentionned add an
> >> annotation but not by default to keep it simple and readable
> >
> > Combined with 1, this makes no sense. When I have the information from a
> > reliable source (1 is not reliable) and dont need 2, if I cant do it, I
> can
> > go home and cry or just look for a soliution, I will not do things more
> > simpler, just because of simplicitly. Reduce to the max, but not one step
> > further!
> >
>
> You didnt get me: I'm not opposed to @ConverterType or whatever name
> it is, I'm opposed to force it cause it makes super verbose classes
> for nothing + in 80% of the cases (100 in our impl IIRC) it is
> redundant.
>
> >
> >
> >> >> > I see the following options currently:
> >> >> > 1) Define an annotation, e.g. @ConverterSpec to add to the
> meta-info
> >> >> > automatically for the auto-registered PropertyProvider instances.
> >> >> > 2) Add an additional interface, extending PropertyProvider that
> adds
> >> the
> >> >> > additional methods. This interface then must be used for
> registration
> >> and
> >> >> > adds the missing functionality.
> >> >> > 3) We could let be PropertyProvider to be non functional, but add
> in
> >> >> Java 8
> >> >> > an additional method to Configuration, which tykes a
> >> Function<String,T>.
> >> >> >
> >> >>
> >> >> In all cases you break java 8 lambdas, not an issue by itself but we
> >> >> should maybe think removing this java 8 module which will soon be
> only
> >> >> justified by Optional which is highly controversed.
> >> >>
> >> >
> >> > This is simply not true at all:
> >> > - 1 Will not break it at all and will be Java 7 compatible.
> >> > - 2 Will also not break it, since the extended interface is only used
> for
> >> > regitration not for the Configuration interface, where
> >> > you can pass a Lambda starting with Java 8.
> >> > - 3 Would not break Lambdas, because in Java 7 PropertyProvider is not
> >> > functional because there is no such concept, and in Java 8 you have
> the
> >> > additional method, which takes a Lamba.
> >> >
> >> >
> >>
> >> 2 points here
> >>
> >> 1) if you split that much the API then I say (again) what I said in
> >> j7/j8 thread: tamaya will fork by itself and both will not be
> >> maintained correctly
> >>
> >
> > Not true! 1 and 2 is exactly the same in Java 7 and 8.
> >
> >
> >
> >> 2) that said this confirms what is said before: you dont need this
> >> getTargetType()
> >
> >
> > As already said, useless to comment. It will not work as you suggest.
> >
>
> I fear you don't know java reflection API enough here, or I am really
> missing something important but I dont get yet what
>
> >
> >> >
> >> >
> >> >
> >> >>
> >> >> > -Anatole
> >> >> >
> >> >> >
> >> >> > 2015-01-20 16:33 GMT+01:00 Romain Manni-Bucau <
> [email protected]
> >> >:
> >> >> >
> >> >> >> The annotation by itself doesn't make of the interface a
> >> >> >> FunctionalInterface or the opposite (ie you can be without it) -
> so
> >> >> >> yes this is fully useless from a code/bytecode point of view.
> That's
> >> >> >> because getTargetType() was added.
> >> >> >>
> >> >> >> I'd just remove it and use reflection to determine it. We would
> then
> >> >> >> be able to do a lot more than simple Class which are more and more
> >> >> >> java 1.4 (it is very funny to see it aside java 8 code ;))
> >> >> >>
> >> >> >>
> >> >> >> Romain Manni-Bucau
> >> >> >> @rmannibucau
> >> >> >> http://www.tomitribe.com
> >> >> >> http://rmannibucau.wordpress.com
> >> >> >> https://github.com/rmannibucau
> >> >> >>
> >> >> >>
> >> >> >> 2015-01-20 16:18 GMT+01:00 Werner Keil <[email protected]>:
> >> >> >> > How, did it lose the annotation or was the method signature
> changed
> >> >> >> > violating the Functional Interface definition?
> >> >> >> >
> >> >> >> > Werner
> >> >> >> >
> >> >> >> > On Tue, Jan 20, 2015 at 4:10 PM, Reinhard Sandtner <
> >> >> >> > [email protected]> wrote:
> >> >> >> >
> >> >> >> >> Hey guys
> >> >> >> >>
> >> >> >> >> build is broken since PropertyConverter is no longer a
> >> >> >> FunctionalInterface
> >> >> >> >> :-(
> >> >> >> >>
> >> >> >> >> shall i fix it or is someone working on it?
> >> >> >> >>
> >> >> >> >> lg
> >> >> >> >> reini
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > *Anatole Tresch*
> >> >> > Java Engineer & Architect, JSR Spec Lead
> >> >> > Glärnischweg 10
> >> >> > CH - 8620 Wetzikon
> >> >> >
> >> >> > *Switzerland, Europe Zurich, GMT+1*
> >> >> > *Twitter: @atsticks*
> >> >> > *Blogs: **http://javaremarkables.blogspot.ch/
> >> >> > <http://javaremarkables.blogspot.ch/>*
> >> >> >
> >> >> > *Google: atsticksMobile +41-76 344 62 79*
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > *Anatole Tresch*
> >> > Java Engineer & Architect, JSR Spec Lead
> >> > Glärnischweg 10
> >> > CH - 8620 Wetzikon
> >> >
> >> > *Switzerland, Europe Zurich, GMT+1*
> >> > *Twitter: @atsticks*
> >> > *Blogs: **http://javaremarkables.blogspot.ch/
> >> > <http://javaremarkables.blogspot.ch/>*
> >> >
> >> > *Google: atsticksMobile +41-76 344 62 79*
> >>
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79*
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
