The Future of TikXML

[sockeqwe]

As you all have noticed TikXML is not in a good shape anymore. This has various reasons but the main reason probably is that I'm not working for Tickaroo anymore (since more than 2 years), the company where we have started this project. When I left Tickaroo, Tikxml was working good enough and kind of has been seen as feature completed as it worked good enough for the use case at Tickaroo.

Right now there are some real issues that need to be fixed:

• Gradle: We migrated the project from maven to gradle. While doing that unfortunately and unnoticed we have broken our CI pipeline. That means no tests were actually run on new PR that have been merged in the meantime although CI did mark the PR as green and we assumed the tests passed. Truth is though that it didn't run the full test suite. That caused some PR's to introduce bugs like java.lang.ArrayIndexOutOfBoundsException size=1 offset=1 byteCount=1 #128 error: incompatible types: Object cannot be converted to ... #123. Furthermore, it also broke publishing artifacts for some reasons. That is why some artifacts of 0.8.15 are missing.
• Continious Deployment: Even if Gradle would work our current CI System (Travis CI) has issues with uploading artifacts in parallel (I'm not talking about SNAPSHOTs, I'm talking about real releases). In the past I made much better experience with Circle CI. Therefore, we should migrate everything (Signing keys and stuff like) to Circle CI.
• We have to fix some real issues like java.lang.ArrayIndexOutOfBoundsException size=1 offset=1 byteCount=1 #128 and error: incompatible types: Object cannot be converted to ... #123 but this is only possible after we have fixed the 2 points above first.

That is why 0.8.13 is the last "working" and "stable" release as it has been published in the good old maven days but it lacks some improvements that have been added since then

When will be release 1.0 be published?

Obviously we have to fix the points above first but then:

• Remove @ElementNameMatcher: @Bodo1981 (works at Tickaroo) did already some work on introducing a way to not have to annotate all subclasses in a hierarchy with @ElementNameMatcher but let the Annotation processor figure that out automatically. This adds a much better developer experience as Tickaroo has a lot of multiple data classes that inherit from one base class and every time you add new content you have to add or adjust ``@ElementNameMatcher` all over the place.

Therefore I would say this is the one missing feature that needs to be added to ship 1.0.

What comes after 1.0 or in other words what is not included in 1.0 release:

• Incremental annotation processing: @Bodo1981 already looked into this because it could increase build times BUT it also depends how the removal of @ElementNameMatcher is implemented actually. Also, at Tickaroo most of the model data classes annotated with TikXML (as far as I know) live in one gradle module. Therefore gradle will recompile the whole gradle module anyway independently of incremental or not incremental annotation processor and causing other depending gradle modules to recompile as well. Therefore in the context of Tickaroo incremental annotation processing doesn't have highest priority because it is not the bottleneck BUT of course we acknowledge that others would benefit from incremental annotation porcessing. So I think it makes sense to add support for incremental annotation processing, just not before 1.0 release.
• Better Kotlin support: TikXML started more than 5 years ago. Back then it has been designed for Java. Once Tickaroo started adopting Kotlin we basically added a quick workaround to TikXML that generates java wrappers under the hood to parse XML and set's the values on the real kotlin class. This is very memory inefficient as for a short period of time you will have 1 kotlin data object and 1 java object in memory representing actually the same piece of parsed xml. This causes gc to run more often as the java object can be garbage collected right after parsing (but TikXML is still much faster than other reflection based xml parsers out there, see benchmarks).
• Revisit AutoValue support: Autovalue is supported basically be the same workaround as kotlin support (having 2 copies in memory and copying fields from a java pojo to autovalue builder). Again, very memory inefficient but I would also like to challenge if support for AutoValue makes sense in the age of kotlin.
• Kotlin Multiplatform: No support for that planned right now (and it also looks that kotlinx serialization has no plans to add support for xml so there might be need for it) but if we would ever like to add support for Kotlin Multiplatform we would have to move away from Annotation Processing to Kotlin Compiler Plugin. This also should be taken into account while discussing incremental annotation processing.
• Increase parsing speed: There is still a lot way of how to improve parsing with smarter data structures like Tries that could speed up parsing further.

I can take care of Continious Deployment point above and migrate things to CircleCI. The goal is to be able to release SNAPSHOTS and RELEASES from CircleCI whenever we push something to master branch (like accepting a PR) without having to do release management by 1 of the Tickaroo employees who know about the signing credentials.

For the other points, however, we need your help as we can't do that alone (I certainly cannot dedicate way more time for this project than I did in the past as I personally don't have too much need for TikXML and I don't work for Tickaroo anymore and have a lot of other open source projects going on in addition to ... you know ... life 😄 ). Any contribution is very much welcome and I wanted to thank all contributors so far especially @iNoles and @WeaponMan !

[Bodo1981]

Hi @sockeqwe.

Thanks for the explanation.

I totally agree with you.
So to start i directly created a new branch "circleci" where i already set up a default circlci config with building and testing.
@sockeqwe It would be great if you can have a look at it and also implment the SNAPSHOT and RELEASE uploading part.

If this is working we can go on with the other stuff!

[iNoles]

Travis CI changed something on the build system that is affecting OpenJDK versions. This is why, you are getting "Expected feature release number in range of 9 to 14, but got: 8" error. They have different distribution one for Android is "trusty." This can be very pita for the java/android developers.

[sockeqwe]

Circle CI is running, building and deploying now. Releasing should work in the future automatically from master branch to oss sonatype.

https://circleci.com/gh/Tickaroo/tikxml/27

However, there is one artifact that is not published (gradle config looks ok though)

• converter-date-rfc3339 is missing https://oss.sonatype.org/content/repositories/snapshots/com/tickaroo/tikxml/converter-date-rfc3339/

Here is the PR to fix this:
#141

[iNoles]

There are somebody else is trying to do XML Support on top of the Kotlinx serialization. it only use platform libraries.

https://github.com/pdvrieze/xmlutil

TikXml + Okio 2 + Kotlinx serialization = powerful multiplatform libraries