Hello everyone, TL;DR: Implementation of Binding Specification V1 needs to be improved in a way that breaks the ability to load Fluorine-generated code in older containers.
Are there any objections to doing that? PROBLEM: Recent change in yangtools to properly support pattern constraints (YANGTOOLS-798) has highlighted a deficiency in Binding V1 implementation: the users of binding objects are exposed to details of how patterns are enforced. In order to properly insulate them from these details and to report the regular expression declared in the model, we need to capture two sets of strings -- see MDSAL-313. A trivial implementation of this ends up significantly bloating generated code from all of source, bytecode and run-time overhead perspective. This will hurt downstreams which are very sensitive to these overheads, most notably fd.io's honeycomb. PROPOSAL: I propose we explicitly break runtime compatibility of Fluorine-generated code with previous runtimes. This means that Binding classes generated by Fluorine codegen will fail to work unless they are coupled with Fluorine-or-later version of yang-binding.jar. BENEFITS: Technically this allows us to host a few common utility methods in yang-binding.jar and call them from generated code, significantly lowering the amount of duplicated strings and bytecode in generated classes. I have prototyped and tested this approach with models in mdsal/model/ietf, having implemented MDSAL-313 and a few obvious optimizations. The end result is jar file size change from 2224797 to 2118432 bytes -- a reduction of 106365 bytes or 4.8%. Given that jars are saving ~70% of class size, this amounts to ~341KiB reduction in class file size. Regards, Robert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
