Java.util.logging का उपयोग क्यों नहीं करें?




slf4j logback (4)

मेरे जीवन में पहली बार मैं खुद को ऐसी स्थिति में ढूंढता हूं जहां मैं एक जावा एपीआई लिख रहा हूं जो खुलेगा। उम्मीद है कि कई अन्य परियोजनाओं में शामिल किया जाएगा।

लॉगिंग के लिए मैं (और वास्तव में जिन लोगों के साथ काम करता हूं) ने हमेशा JUL (java.util.logging) का उपयोग किया है और इसके साथ कभी भी कोई समस्या नहीं है। हालांकि अब मुझे और विस्तार से समझने की जरूरत है कि मुझे अपने एपीआई विकास के लिए क्या करना चाहिए। मैंने इस पर कुछ शोध किया है और मुझे मिली जानकारी के साथ मैं और अधिक उलझन में हूं। इसलिए यह पोस्ट।

चूंकि मैं जूल से आया हूं, मैं उस पर पक्षपात कर रहा हूं। बाकी का मेरा ज्ञान इतना बड़ा नहीं है।

मैंने जो शोध किया है, उससे मैंने इन कारणों से बात की है कि लोग जूल पसंद क्यों नहीं करते हैं:

  1. "सूर्य ने जेयूएल जारी करने से पहले जावा में विकास करना शुरू कर दिया था और कुछ नया सीखने के बजाय लॉगिंग-फ्रेमवर्क-एक्स के साथ जारी रखना मेरे लिए आसान था" हम्म। मैं मजाक नहीं कर रहा हूं, वास्तव में लोग क्या कहते हैं। इस तर्क के साथ हम सभी कोबोल कर सकते हैं। (हालांकि मैं निश्चित रूप से यह एक आलसी दोस्त होने से संबंधित हो सकता हूं)

  2. "मुझे जूल में लॉगिंग स्तर के नाम पसंद नहीं हैं" । ठीक है, गंभीरता से, यह एक नई निर्भरता को पेश करने के लिए पर्याप्त कारण नहीं है।

  3. "मुझे जूल से आउटपुट के मानक प्रारूप को पसंद नहीं है" । हम्म। यह सिर्फ विन्यास है। आपको कोड-वार कुछ भी करने की ज़रूरत नहीं है। (सच है, पुराने दिनों में आपको इसे सही करने के लिए अपनी खुद की फॉर्मेटर क्लास बनाना पड़ सकता था)।

  4. "मैं अन्य पुस्तकालयों का उपयोग करता हूं जो लॉगिंग-फ्रेमवर्क-एक्स का भी उपयोग करते हैं, इसलिए मैंने सोचा कि बस इसका उपयोग करना आसान है" । यह एक चक्रीय तर्क है, है ना? 'हर कोई' लॉगिंग-फ्रेमवर्क-एक्स का उपयोग क्यों करता है और जूल नहीं?

  5. "हर कोई लॉगिंग-फ्रेमवर्क-एक्स का उपयोग कर रहा है" । यह मेरे लिए उपरोक्त का एक विशेष मामला है। बहुतायत हमेशा सही नहीं है।

तो असली बड़ा सवाल यह है कि जूल क्यों नहीं? । मुझे क्या याद आया है? लॉगिंग facades (एसएलएफ 4 जे, जेसीएल) के लिए Raison d'être यह है कि कई लॉगिंग कार्यान्वयन ऐतिहासिक रूप से मौजूद हैं और इसका कारण वास्तव में जेयूएल से पहले युग में वापस आता है जैसा कि मैंने इसे देखा है। यदि JUL सही था तो लॉगिंग facades मौजूद नहीं होगा, या क्या? उन्हें गले लगाने के बजाय हमें सवाल नहीं करना चाहिए कि वे पहले स्थान पर क्यों जरूरी थे? (और देखें कि क्या कारण अभी भी मौजूद हैं)

