🚲 🏇🏾 ⬛️ संकलन के दौरान एनोटेशन का संकलन ☺️ 💛 🎧

मेटाप्रोग्रामिंग एक प्रकार की प्रोग्रामिंग है, जो प्रोग्राम्स के निर्माण से जुड़ी होती है, जो उनके काम के परिणामस्वरूप अन्य प्रोग्राम उत्पन्न करते हैं (विशेष रूप से, उनके सोर्स कोड के संकलन चरण में), या ऐसे प्रोग्राम जो खुद को रनटाइम में बदलते हैं।

2004 में जावा 5 के रिलीज के साथ एक मेटाप्रोग्रामिंग टूल के रूप में एनोटेशन दिखाई दिए। उनके साथ, एनोटेशन प्रोसेसिंग टूल दिखाई दिया , जिसे जेएसआर 269 विनिर्देश या प्लग करने योग्य एनोटेशन प्रोसेसिंग एपीआई द्वारा प्रतिस्थापित किया गया था। दिलचस्प बात यह है कि यह विनिर्देश लगभग 10 साल पुराना है, लेकिन यह केवल एंड्रॉइड विकास में अपनी लोकप्रियता हासिल करना शुरू कर दिया।

हम उन संभावनाओं के बारे में बात करेंगे कि यह विनिर्देश थोड़ी देर बाद खुलता है (बहुत कोड होगा), लेकिन पहले, क्या आप जावा कोड को संकलित करने के बारे में बात करना चाहेंगे?

जावाक के बारे में कुछ शब्द

संपूर्ण संकलन प्रक्रिया को com.sun.tools.javac पैकेज के टूल द्वारा नियंत्रित किया जाता है और, OpenJDK विनिर्देशों के अनुसार, सामान्य रूप से, यह इस तरह दिखता है:

पार्स - संकलक इनपुट स्ट्रीम को टोकन के क्रम में रखता है और com.sun.tools.javac.parser पैकेज से उपकरणों का उपयोग करके एक सार वाक्यविन्यास ट्री (एएसटी) बनाता है । *
दर्ज करें - इस स्तर पर, वाक्यविन्यास पेड़ के माध्यम से एक पास किया जाता है और एक प्रतीक तालिका बनाई जाती है। यह ध्यान देने योग्य है कि इस प्रक्रिया में दो चरण होते हैं: पार्स चरण से एएसटी के माध्यम से पहले पास पर, दूसरे पर सभी निर्भरता (इंटरफेस, सुपर प्रकार, पैरामीटर) के माध्यम से।
एनोटेशन प्रोसेसिंग - यह चरण, वास्तव में, बाद में चर्चा की जाएगी।
विशेषता - इस चरण के दौरान अधिकांश संदर्भ-संवेदनशील ऑपरेशन किए जाते हैं: नाम रिज़ॉल्यूशन, टाइप चेकिंग, निरंतर गणना।
प्रवाह - इस स्तर पर, डेटा प्रवाह की जाँच की जाती है, कोड के सभी वर्गों की पुनरावृत्ति, कि सभी पकड़े गए अपवाद संसाधित होते हैं, अंतिम चर एक बार सेट किए जाते हैं, आदि।
देसुगर - सिंटैक्टिक शुगर को हटाने, आंतरिक कक्षाओं की जगह, फॉरेक्स लूप को तैनात करना।
उत्पन्न - उत्पन्न .class फ़ाइलें

Android मेटाप्रोग्रामिंग

एंड्रॉइड डेवलपमेंट में मेटाप्रोग्रामिंग हमें कहां मदद कर सकता है? आप में से बहुत से लोग इस प्रश्न का उत्तर पहले से ही जानते हैं - यह पुस्तकालयों की एक पर्याप्त संख्या है जो किसी तरह घटकों को इंजेक्शन लगाने, श्रोताओं को स्थापित करने, और बहुत कुछ प्रदान करते हैं।

public class MainActivity extends AppCompatActivity { @Bind(R.id.fab) private FloatingActionButton mFab; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.ac_main); mFab.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { } }); ButterKnife.bind(this); } }

इस कोड में क्या समस्याएं हैं? सबसे पहले, वह एक साथ नहीं मिलेगा! संकलन प्रक्रिया एक त्रुटि से बाधित होगी

 Error:(15, 34) error: @Bind fields must not be private or static. (moscow.droidcon2015.activity.MainActivity.mFab)

