इनलाइन टैगलेट (जिसे com.sun की आवश्यकता है) को और अधिक क्रॉस-प्लेटफ़ॉर्म कैसे बनाएं? क्या कोई गैर-ओरेकल/अधिक-क्रॉस-प्लेटफार्म जावाडोक पार्सर है?

Question

मैं a library लिख रहा हूं जो पहले से ही यूनिट-परीक्षण उदाहरण कोड (इसका स्रोत-कोड, आउटपुट, और कोई भी इनपुट फाइल) जावाडोक में, कई अनुकूलन संभावनाओं के साथ सम्मिलित करता है। इस पुस्तकालय का उपयोग करने का मुख्य तरीका यह मतलब है कि वे लगभग जावा ही पार मंच के रूप में नहीं कर रहे हैं इनलाइन taglets साथ है, such as

{@.codelet.and.out my.package.AGreatExample} 
{@.codelet my.package.AGreatExample} 
{@.file.textlet examples\doc-files\an_input_file.txt} 
{@.codelet.and.out my.package.AGreatExample%eliminateCommentBlocksAndPackageDecl()} 

कस्टम taglets (और यहां तक ​​doclets) के बाद से com.sun की आवश्यकता है। (यह सुनिश्चित नहीं है कि यह प्रासंगिक है, लेकिन "javadoc" शब्द और यहां तक ​​कि सबस्ट्रिंग "डॉक्टर" - Java 8 Language Specifications में नहीं है।)

मुझे उस लाइब्रेरी को लिखने का विचार पसंद नहीं है जो सीमित है इस तरफ। तो मैं क्या करूं? मेरे विचार अब तक कि

• आदेश मौजूदा जावाडोक पार्सर का लाभ लेने के लिए, मैं com.sun taglets साथ रहना है। हालांकि, मैं इस निर्भरता को com.sun पर "पतली" के रूप में बना सकता हूं। यही है, मैंने टैगलेट क्लास में जितना संभव हो उतना कोड डाला, जिससे कहीं और कोड को छोड़ दिया गया, जहां com.sun पर कोई निर्भरता नहीं है।
• मैं अपना खुद का पार्सर बनाने की दिशा में काम करता हूं, जो केवल मेरे विशिष्ट टैगलेट की खोज करता है। यह एक दर्द है, लेकिन बहुत भयानक नहीं है। आप प्रत्येक जावा स्रोत फ़ाइल की लाइनों के माध्यम से पुन: प्रयास करते हैं, \{@\.myTagletName (.*?)\} खोज रहे हैं। एक बार जब आप उस पाठ को कैप्चर कर लेते हैं, तो यह com.sun टैगलेट के भीतर कोड के समान ही है।
• इस पार्सर को जावाडोक निष्पादित करने से पहले चलाया जाना होगा, और इसलिए डुप्लिकेट निर्देशिका संरचना की आवश्यकता होगी। (1) अनारक्षित कस्टम टैग के साथ, आपका मूल कोड, (2) उस कोड का डुप्लिकेट, पार्स-आउटपुट के साथ। मैं डुप्लिकेट निर्देशिका में सभी कोड कॉपी करूंगा, और उसके बाद केवल उन जावा फ़ाइलों को पार्स करें जिन्हें ये टैगलेट (क्लास जो "पंजीकृत" हैं, पार्सर के साथ किसी भी तरीके से) हैं।

क्या यह एक उचित दृष्टिकोण है? क्या वहां पहले से कहीं अधिक क्रॉस-प्लेटफार्म जावाडोक/टैगलेट पार्सर है, इसलिए मुझे अपना खुद का रोल नहीं करना है? क्या क्रॉस-प्लेटफ़ॉर्म कुछ भी है जो टैगलेट- पहले से बाहर है? क्या JavaDoc स्वयं क्रॉस प्लेटफ़ॉर्म नहीं है, या केवल कस्टम टैगलेट और दस्तावेज़ हैं?

मुझे इस फैसले (इनलाइन टैगलेट का उपयोग करने के लिए) के कारण मैं अपनी लाइब्रेरी से कितने लोगों को लॉक कर रहा हूं, इस पर कोई मोटा परिप्रेक्ष्य नहीं चाहता हूं, लेकिन ज्यादातर मैं एक दीर्घकालिक समाधान की तलाश में हूं।