ठीक है, अब तक मेरे शोध ने कुछ चीजों को जन्म दिया है जो मैं देख सकता हूं JUL के साथ असली समस्या हो सकती है:

  1. प्रदर्शन कुछ कहते हैं कि एसएलएफ 4 जे में प्रदर्शन बाकी से बेहतर है। ऐसा लगता है कि मुझे समयपूर्व अनुकूलन का मामला है। यदि आपको प्रति सेकंड सैकड़ों मेगाबाइट लॉग इन करने की आवश्यकता है तो मुझे यकीन नहीं है कि आप वैसे भी सही रास्ते पर हैं। जेयूएल भी विकसित हुआ है और जावा 1.4 पर किए गए परीक्षण अब सत्य नहीं हो सकते हैं। आप here इसके बारे में पढ़ सकते हैं और इस फिक्स ने इसे जावा 7 में बनाया है। कई लॉगिंग विधियों में स्ट्रिंग कॉन्सटेनेशन के ओवरहेड के बारे में भी बात करते हैं। हालांकि टेम्पलेट आधारित लॉगिंग इस लागत से बचाती है और यह जूल में भी मौजूद है। व्यक्तिगत रूप से मैं वास्तव में टेम्पलेट आधारित लॉगिंग कभी नहीं लिखता हूं। इसके लिए बहुत आलसी। उदाहरण के लिए यदि मैं इसे JUL के साथ करता हूं:

    log.finest("Lookup request from username=" + username 
       + ", valueX=" + valueX
       + ", valueY=" + valueY));
    

    मेरा आईडीई मुझे चेतावनी देगा और अनुमति मांगेगा कि इसे इसे बदलना चाहिए:

    log.log(Level.FINEST, "Lookup request from username={0}, valueX={1}, valueY={2}", 
       new Object[]{username, valueX, valueY});
    

    .. जो मैं निश्चित रूप से स्वीकार करेंगे। अनुमति प्रदान की गई ! आपके सहयोग के लिए धन्यवाद।

    इसलिए मैं वास्तव में ऐसे बयान नहीं लिखता हूं, जो आईडीई द्वारा किया जाता है।

    प्रदर्शन के मुद्दे पर निष्कर्ष में मुझे कुछ भी नहीं मिला है जो सुझाव देगा कि प्रतिस्पर्धा की तुलना में जेयूएल का प्रदर्शन ठीक नहीं है।

  2. कक्षापथ से विन्यास । आउट ऑफ़ द बॉक्स JUL क्लासपाथ से कॉन्फ़िगरेशन फ़ाइल लोड नहीं कर सकता है। यह ऐसा करने के लिए कोड की कुछ पंक्तियां हैं । मैं देख सकता हूं कि यह परेशान क्यों हो सकता है लेकिन समाधान छोटा और सरल है।

  3. आउटपुट हैंडलर की उपलब्धता । JUL 5 आउटपुट हैंडलर के साथ-साथ-बॉक्स में आता है: कंसोल, फ़ाइल स्ट्रीम, सॉकेट और मेमोरी। इन्हें बढ़ाया जा सकता है या नए लोगों को लिखा जा सकता है। यह उदाहरण के लिए यूनिक्स / लिनक्स Syslog और विंडोज इवेंट लॉग को लिख रहा है। मैंने व्यक्तिगत रूप से इस आवश्यकता को कभी नहीं लिया है और न ही मैंने इसे इस्तेमाल किया है, लेकिन मैं निश्चित रूप से संबंधित हो सकता हूं कि यह एक उपयोगी विशेषता क्यों हो सकती है। उदाहरण के लिए लॉगबैक Syslog के लिए एक एपेंडर के साथ आता है। फिर भी मैं उस पर बहस करूंगा

    1. आउटपुट गंतव्यों के लिए 99.5% जरूरतों को कवर किया गया है जो कि जेयूएल आउट ऑफ़ द बॉक्स में है।
    2. किसी और चीज के शीर्ष पर JUL के शीर्ष पर कस्टम हैंडलर द्वारा विशेष आवश्यकताओं को पूरा किया जा सकता है। मेरे लिए कुछ भी नहीं है जो बताता है कि एक अन्य लॉगिंग फ्रेमवर्क के लिए JUL के लिए Syslog आउटपुट हैंडलर लिखने में अधिक समय लगता है।

