yes and no (inline)
Romain Manni-Bucau @rmannibucau http://www.tomitribe.com http://rmannibucau.wordpress.com https://github.com/rmannibucau 2015-01-20 18:15 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > IMO the use cases are not the same, in CDI you have > > SomeClass{ > > @Inject > private MyType type = Instance<MyType>; > private Instance<MyType>? btw this mecasnism is also used if you have @Inject Converter<Boolean> and have a class BooleanConverter -> this really looks close to half of we need. > Here the information about the target type is contained in the Field type. > The part defined in <MyType> is removed by type erasure. > not for type hierarchy but for variables > 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. > we are not in this case, we are in the following one: public IntegerConverter [extends|implements] PropertyConverter<Integer> {} And here you can get the Integer checking parameters of the generic [superclass|interfaces]. I think it is interesting because it allows you to register a type just doing: public IntegerConverter .... {...} + META-INF/services/...., nothing else > 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*