taglet सुझाव के लिए @fge को

---

क्रेडिट, जो मेरे original idea की तुलना में अधिक सुंदर है, और के लिए @Michael को (मेरे जावा 8 ऊपर दिए लिंक पर मैं जावा 7. उपयोग कर रहा हूँ के बावजूद) अशुभ-लेकिन-सहायक com.sun चेतावनियां।

Answer 1

पहले, ध्यान दें कि sun.* और com.sun.* निर्भरताओं के बीच कोई अंतर है। sun.* नामस्थान में कक्षाएं हैं जो ओरेकल की जावा वर्चुअल मशीन को लागू करती हैं। आप should not use such dependencies क्योंकि ओरेकल जेवीएम की आंतरिक एपीआई भविष्य की रिलीज में बदल सकती है और क्योंकि यह नामस्थान अन्य, गैर-ओरेकल जेवीएम कार्यान्वयन द्वारा प्रदान नहीं किया जा सकता है।(व्यवहार में, और अधिक व्यापक रूप से इस्तेमाल sun.* वर्गों के ships with one भी Android's JVM।)

तो फिर वहाँ com.sun.* नाम स्थान है जो अपनी Java अनुप्रयोगों लागू करने के लिए Sun Microsystems द्वारा इस्तेमाल किया गया था। com.sun.* निर्भरताओं के कानूनी उपयोग के लिए एक उदाहरण सूर्य की जर्सी ढांचा है जो originally deployedcom.sun.jersey.* नामस्थान में था। (पूर्णता के लिए, ध्यान दें कि हालिया जर्सी संस्करण are deployedorg.glassfish.jersey.* में संस्करण 2.0 के साथ शुरू होने वाले नामस्थान जो कि जर्सी 1 एपीआई के साथ असंगत है।) आगे के संदर्भ के लिए, ध्यान दें कि ओरेकल com.sun.* नेमस्पेस when discussing समस्याओं का भी उल्लेख नहीं करता है sun.* नामस्थान का उपयोग करके लगाया गया। इसके अलावा, स्टैक ओवरफ़्लो पर this related question देखें।

इसलिए, com.sun.* निर्भरताओं का उपयोग sun.* निर्भरताओं की तुलना में एक अलग सौदा है। com.sun.* कक्षाओं का उपयोग करके, आप अपने आप को विशिष्ट लाइब्रेरी के एपीआई में लॉक करते हैं, न कि विशिष्ट जेवीएम के लिए। उदाहरण के लिए, आप मानकीकृत JAX-RSjavax.ws.rs.* नामस्थान का उपयोग करके com.sun.jersey.* नामस्थान के प्रत्यक्ष उपयोग से बच सकते हैं। इस अर्थ में, com.sun.* निर्भरता उत्पाद विशिष्ट और मालिकाना हैं और जावा के मानकीकृत एपीआई के साथ भ्रमित नहीं होना चाहिए जो आम तौर पर javax.* नामस्थान में पाए जाते हैं।

यदि मैं आप थे, तो मैं टैगलेट के साथ रहूंगा जो एक परिपक्व और मान्यता प्राप्त कार्यान्वयन है। ओरेकल not to break APIs बहुत दृढ़ संकल्पित है (अन्यथा, वे शायद टैगलेट को com.oracle.* पर भी ले जाएंगे) और मुझे कोई कारण नहीं दिखता कि वे अचानक टैगलेट पैकेज संरचना को क्यों बदल देंगे। और अगर वे चाहते हैं, तो आपको केवल अपने तकनीक को अपडेट करने की आवश्यकता है। यदि आपका एप्लिकेशन एक नई जावा रिलीज के लिए टूट जाता है, तो आपके उपयोगकर्ता आपके सॉफ़्टवेयर के अपडेट की तलाश करेंगे। चूंकि आप टैगलेट प्रोजेक्ट नहीं चलाते हैं, इसलिए मैं आपसे सहमत हूं कि एक विदेशी एपीआई से अपने तर्क को अलग करना सामान्य रूप से एक अच्छा विचार है क्योंकि यह किसी भी निर्भरता के लिए है। साथ ही, आपके उपयोग के मामले में टैगलेट का उपयोग करके KISS और DRY सिद्धांतों को बहुत अधिक पहचानता है।