मैं वास्तव में चिंतित हूं कि मैंने कुछ अनदेखा किया है। लॉगिंग facades और JUL के अलावा लॉगिंग कार्यान्वयन का उपयोग इतना व्यापक है कि मुझे इस निष्कर्ष पर आना है कि यह वह है जो मुझे समझ में नहीं आता है। यह पहली बार नहीं होगा, मुझे डर है। :-)

तो मुझे अपने एपीआई के साथ क्या करना चाहिए? मैं इसे सफल बनना चाहता हूं। मैं निश्चित रूप से बस "प्रवाह के साथ जाना" और एसएलएफ 4 जे को लागू कर सकता हूं (जो इन दिनों सबसे लोकप्रिय लगता है) लेकिन मेरे अपने फायदे के लिए मुझे अभी भी समझना होगा कि आज के जूल के साथ क्या गलत है जो सभी फज़ वारंट करता है? क्या मैं अपनी पुस्तकालय के लिए जेयूएल चुनकर खुद को तबाह कर दूंगा?

परीक्षण प्रदर्शन

(07-जुलाई -2012 को नोलन 600 द्वारा जोड़ा गया अनुभाग)

सेकी से नीचे एक संदर्भ है जो एसएलएफ 4 जे के पैरामीट्रिजेशन के बारे में जुएल के मुकाबले 10 गुना या अधिक तेज है। तो मैंने कुछ सरल परीक्षण करना शुरू कर दिया है। पहली नज़र में दावा निश्चित रूप से सही है। प्रारंभिक परिणाम यहां दिए गए हैं (लेकिन पढ़ें!):

  • निष्पादन समय एसएलएफ 4 जे, बैकएंड लॉगबैक: 1515
  • निष्पादन समय एसएलएफ 4 जे, बैकएंड जेयूएल: 12 9 38
  • निष्पादन समय JUL: 16 9 11

उपरोक्त संख्याएं msecs इतनी कम बेहतर हैं। तो 10 बार प्रदर्शन अंतर वास्तव में वास्तव में बहुत करीब है। मेरी प्रारंभिक प्रतिक्रिया: यह बहुत है!

परीक्षण का मूल यहां है। जैसा कि एक पूर्णांक देखा जा सकता है और एक लूप में स्ट्रिंग को गठित किया जाता है जिसे तब लॉग कथन में उपयोग किया जाता है:

    for (int i = 0; i < noOfExecutions; i++) {
        for (char x=32; x<88; x++) {
            String someString = Character.toString(x);
            // here we log 
        }
    }

(मैं चाहता था कि लॉग स्टेटमेंट में एक आदिम डेटा प्रकार (इस मामले में एक int) और एक अधिक जटिल डेटा प्रकार (इस मामले में एक स्ट्रिंग) होना चाहिए। सुनिश्चित नहीं है कि यह महत्वपूर्ण है लेकिन वहां आपके पास है।)

एसएलएफ 4 जे के लिए लॉग स्टेटमेंट:

logger.info("Logging {} and {} ", i, someString);

JUL के लिए लॉग स्टेटमेंट:

logger.log(Level.INFO, "Logging {0} and {1}", new Object[]{i, someString});

वास्तविक माप किए जाने से पहले एक बार परीक्षण किए गए उसी परीक्षण के साथ जेवीएम 'गर्म हो गया' था। जावा 1.7.03 विंडोज 7 पर इस्तेमाल किया गया था। एसएलएफ 4 जे (v1.6.6) और लॉगबैक (v1.0.6) के नवीनतम संस्करणों का उपयोग किया गया था। Stdout और stderr को शून्य डिवाइस पर रीडायरेक्ट किया गया था।

