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 <
[email protected]> 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