महान, निजी निकालें और वह, कोड संकलित है। लेकिन, इसके अलावा, हम OOP के मूल सिद्धांतों में से एक का उल्लंघन करते हैं - इनकैप्सुलेशन । दूसरे, स्टार्टअप पर, एप्लिकेशन एनपीई के साथ दुर्घटनाग्रस्त हो जाएगा, क्योंकि एमफैब क्षेत्र को इनिशियलाइज़ किया जाता है जब बटरकाइनी.बाइंड (यह) कहा जाता है। तीसरा, प्रोगार्ड बटरकनीफ लाइब्रेरी द्वारा उत्पन्न वर्गों में कटौती कर सकता है। आप कह सकते हैं कि ये सभी दूर की समस्याएँ हैं और ये सभी पाँच मिनट में हल हो जाती हैं। बेशक, यह सच है, लेकिन इन संभावित समस्याओं के बारे में सोचने की जरूरत से खुद को दूर करना बहुत अच्छा होगा।

आगे बढ़ो! भारी पदार्थों के लिए!

तो, चलो पहिया को फिर से शुरू करना शुरू करें! पहली चीज जिसकी हमें आवश्यकता है, विचित्र रूप से पर्याप्त है, वह एनोटेशन ही है, जिसे हम बाद में प्रोसेस करेंगे:

 @Retention(RetentionPolicy.SOURCE) @Target({ElementType.FIELD}) public @interface BindView { int value(); }

RetentionPolicy.SOURCE का अर्थ है कि यह एनोटेशन केवल स्रोत कोड (जो हमें पूरी तरह से सूट करता है) में उपलब्ध है और आप इसे प्रतिबिंब के माध्यम तक नहीं पहुंचा पाएंगे। ElementType.FIELD का कहना है कि एनोटेशन केवल वर्ग के क्षेत्रों पर लागू होता है।

अगला, हमें स्वयं प्रोसेसर बनाने और इसे एक विशेष फ़ाइल में पंजीकृत करने की आवश्यकता है:

 src/main/resources/META-INF.services/javax.annotation.processing.Processor

इस फ़ाइल की सामग्री एक एकल पंक्ति है जिसमें कनेक्टेड प्रोसेसर के पूरी तरह से योग्य वर्ग का नाम है:

 moscow.droidcon2015.processor.DroidConProcessor