हालांकि, अब सावधान रहें, यह पता चला है कि JUL अपने अधिकांश समय getSourceClassName() में खर्च कर रहा है क्योंकि डिफ़ॉल्ट रूप से JUL आउटपुट में स्रोत वर्ग नाम प्रिंट करता है, जबकि लॉगबैक नहीं करता है। तो हम सेब और संतरे की तुलना कर रहे हैं। मुझे फिर से परीक्षण करना है और लॉगिंग कार्यान्वयन को उसी तरीके से कॉन्फ़िगर करना है ताकि वे वास्तव में एक ही सामान को आउटपुट कर सकें। हालांकि मुझे संदेह है कि एसएलएफ 4 जे + लॉगबैक अभी भी शीर्ष पर बाहर आएगा लेकिन ऊपर दिए गए शुरुआती संख्याओं से बहुत दूर है। बने रहें।

बीटीडब्ल्यू: परीक्षण पहली बार था जब मैंने वास्तव में एसएलएफ 4 जे या लॉगबैक के साथ काम किया था। एक सुखद अनुभव। जब आप शुरू कर रहे हैं तो JUL निश्चित रूप से बहुत कम स्वागत है।

परीक्षण प्रदर्शन (भाग 2)

(08-जुलाई -2012 को नोलन 600 द्वारा जोड़ा गया अनुभाग)

जैसा कि यह पता चला है कि यह वास्तव में प्रदर्शन के लिए कोई फर्क नहीं पड़ता कि आप JUL में अपना पैटर्न कैसे कॉन्फ़िगर करते हैं, यानी इसमें स्रोत का नाम शामिल है या नहीं। मैंने एक बहुत ही सरल पैटर्न के साथ प्रयास किया:

java.util.logging.SimpleFormatter.format="%4$s: %5$s [%1$tc]%n"

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

इसलिए मैं प्रदर्शन के मुद्दे पर निष्कर्ष निकाल रहा हूं कि कम से कम परीक्षण किए गए टेम्पलेट आधारित लॉग स्टेटमेंट के लिए JUL (धीमी) और SLF4J + लॉगबैक (त्वरित) के बीच वास्तविक प्रदर्शन अंतर में लगभग 10 का कारक लगता है। जैसे केकी ने कहा।

मैं एक और बात भी देख सकता हूं अर्थात् एसएलएफ 4 जे की getLogger() कॉल जूल के getLogger() तुलना में बहुत अधिक महंगा है। (यदि मेरा प्रोफाइलर सटीक है तो 95 एमएस बनाम 0.3 एमएस)। यह समझ में आता है। एसएलएफ 4 जे को अंतर्निहित लॉगिंग कार्यान्वयन के बाध्यकारी पर कुछ समय देना है। यह मुझे डराता नहीं है। ये कॉल एक आवेदन के जीवनकाल में कुछ दुर्लभ होना चाहिए। स्थिरता वास्तविक लॉग कॉल में होना चाहिए।

अंतिम निष्कर्ष

(08-जुलाई -2012 को नोलन 600 द्वारा जोड़ा गया अनुभाग)

आपके सभी उत्तरों के लिए धन्यवाद। मैंने शुरू में सोचा कि इसके विपरीत मैंने अपने एपीआई के लिए एसएलएफ 4 जे का उपयोग करने का फैसला किया है। यह कई चीजों और आपके इनपुट पर आधारित है:

  1. यह तैनाती के समय लॉग कार्यान्वयन का चयन करने के लिए लचीलापन देता है।

  2. अनुप्रयोग सर्वर के अंदर चलाने पर JUL की कॉन्फ़िगरेशन की लचीलापन की कमी के साथ समस्याएं।

  3. यदि आप इसे लॉगबैक के साथ जोड़ते हैं तो विशेष रूप से ऊपर वर्णित एसएलएफ 4 जे निश्चित रूप से बहुत तेज है। यहां तक ​​कि अगर यह सिर्फ एक मोटा परीक्षण था, तो मुझे विश्वास करने का कारण है कि जेएलयू की तुलना में एसएलएफ 4 जे + लॉगबैक पर ऑप्टिमाइज़ेशन में बहुत अधिक प्रयास किए गए हैं।

  4. प्रलेखन। एसएलएफ 4 जे के लिए प्रलेखन बस बहुत अधिक व्यापक और सटीक है।

  5. पैटर्न लचीलापन। जैसा कि मैंने परीक्षण किए हैं, मैंने JUL को लॉगबैक से डिफ़ॉल्ट पैटर्न की नकल करने के लिए निर्धारित किया है। इस पैटर्न में धागे का नाम शामिल है। यह पता चला है कि जेयूएल बॉक्स से बाहर नहीं कर सकता है। ठीक है, मैंने अब तक इसे याद नहीं किया है, लेकिन मुझे नहीं लगता कि यह एक ऐसी चीज है जो लॉग फ्रेमवर्क से गुम होनी चाहिए। अवधि!

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

