From 7597353c19d9b3417aac176341c2aa33087290e1 Mon Sep 17 00:00:00 2001 From: Robert Varga Date: Mon, 13 Jul 2020 22:06:45 +0200 Subject: [PATCH] Clean up CodecDataObjectGenerator documentation We have a few typos and opportunities for cleanup. Change-Id: Ibb9f5804ccc05c1b58c51d0ba1ac03fbaef7b223 Signed-off-by: Robert Varga --- .../dom/codec/impl/CodecDataObjectGenerator.java | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/binding/mdsal-binding-dom-codec/src/main/java/org/opendaylight/mdsal/binding/dom/codec/impl/CodecDataObjectGenerator.java b/binding/mdsal-binding-dom-codec/src/main/java/org/opendaylight/mdsal/binding/dom/codec/impl/CodecDataObjectGenerator.java index b2eeedc4be..c965a087a9 100644 --- a/binding/mdsal-binding-dom-codec/src/main/java/org/opendaylight/mdsal/binding/dom/codec/impl/CodecDataObjectGenerator.java +++ b/binding/mdsal-binding-dom-codec/src/main/java/org/opendaylight/mdsal/binding/dom/codec/impl/CodecDataObjectGenerator.java @@ -109,8 +109,10 @@ import org.slf4j.LoggerFactory; * This strategy minimizes the bytecode footprint and follows the generally good idea of keeping common logic in a * single place in a maintainable form. The glue code is extremely light (~6 instructions), which is beneficial on both * sides of invocation: - * - generated method can readily be inlined into the caller - * - it forms a call site into which codeMember() can be inlined with VarHandle being constant + * * *

* The second point is important here, as it allows the invocation logic around VarHandle to completely disappear, @@ -131,12 +133,12 @@ import org.slf4j.LoggerFactory; *

* The sticky point here is the NodeContextSupplier, as it is a heap object which cannot normally be looked up from the * static context in which the static class initializer operates -- so we need perform some sort of a trick here. - * Eventhough ByteBuddy provides facilities for bridging references to type fields, those facilities operate on volatile - * fields -- hence they do not quite work for us. + * Even though ByteBuddy provides facilities for bridging references to type fields, those facilities operate on + * volatile fields -- hence they do not quite work for us. * *

* Another alternative, which we used in Javassist-generated DataObjectSerializers, is to muck with the static field - * using reflection -- which works, but requires redefinition of Field.modifiers, which is something Java 9 complains + * using reflection -- which works, but requires redefinition of Field.modifiers, which is something Java 9+ complains * about quite noisily. * *

@@ -151,7 +153,7 @@ import org.slf4j.LoggerFactory; * class loading operation. At this point the generator installs itself as the current generator for this thread via * {@link ClassGeneratorBridge#setup(CodecDataObjectGenerator)} and allows the class to be loaded. *

  • After the class has been loaded, but before the call returns, we will force the class to initialize, at which - * point the static invocations will be redirect to {@link #resolveNodeContextSupplier(String)} and + * point the static invocations will be redirected to {@link #resolveNodeContextSupplier(String)} and * {@link #resolveKey(String)} methods, thus initializing the fields to the intended constants.
  • *
  • Before returning from the class loading call, the generator will detach itself via * {@link ClassGeneratorBridge#tearDown(CodecDataObjectGenerator)}.
  • @@ -164,7 +166,7 @@ import org.slf4j.LoggerFactory; abstract class CodecDataObjectGenerator> implements ClassGenerator { // Not reusable definition: we can inline NodeContextSuppliers without a problem // FIXME: 6.0.0: wire this implementation, which requires that BindingRuntimeTypes provides information about types - // being genenerated from within a grouping + // being generated from within a grouping private static final class Fixed> extends CodecDataObjectGenerator implements NodeContextSupplierProvider { private final ImmutableMap properties; -- 2.36.6