Add Kotlin

[pengrad]

It should be more fun to write models in Kotlin.
Here is the initial Kotlin support with some request, models, and response converted.

We still need to keep it compatible with Java code, especially already existing.
So we either need to generate explicit getters (even if they're not needed in Kotlin but to have a Java getters without get) or define annotation for every field such as @get:JvmName("fileId").

We can freely convert any existing models classes, but TelegramBotTest should at least compile without changes.
It will act like a Java compatibility check.

Dear @anfanik you are very welcome to review and to share any ideas on improving it.

[anfanik]

I really love Kotlin and all my projects with this library written in it but I think that it’s a really bad idea.

I have experience writing a library in Kotlin with support for both languages, and it was terrible.

I think this PR will disrupt the smooth usability experience for Java users and won't provide a lot of features for Kotlin users. (But fields instead of getters are cool, I really want it 👀)

[anfanik]

I have an idea (and I'm realizing it with my telegram-api-kindings, but not really fast 😅). Here is my view on Kotlin support:

• Another module/project: Java users won't be happy with + some MBs to the library and to their jar

• Own model. It can give a lot of benefits: backward compatibility for Java users; ability to write it without Java support, to refactor and to remove all of legacy code

• Not only model changes. I'd like to merge features (Method and Markdown extensions from my kindings) and add new: requests and responses to data classes, Kotlin-style builders (what I can't merge to kindings haha), complex null-safety and maybe a way to use kotlinx-serialization instead of gson

[pengrad]

I think that it’s a really bad idea.

That was unexpected 😁

I have experience writing a library in Kotlin with support for both languages, and it was terrible.
I think this PR will disrupt the smooth usability experience for Java users and won't provide a lot of features for Kotlin users.

I think we can try to do better. As a counter-example I can give OkHttp library that was rewritten in Kotlin and now is Kotlin first, and yet it's used in this library with no usability issues.
We won't have all Kotlin features and extensions available for Java users, this is fine.
Basically for Java it will stay as simple as it is now, and for Kotlin users we could have all available rich commands and syntax sugars.

I've seen your telegram-bot-api-kindings, it is great. It can definitely be merged directly to this java-telegram-bot-api lib (We should discuss design of extensions though 😁)

Another module/project: Java users won't be happy with + some MBs to the library and to their jar.

They will bear it. I'm not the fan of the new module right now. If we keep main module in plain java then it would make sense to have additional -ktx artifact. But with adding Kotlin into the main lib it's not needed, at least for now. Maybe more application-level libs like handling authorisation, step by step flows deserve a separate lib, but that's another story.

Own model. It can give a lot of benefits: backward compatibility for Java users; ability to write it without Java support, to refactor and to remove all of legacy code

I think with no issues we can re-write models and everything else in Kotlin without affecting Java compatibility.

Not only models changes. I'd like to merge features (Method and Markdown extensions from my kindings) and add new: requests and responses to data classes, Kotlin-style builders (what I can't merge to kindings haha), complex null-safety and maybe a way to use kotlinx-serialization instead of gson.

Yes, indeed! We are not limited by model only. Especially extensions will be very useful and handy (and won't require internal changes). kotlinx-serialization is questionable 😅 but better null-safety for kotlin is absolutely beatiful.

In general, I don't see any big obstacles. Java users will have all the same they have now, and Kotlin users will get much more simplicity and hopefully safety.