तो यह हुआ कि अजीब बात यह थी कि एसएलएफ 4 जे के साथ थोड़ा सा काम करने के बाद मैं वास्तव में जेयूएल के साथ काफी परेशान हो गया था। मुझे अभी भी खेद है कि इसे जूल के साथ इस तरह से होना चाहिए। JUL सही से बहुत दूर है लेकिन नौकरी की तरह है। बस काफी अच्छी तरह से नहीं है। Properties बारे में एक उदाहरण के रूप में भी कहा जा सकता है लेकिन हम इस बात के बारे में नहीं सोचते कि लोग अपनी कॉन्फ़िगरेशन लाइब्रेरी में प्लग कर सकते हैं और आप क्या हैं। मुझे लगता है कि कारण यह है कि Properties बार के ऊपर आता है जबकि विपरीत आज के जूल के लिए सच है ... और अतीत में यह शून्य पर आया क्योंकि यह अस्तित्व में नहीं था।


  1. Java 1.4 में java.util.logging पेश किया गया था। इससे पहले लॉगिंग के लिए उपयोग किया गया था, यही कारण है कि कई अन्य लॉगिंग एपीआई मौजूद हैं। उन एपीआई जहां जावा 1.4 से पहले भारी इस्तेमाल किया गया था और इस प्रकार एक महान मार्केटशेयर था जो 1.4 रिलीज होने पर केवल 0 तक नहीं गिर गया था।

  2. जेयूएल ने उन सभी महान चीजों को शुरू नहीं किया, जिन चीजों का आपने उल्लेख किया है उनमें से कई 1.4 में बहुत खराब हैं और केवल 1.5 में बेहतर हो गए हैं (और मुझे लगता है कि 6 में भी, लेकिन मुझे भी यकीन नहीं है)।

  3. JUL एक ही JVM में विभिन्न कॉन्फ़िगरेशन के साथ एकाधिक अनुप्रयोगों के लिए उपयुक्त नहीं है (कई वेब अनुप्रयोगों को सोचें जिन्हें इंटरैक्ट नहीं करना चाहिए)। टॉमकैट को काम करने के लिए कुछ हुप्स के माध्यम से कूदने की जरूरत है (अगर मैं सही ढंग से समझ गया तो प्रभावी ढंग से JUL को फिर से कार्यान्वित कर रहा हूं)।

  4. आप हमेशा अपने पुस्तकालयों का उपयोग करने वाले लॉगिंग फ्रेमवर्क को प्रभावित नहीं कर सकते हैं। इसलिए SLF4J का उपयोग करना (जो वास्तव में अन्य पुस्तकालयों के ऊपर केवल एक बहुत ही पतली एपीआई परत है) पूरे लॉगिंग दुनिया की कुछ लगातार तस्वीर रखने में मदद करता है (इसलिए आप उसी सिस्टम में लाइब्रेरी लॉगिंग करते समय अंतर्निहित लॉगिंग फ्रेमवर्क का निर्णय ले सकते हैं)।

  5. पुस्तकालय आसानी से बदल नहीं सकते हैं। यदि लॉगिंग-लाइब्रेरी-एक्स का उपयोग करने के लिए उपयोग की जाने वाली लाइब्रेरी का पिछला संस्करण यह आसानी से लॉगिंग-लाइब्रेरी-वाई (उदाहरण के लिए JUL) पर स्विच नहीं कर सकता है, भले ही बाद वाला स्पष्ट रूप से शानदार हो: उस लाइब्रेरी के किसी भी उपयोगकर्ता को सीखना होगा नया लॉगिंग ढांचा और (कम से कम) उनके लॉगिंग को फिर से कॉन्फ़िगर करें। यह एक बड़ा नो-नो है, खासकर जब यह ज्यादातर लोगों को कोई स्पष्ट लाभ नहीं देता है।

