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

Reply via email to