On Thu, Mar 1, 2018 at 6:31 PM, Robert Varga <n...@hq.sk> wrote: > 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. >
I don't think that's really a problem, so fine by me... > 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 > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