ऐसा लगता है कि मुझे लगता है कि JUL इन दिनों अन्य लॉगिंग ढांचे के लिए कम से कम एक वैध विकल्प है।


आईएमएचओ, slf4j जैसे लॉगिंग मुखौटा का उपयोग करने में मुख्य लाभ यह है कि आप लाइब्रेरी के अंतिम उपयोगकर्ता को अंतिम उपयोगकर्ता को अपनी पसंद को लागू करने के बजाय, कौन सा ठोस लॉगिंग कार्यान्वयन करना चाहते हैं, चुनते हैं।

हो सकता है कि उसने लॉग 4j या लॉगबैक (विशेष फॉर्मेटर्स, एपेंडर इत्यादि) में समय और पैसा निवेश किया है और जूल को कॉन्फ़िगर करने के बजाय लॉग 4j या लॉगबैक का उपयोग जारी रखना पसंद करते हैं। कोई समस्या नहीं: slf4j इसे अनुमति देता है। क्या यह जूल पर लॉग 4j का उपयोग करने के लिए एक बुद्धिमान विकल्प है? शायद शायद नहीं। लेकिन आप परवाह नहीं है। अंतिम उपयोगकर्ता को वह पसंद करना चाहिए जो वह पसंद करता है।


मैंने शुरू किया, जैसा कि मुझे संदेह है, JUL का उपयोग करना क्योंकि यह तुरंत जाने के लिए सबसे आसान था। हालांकि, पिछले कुछ सालों में, मेरी इच्छा है कि मैंने थोड़ा और समय चुनने में बिताया है।

मेरा मुख्य मुद्दा यह है कि हमारे पास पर्याप्त मात्रा में 'लाइब्रेरी' कोड है जिसका उपयोग कई अनुप्रयोगों में किया जाता है और वे सभी JUL का उपयोग करते हैं। जब भी मैं इन उपकरणों का उपयोग वेब-सेवा प्रकार ऐप में करता हूं तो लॉगिंग गायब हो जाती है या कहीं अप्रत्याशित या अजीब जाती है।

हमारा समाधान लाइब्रेरी कोड में एक मुखौटा जोड़ना था जिसका मतलब था कि लाइब्रेरी लॉग कॉल नहीं बदले थे, लेकिन जो भी लॉगिंग तंत्र उपलब्ध है, गतिशील रूप से रीडायरेक्ट किए गए थे। जब पीओजेओ टूल में शामिल किया जाता है तो उन्हें जेयूएल को निर्देशित किया जाता है लेकिन जब वेब-ऐप के रूप में तैनात किया जाता है तो उन्हें लॉगबैक पर रीडायरेक्ट किया जाता है।

हमारा अफसोस - निश्चित रूप से - यह है कि लाइब्रेरी कोड पैरामीटरयुक्त लॉगिंग का उपयोग नहीं करता है, लेकिन अब इसे आवश्यकतानुसार फिर से लगाया जा सकता है।

हमने मुखौटा बनाने के लिए slf4j का उपयोग किया।


अस्वीकरण : मैं log4j, एसएलएफ 4 जे और लॉगबैक परियोजनाओं के संस्थापक हूं।

