polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: Generic composite types in Zest
Date Sun, 20 Dec 2015 11:53:43 GMT
Hi all,
in Scala there is a workaround for erasure, take a look here:


but probably that info is accessible only in/from Scala code.
But in the implementation they use some trick available in Java, maybe
something like this could be implemented/reimplemented even here.
Some info on the trick used here (in comments):


hope you can find useful ...

In Groovy I'm not sure there is something similar, but with the
ability to have metadata for any class probably something could be
done. Some info on available AST Transformations here:


Anyway note that reified generics could have a runtime overhead, so
I'm not sure it will be a good solution for all cases (in many
probably it is :-) ). Anyway it seems that Java 10 could implement
something better on generics ... who can say ?



2015-12-18 2:40 GMT+01:00 Niclas Hedhman <niclas@hedhman.org>:
> In Zest Java, there is limited support for generic types. For instance,
>     @Service
>     Foo<Long> longFoo;
>     @Service
>     Foo<String> stringFoo;
> is handled as expected.
> To sort out what Java can and can not do;
> As you mention, Java's generics support is not complete, but it is (and
> always been) incorrect (despite everyone saying so) that the generics are
> compile-time only.
> The "declaration" of something (method return type, method parameters,
> fields,...) all has the generics information in them, even the TypeVariable
> name ("K" and "V" in Map<K,V>). But the object doesn't reference the
> ParameterizedType (only the Class) instance, so that bit is missing (still,
> and probably not going to be fixed).
> This has some consequences,
> {
>     Object list = new ArrayList();   // local variable = No generics
> information
>     abc( list );   // Requires cast, but only for compiler. No runtime
> check possible
>     def( list );    // Requires cast, but only for compiler. No runtime
> check possible
> }
> public void abc( List<String> list ) {}
> public void def( List<Long> list ) {}
> So, from there it is possible to fill the List with any type you want. So,
> there is no possibility to equal()=false for
>     new ArrayList<Long>().equals( new ArrayList<String>() )
> the information isn't there.
> Now, this also means that;
>     ValueBuilderFactory vbf;
>     MyValueComposite<String> v =
>         (MyValueComposite<String>) vbf.newValue( MyComposite.class);
> will "work" just as well as the java.util.List shown above.
> So beyond these basic two cases, I am not sure what else can be done to
> support Generic Types in Zest Java.
> I am uncertain whether nested generics works for Services;
>     @Service
>     Foo<Map<String, Map<Long, Bar>>> foo;
> But that would be the only thing that I could imagine to be improved.
> Other concrete ideas are welcome.
> Niclas
> On Thu, Dec 17, 2015 at 10:33 PM, Stanislav Muhametsin <
> stanislav.muhametsin@zest.mail.kapsi.fi> wrote:
>> This thing came to my mind when writing previous mail about Assemblies,
>> Models, and Instances.
>> Is it true that Zest still has limitation/restriction not to support
>> generic composites (i.e. MyComposite<T, U> -interfaces as composite types)?
>> IMO you might want to remove that limitation.
>> I am not sure if that is possible, since generics in Java exist only at
>> compile-time (is this so with newest Java?).
>> But I am certain that many people are most likely to give up on Zest when
>> they encounter that limitation (I know it was a tough slap-in-the-face for
>> me, when I encountered it).
>> If you decide to remove this limitation, I could give some pointers as to
>> which pitfalls to avoid, and what to keep in mind, when dealing with
>> generic composite types.
>> I encountered a lot of trouble when I implemented generic composites in
>> Qi4CS, but the type system in CLR preserves generic argument information at
>> runtime (so, in Java terms, that List<String>.class will return *false*
>> when doing equality comparison with List<Int32>.class), so it was possible
>> to implement support for generic composite types.
>> In Zest, it might make code generation more complex, and it might make the
>> method intercepting code in Zest more complex, but I think it is worth the
>> hassle.
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java

View raw message