Support for generics without type erasure (aka templates)

[Nikolay Shustov]

Hi.
I have an idea on how Lombok can be used to support the Java generics that do not do type erasure. The concept is very like C++ idea of templates.

I am attaching the .PDF with the draft and examples to this message.

Unfortunately, I will not likely to be able to work on the implementation soon (real life, time troubles), but if someone is interested to pick it up, I will gladly do my best to help at least with the design of the idea. I am new to Lombok, but I read the contributor documentation and went through some Lombok source code, so I think I got a reasonable understanding the complexity. By my estimate, it would be a #bigjob scope project, needed to be done in some iterations.

Cheers,
- Nikolay

[Thorsten Glaser]

Hi Nikolay,

> I am attaching the .PDF with the draft and examples to this message.

how do you know which methods to add to class A, even in just the
first example?

Note that class A may be, and very likely will be, compiled in a
different pass from its users, even be shipped in a library.

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also, https://www.tarent.de/newsletter
╱ ╲ header encryption!
****************************************************

[Nikolay Shustov]

Hi Mirabilos,

> how do you know which methods to add to class A, even in just the

> first example?

The generated method signature is defined by the set of the actual types used when the method template is "instantiated" (in C++ terms) .
The types of the arguments inferred from the template method invocation determine which specific classes should be used in generated method in place of which type parameter usage (and, in my example, the will define name of the generated method).

> Note that class A may be, and very likely will be, compiled in a
> different pass from its users, even be shipped in a library.

The reuse of templates (as I suggest them) from compiled classes is a separate big topic.
The templates resolution happens at compile time, not in runtime, that's why, say, in C++, templates distributed with compiled libraries as headers.
Languages that do not support that (e.g. C#) got the appropriate metadata injected into the compilation output.

We can choose either of those approaches or something else:

- we can declare that we require to have .java file along with the .class file for the template classes, so we could generate AST for it and allow template instantiations

- we can serialize the AST of the class into a separate file and declare that we require this file to be available along with .class file, maybe as a resource file
- we can embed any kind of  metadata that we need into the generated .class file by placing it in the special runtime-retained annotation

We can simply start with saying "for now we support templates for the compilable code only" and start pounding on the best way to approach it - it should not break the compatibility with the code that already uses it, if we add this later.
Implementing things in increments, we can still have added value on each step.

What I wanted to do with my initial e-mail is to kick off a discussion about that feature.
If it appears like a good idea in general, the discussions of technical details will definitely follow up.

Regards,

- Nikolay