DroidConProcessor.java

 @SupportedAnnotationTypes({"moscow.droidcon2015.processor.BindView"}) public class DroidConProcessor extends AbstractProcessor { private final Map<TypeElement, BindViewVisitor> mVisitors = new HashMap<>(); @Override public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) { if (annotations.isEmpty()) { return false; } final Set<? extends Element> elements = roundEnv.getElementsAnnotatedWith(BindView.class); for (final Element element : elements) { // element == MainActivity.mFab final TypeElement object = (TypeElement) element.getEnclosingElement(); // object == MainActivity BindViewVisitor visitor = mVisitors.get(object); if (visitor == null) { visitor = new BindViewVisitor(processingEnv, object); mVisitors.put(object, visitor); } element.accept(visitor, null); } for (final BindViewVisitor visitor : mVisitors.values()) { visitor.brewJava(); } return true; } @Override public SourceVersion getSupportedSourceVersion() { return SourceVersion.latestSupported(); } }

विरोधाभास जैसा कि यह लग सकता है, हम प्रोसेसर को एक एनोटेशन के साथ चिह्नित करते हैं, जो इंगित करता है कि प्रोसेसर किस एनोटेशन को संसाधित कर सकता है। यह अनुमान लगाना कठिन नहीं है कि मुख्य विधि प्रक्रिया विधि है। पहला पैरामीटर हमारे प्रोसेसर द्वारा समर्थित सूची से बहुत सारे एनोटेशन हैं, जिन्हें संकलन के पहले दो चरणों में खोजा गया था। दूसरा पैरामीटर संकलक वातावरण है। एक अच्छे तरीके से, विधि के कार्यान्वयन में, हमें एनोटेशन के पूरे सेट के माध्यम से जाना होगा और उन सभी को संसाधित करना होगा, लेकिन इस मामले में, प्रोसेसर केवल एक ही एनोटेशन का समर्थन करता है, इसलिए हम इसे "माथे" संसाधित करेंगे। चरणों में प्रक्रिया विधि पर विचार करें:

हम सत्यापित करते हैं कि कम से कम समर्थित का एक एनोटेशन
हम पर्यावरण से @BindView एनोटेशन के साथ चिह्नित सभी तत्वों का एक बहुत कुछ प्राप्त करते हैं
हम इस सेट से गुजरते हैं। जैसा कि हम याद करते हैं, एनोटेशन को केवल कक्षा के क्षेत्र पर लागू किया जा सकता है, क्रमशः element.getEnclosingElement () विधि उस वर्ग के ऑब्जेक्ट को वापस कर देगी जिसमें फ़ील्ड निहित है।
चिह्नित फ़ील्ड वाले प्रत्येक ऑब्जेक्ट के लिए एक विज़िटर वर्ग बनाएं
हमारे आगंतुक को प्रत्येक क्षेत्र में लागू करें।
सभी आगंतुकों के काम करने के बाद, हम स्रोत कोड की अंतिम कक्षाओं को उत्पन्न करते हैं।

BindViewVisitor.java

 public class BindViewVisitor extends ElementScanner7<Void, Void> { private final CodeBlock.Builder mFindViewById = CodeBlock.builder(); private final Trees mTrees; private final Messager mLogger; private final Filer mFiler; private final TypeElement mOriginElement; private final TreeMaker mTreeMaker; private final Names mNames; public BindViewVisitor(ProcessingEnvironment env, TypeElement element) { super(); mTrees = Trees.instance(env); mLogger = env.getMessager(); mFiler = env.getFiler(); mOriginElement = element; final JavacProcessingEnvironment javacEnv = (JavacProcessingEnvironment) env; mTreeMaker = TreeMaker.instance(javacEnv.getContext()); mNames = Names.instance(javacEnv.getContext()); } }

अब आइए उस वर्ग को देखें जिसमें सभी मुख्य कार्य किए जाते हैं। पहली बात यह है कि आंखों की लटें एलीमेंटसेनर 7 हैं । यह ElementVisitor इंटरफ़ेस का कार्यान्वयन है, और 7 उस JDK का न्यूनतम संस्करण है जिसका हम उपयोग करना चाहते हैं। आइए खेतों के माध्यम से जाएं (उनके प्रकारों से अधिक सटीक):

CodeBlock.Builder स्क्वायर से लोगों के जेवपोत पुस्तकालय का हिस्सा है, जो कोड पीढ़ी को सरल बनाने के लिए बनाया गया था।
पेड़ com.sun.source.util पैकेज से एक वर्ग है जो एएसटी तक पहुंच की अनुमति देता है।
मेसेंजर एक लकड़हारा है। यदि आप प्राथमिकता ERROR के साथ संदेश भेजते हैं तो आप संकलन के दौरान संदेश दिखा सकते हैं या प्रक्रिया को बाधित कर सकते हैं।
फाइलर - एक वर्ग जो आपको वर्तमान संकलक सैंडबॉक्स में स्रोत कोड फ़ाइलों को बनाने की अनुमति देता है। वह जानता है कि फाइल को फाइल सिस्टम में कहां रखा जाए। उदाहरण के लिए, ग्रेडेल के लिए, यह बिल्ड / इंटरमीडिएट / कक्षाएं हैं।
ट्रीमेकर com.sun.tools.javac.tree पैकेज से एक वर्ग है जो आगे होने वाले सभी जादू के लिए बिल्कुल जिम्मेदार है! एएसटी के निर्माण के लिए संकलन के पहले चरण में भी इसका उपयोग किया जाता है।
नाम com.sun.tools.javac.util पैकेज से एक वर्ग है जो एएसटी निर्माण में तत्व नामों का अनुवाद करता है।

जैसा कि आपको याद है, हमने क्लास फील्ड में एलिमेंटविज़िटर लागू किया, इसलिए वह विधि जो हमें रुचती है

visitVariable

  @Override public Void visitVariable(VariableElement field, Void aVoid) { ((JCTree) mTrees.getTree(field)).accept(new TreeTranslator() { @Override public void visitVarDef(JCTree.JCVariableDecl jcVariableDecl) { super.visitVarDef(jcVariableDecl); jcVariableDecl.mods.flags &= ~Flags.PRIVATE; } }); final BindView bindView = field.getAnnotation(BindView.class); mFindViewById.addStatement("(($T) this).$L = ($T) findViewById($L)", ClassName.get(mOriginElement), field.getSimpleName(), ClassName.get(field.asType()), bindView.value()); return super.visitVariable(field, aVoid); }

आगे क्या होगा यह समझने के लिए एक छोटा विषयांतर: javax.lang.model.element (VariableElement, TypeElement, आदि) से कक्षाएं हैं, चलो कहते हैं, एएसटी पर एक उच्च-स्तरीय अमूर्तता। ट्रीज़ क्लास का उपयोग करते हुए, हम एक निम्न-स्तरीय अमूर्तता प्राप्त करते हैं, उस पर ट्री-विजिटर कार्यान्वयन निर्धारित करते हैं, और विजिटवर्फ पद्धति में मिलते हैं, जिसके मापदंडों में हमारे क्षेत्र का एएसटी प्रतिनिधित्व ( JCTree.JCVariableDl ) शामिल है। फिर गंदे हैक - हम निजी झंडे को मैदान से हटा देते हैं। हां, हां, हम एनकैप्सुलेशन के सिद्धांत का उल्लंघन करते हैं, लेकिन हम इसे कंपाइलर स्तर पर करते हैं (जहां हम पहले से ही, सिद्धांत रूप में, बग़ल में क्या होता है)। स्रोत कोड स्तर पर एनकैप्सुलेशन को संरक्षित किया गया है: आईडीई आपको बाहर से क्षेत्र का उपयोग करने की अनुमति नहीं देगा, और स्थैतिक विश्लेषक शांति से रिपोर्ट करेंगे कि इस क्षेत्र के साथ कोई समस्या नहीं है। फ़ील्ड प्रारंभ करने के लिए CodeBlock.Builder में एक अभिव्यक्ति जोड़ें और यह बात है।

स्रोत कोड फ़ाइल जनरेट करें

हमने अपनी कक्षा के सभी क्षेत्रों का दौरा करने के बाद, स्रोत कोड फ़ाइल उत्पन्न करना आवश्यक है।

brewJava

  public void brewJava() { final TypeSpec typeSpec = TypeSpec.classBuilder(mOriginElement.getSimpleName() + "$$Proxy") // MainActivity$$Proxy .addModifiers(Modifier.ABSTRACT) .superclass(ClassName.get(mOriginElement.getSuperclass())) // extends AppCompatActivity .addOriginatingElement(mOriginElement) .addMethod(MethodSpec.methodBuilder("setContentView") .addAnnotation(Override.class) .addModifiers(Modifier.PUBLIC) .addParameter(TypeName.INT, "layoutResId") .addStatement("super.setContentView(layoutResId)") .addCode(mFindViewById.build()) // findViewById... .build()) .build(); final JavaFile javaFile = JavaFile.builder(mOriginElement.getEnclosingElement().toString(), typeSpec) .addFileComment("Generated by DroidCon processor, do not modify") .build(); try { final JavaFileObject sourceFile = mFiler.createSourceFile( javaFile.packageName + "." + typeSpec.name, mOriginElement); try (final Writer writer = new BufferedWriter(sourceFile.openWriter())) { javaFile.writeTo(writer); } // TODO: MAGIC } catch (IOException e) { mLogger.printMessage(Diagnostic.Kind.ERROR, e.getMessage(), mOriginElement); } }

स्रोत कोड जनरेट करने का सारा काम javapoet लाइब्रेरी ने लिया। बेशक, कोई भी इसके बिना कर सकता था, लेकिन तब पूरे स्रोत कोड को मैन्युअल रूप से स्ट्रिंग कॉन्फैनेटेशन का उपयोग करके उत्पन्न करना होगा, जो कि आप देखते हैं, बहुत सुविधाजनक नहीं है। इस बिंदु पर, बटरकनीफ़ जैसे पुस्तकालयों के सभी निर्माता खत्म हो जाते हैं । हमें एक क्लास फाइल मिली, जिसे हम फिर रिफ्लेक्शन की मदद से ढूंढते हैं और इसकी मदद से हम संबंधित विधि को खींचते हैं, जो उपयोगी काम करता है। लेकिन मैंने वादा किया कि हम इस ज़रूरत से छुटकारा पा लेंगे!

हमें और गहरे जाने की जरूरत है!

TODO: जादू

 JCTree.JCExpression selector = mTreeMaker.Ident(mNames.fromString(javaFile.packageName)); selector = mTreeMaker.Select(selector, mNames.fromString(typeSpec.name)); ((JCTree.JCClassDecl) mTrees.getTree(mOriginElement)).extending = selector;

हाँ! तीन लाइनें। उनमें क्या होता है:

एएसटी नोड्स में से एक चुनें। हमारे मामले में, पैकेज जिसमें उत्पन्न वर्ग निहित है।
हम पेड़ में गहराई तक जाते हैं और अगले नोड - स्वयं उत्पन्न वर्ग का चयन करते हैं।
स्रोत तत्व (MainActivity) में हम फैली हुई संपत्ति को बदलते हैं, जो वास्तव में, इसका मतलब है कि इस वर्ग को क्या विरासत में मिला है।

एक और भी सरल भाषा में - हम उत्पन्न वर्ग को वंशानुगत पदानुक्रम में एम्बेड करते हैं:

 MainActivity extends MainActivity$$Proxy extends AppCompatActivity

MainActivity $$ Proxy.java

 // Generated by DroidCon processor, do not modify package moscow.droidcon2015.activity; import android.support.design.widget.FloatingActionButton; import android.support.v7.app.AppCompatActivity; import java.lang.Override; abstract class MainActivity$$Proxy extends AppCompatActivity { @Override public void setContentView(int layoutResId) { super.setContentView(layoutResId); ((MainActivity) this).mFab = (FloatingActionButton) findViewById(2131492965); } }

MainActivity.class (विघटित)

 // // Source code recreated from a .class file by IntelliJ IDEA // (powered by Fernflower decompiler) // package moscow.droidcon2015.activity; import android.os.Bundle; import android.support.design.widget.FloatingActionButton; import android.view.View; import android.view.View.OnClickListener; import moscow.droidcon2015.activity.MainActivity$$Proxy; public class MainActivity extends MainActivity$$Proxy { FloatingActionButton mFab; public MainActivity() { } protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); this.setContentView(2130968600); this.mFab.setOnClickListener(new OnClickListener() { public void onClick(View v) { } }); } }

निष्कर्ष

दुर्भाग्य से, एक लेख के ढांचे के भीतर एनोटेशन प्रोसेसिंग की सभी पेचीदगियों और com.sun.tools.javac के अंदर झूठ बोलने वाले खजाने के बारे में बताना असंभव है । * । इससे भी अधिक परेशान करने वाली बात यह है कि इन खजाने पर किसी भी दस्तावेज की पूरी कमी है और रिलीज के बीच संगतता की कमी है। इसके बाद, डरावने शब्दों को सुना जाएगा: java7 और java8 संकलक के लिए समर्थन प्रदान करने के लिए, संकलन प्रक्रिया में प्रतिबिंब का उपयोग करना आवश्यक होगा! इससे एक ट्विस्ट है! सच? लेकिन एक बार फिर, यह केवल com.sun.tools.javac पर लागू होता है।

DroidCon पर आधारित है

प्रस्तुति के माध्यम से फ़्लिप करते हुए लेख को पढ़ना अधिक सुविधाजनक है।
यहां प्रोजेक्ट रिपोजिटरी।

सवालों के जवाब:

यह कोई शोध कार्य नहीं है। यह सब पहले से ही कई परियोजनाओं में सक्रिय रूप से काम कर रहा है।
ASM जैसे पुस्तकालयों द्वारा मॉडिफाइड बायोटेक पर इस दृष्टिकोण का लाभ यह है कि एनोटेशन को संकलन के समय संसाधित किया जाता है और इसके बाद नहीं, और रनटाइम के बजाय संकलन त्रुटि को पकड़ने की क्षमता, मेरी राय में, बहुत बेहतर है।
आप इसे DroidKit लाइब्रेरी में देख सकते हैं। andkulikov , प्रलेखन निस्संदेह दिखाई देगा। कब? कब किया जाता है =)

अधिक कट्टर!

visitMethodDef

 @Override public void visitMethodDef(JCTree.JCMethodDecl methodDecl) { super.visitMethodDef(methodDecl); methodDecl.body.stats = com.sun.tools.javac.util.List.<JCTree.JCStatement>of( mTreeMaker.Try( mTreeMaker.Block(0, methodDecl.body.stats), com.sun.tools.javac.util.List.<JCTree.JCCatch>nil(), mTreeMaker.Block(0, com.sun.tools.javac.util.List.<JCTree.JCStatement>of( mTreeMaker.Exec(mTreeMaker.Apply( com.sun.tools.javac.util.List.<JCTree.JCExpression>nil(), ident(mPackageName, mHelperClassName, "update"), com.sun.tools.javac.util.List.of( mTreeMaker.Literal(TypeTag.CLASS, mColumnName), mTreeMaker.Select(mTreeMaker.Ident(mNames._this), mNames.fromString(mFieldName)), mTreeMaker.Select(mTreeMaker.Ident(mNames._this), mNames.fromString(mPrimaryKey.call())) ) )) )) ) ); }

यहां पहली नज़र में ऐसा भयानक कोड है, यह केवल सेटर विधि के कोड को संशोधित करता है ताकि डेटाबेस में तुरंत परिवर्तन लिखा जाए।

पतलून आसानी से बारी ...

 //  public void setText(String text) { mText = text; } //  public void setText(String text) { try { this.mText = text; } finally { Foo$$SQLiteHelper.update("text", this.mText, this.mId); } }

संकलन के दौरान एनोटेशन का संकलन