आगे संगत जावा 6 एनोटेशन प्रोसेसर और SupportedSourceVersion

Question

मैं एक परियोजना के लिए जावा 7 बाहर कोशिश कर रहा हूँ और इस तरह की टिप्पणी के प्रोसेसर से चेतावनी (Bindgen और हाइबरनेट जेपीए modelgen) हो रही है:

warning: Supported source version 'RELEASE_6' from annotation processor 'org.hibernate.jpamodelgen.JPAMetaModelEntityProcessor' less than -source '1.7' 

यह @SupportedSourceVersion(SourceVersion.RELEASE_6) के कारण होता है एनोटेशन प्रोसेसर कक्षाओं पर एनोटेशन। चूंकि वे जावा 6 के साथ संकलित हैं, उनके लिए उपलब्ध SourceVersion का उच्चतम मूल्य RELEASE_6 है। SourceVersion का जावा 7 संस्करण RELEASE_7 प्रस्तुत करता है।

मेरे प्रश्न: एनोटेशन प्रोसेसर को आगे संगतता को संभालने के लिए कैसे माना जाता है? क्या उनमें से अलग jdk6 और jdk7 बाइनरी संस्करण होना चाहिए? क्या मैं यहाँ कुछ और समझ नहीं रहा हूँ?

Querdydsl bug report जो

@Override 
public SourceVersion getSupportedSourceVersion() { 
    return SourceVersion.latest(); 
} 

Oracle blog इस्तेमाल किया, जिसमें एक commentor समर्थन की सिफारिश नवीनतम स्रोत संस्करण

Answer 1

आगे संगतता प्रसंस्करण अज्ञात भाषा द्वारा नियंत्रित किया जाता है:

मैं केवल इस चिंता के बारे में निम्नलिखित जानकारी मिली उचित रूप से निर्माण करता है, उदाहरण के लिए ElementVisitor.visitUnknown लागू करके।

उल्लेख Oracle blog में कोई अन्य प्रविष्टि है, जो आगे संगतता के बारे में दो नीतियों का सुझाव है:

• वर्तमान भाषा संस्करण के साथ ही काम करने के लिए प्रोसेसर लिखें।
• अज्ञात भविष्य संरचनाओं का सामना करने के लिए प्रोसेसर लिखें।

दूसरा एक SourceVersion.latest() के रूप में पहले से ही विचाराधीन तैनात लौटने द्वारा किया जाता है।

मुझे लगता है कि ज्यादातर मामलों में ऐसा करना ठीक है, जब आप सुनिश्चित हैं कि अतिरिक्त भाषा तत्व कुछ भी नहीं तोड़ेंगे। बेशक आपको यह नहीं मानना ​​चाहिए कि नए संस्करणों के साथ भी सब ठीक हो जाएगा, आपको इसका भी परीक्षण करना चाहिए।

---

ठीक है, मैं प्रसंस्करण अज्ञात भाषा उचित रूप से निर्माण करती अस्पष्ट थोड़ा लगता है लगता है, इसलिए यहाँ कुछ उदाहरण हैं।

मान लीजिए कि आपके पास एक प्रोसेसर है जो ज्ञात भाषा संरचनाओं (उदाहरण के लिए कक्षा पर एनोटेशन) पर एक कस्टम प्रकार की टिप्पणियों की जांच करता है और जो पाया गया है उसका एक सरल दस्तावेज बनाता है। आप शायद यह मानने के लिए सुरक्षित हैं कि यह नए संस्करणों में भी काम करेगा। इसे किसी विशेष संस्करण में प्रतिबंधित करना मेरी राय में एक अच्छा निर्णय नहीं होगा।

मान लीजिए कि आपके पास एक प्रोसेसर है जो प्रत्येक तत्व को जांचता है और इसे ग्राफ़ उत्पन्न करने के लिए कोड संरचना का विश्लेषण करता है। आपको नए संस्करणों में समस्याएं हो सकती हैं। आप किसी भी तरह अज्ञात भाषा संरचनाओं को संभालने में सक्षम हो सकते हैं (जैसे ग्राफ में अज्ञात नोड जोड़कर) लेकिन अगर यह समझ में आता है तो केवल ऐसा करें - और यदि यह समस्या के लायक है।अगर किसी अज्ञात के साथ सामना करते समय प्रोसेसर अब और उपयोगी नहीं होगा, तो शायद यह किसी विशेष जावा संस्करण से चिपकना चाहिए।

नीति का उपयोग किए बिना, मेरी राय में सबसे अच्छा तरीका भाषा में आगामी परिवर्तनों की निगरानी करना और उसके अनुसार प्रोसेसर को अपडेट करना होगा। उदाहरण के लिए जावा 7 में, project coin ने कुछ नई भाषा विशेषताओं को पेश किया, जो प्रोसेसर को भी दिखाई नहीं दे सकते हैं। दूसरी तरफ जावा 8 में नई संरचनाएं हैं जो प्रसंस्करण को प्रभावित करती हैं, उदाहरण के लिए type annotations। नई भाषा विशेषताएं अक्सर नहीं होती हैं, इसलिए संभावना है कि आपको लंबे समय तक कुछ भी बदलने की आवश्यकता नहीं है।