एसएलएफ 4 जे पसंद करने के उद्देश्य के कारण हैं। एक के लिए, यह अंत उपयोगकर्ता को अंतर्निहित लॉगिंग ढांचे को चुनने की स्वतंत्रता प्रदान करता है। इसके अलावा, savvier उपयोगकर्ता लॉगबैक पसंद करते हैं जो लॉग 4j से परे क्षमताओं की पेशकश करता है , जूल गिरने के रास्ते के साथ। फीचर-वार जूल कुछ उपयोगकर्ताओं के लिए पर्याप्त हो सकता है लेकिन कई अन्य लोगों के लिए यह सिर्फ नहीं है। संक्षेप में, यदि लॉगिंग आपके लिए महत्वपूर्ण है, तो आप अंतर्निहित कार्यान्वयन के रूप में लॉगबैक के साथ SLF4J का उपयोग करना चाहेंगे। अगर लॉगिंग महत्वहीन है, तो जुल ठीक है।

हालांकि, एक ओएसएस डेवलपर के रूप में, आपको अपने उपयोगकर्ताओं की वरीयताओं को ध्यान में रखना होगा, न केवल स्वयं ही। यह इस प्रकार है कि आपको एसएलएफ 4 जे को अपनाना चाहिए क्योंकि आप इस बात से आश्वस्त हैं कि एसएलएफ 4 जे जूल से बेहतर है, लेकिन वर्तमान में अधिकांश जावा डेवलपर्स (जुलाई 2012) एसएलएफ 4 जे को अपने लॉगिंग एपीआई के रूप में पसंद करते हैं। यदि अंततः आप लोकप्रिय राय की परवाह न करने का निर्णय लेते हैं, तो निम्नलिखित तथ्यों पर विचार करें:

  1. जो लोग जूल पसंद करते हैं, वे सुविधा से बाहर करते हैं क्योंकि जूल को जेडीके के साथ बंडल किया जाता है। मेरे ज्ञान के लिए जूल के पक्ष में कोई और उद्देश्य तर्क नहीं है
  2. जूल के लिए आपकी अपनी प्राथमिकता सिर्फ वरीयता है

इस प्रकार, सार्वजनिक राय के ऊपर "कठिन तथ्यों" को पकड़ना, जबकि प्रतीत होता है बहादुर, इस मामले में एक तार्किक झूठ है।

यदि अभी भी विश्वास नहीं है, जेबी निजेट एक अतिरिक्त और शक्तिशाली तर्क देता है:

सिवाय इसके कि अंतिम उपयोगकर्ता अपने कोड के लिए पहले ही यह अनुकूलन कर सकता था, या लॉग लाइज या लॉगबैक का उपयोग करने वाली दूसरी लाइब्रेरी। जूल एक्स्टेंसिबल है, लेकिन लॉगबैक, जुल, log4j और ईश्वर को केवल इतना ही पता है कि कौन सा अन्य लॉगिंग फ्रेमवर्क जानता है क्योंकि वह चार पुस्तकालयों का उपयोग करता है जो चार अलग-अलग लॉगिंग फ्रेमवर्क का उपयोग करते हैं। एसएलएफ 4 जे का उपयोग करके, आप उसे लॉगिंग फ्रेमवर्क को कॉन्फ़िगर करने की अनुमति देते हैं, जिसे आपने चुना है। याद रखें कि एक ठेठ प्रोजेक्ट लाइब्रेरी के असंख्य का उपयोग करता है, न सिर्फ आपके

यदि आप किसी भी कारण से एसएलएफ 4 जे एपीआई से नफरत करते हैं और इसका उपयोग करके अपने काम से मजाक उड़ाएंगे, तो हर तरह से जूल के लिए जाएं, जूल को एसएलएफ 4 जे पर रीडायरेक्ट करने के साधन हैं

वैसे, जूल पैरामीट्रिजेशन एसएलएफ 4 जे की तुलना में कम से कम 10 गुना धीमा है जो एक उल्लेखनीय अंतर बनाता है।





logback