क्या यह बताने का कोई तरीका है कि क्लासपाथ संसाधन फ़ाइल या निर्देशिका है या नहीं?

Question

उदाहरण के लिए, यह स्निपेट stream.read() लाइन पर एक NullPointerException (!) फेंकता है, मानते हैं कि com.google पैकेज कहीं भी एक जार में मौजूद है (उदाहरण के लिए, गुवा)। com/google एक पैकेज एक जार फाइल सिस्टम के बजाय में है कि के साथ बदली है

ClassLoader classLoader = getClass().getClassLoader(); 
URL resource = classLoader.getResource("com/google"); 
InputStream stream = resource.openStream(); 
System.out.println(stream.toString()); // Fine -- stream is not null 
stream.read(); // NPE inside FilterInputStream.read()! 

, तो टुकड़ा सब पर दुर्घटना नहीं है। असल में, ऐसा लगता है कि उस निर्देशिका में फ़ाइलों को नई लाइनों से अलग किया गया है, हालांकि मैं कल्पना नहीं कर सकता कि व्यवहार कहीं भी निर्दिष्ट है।

क्या संसाधन पथ "com/google" को "सामान्य" संसाधन फ़ाइल या निर्देशिका में इंगित करने का कोई तरीका है?

Answer 1

इन संसाधनों को लोड करने में शामिल प्रोटोकॉल हैंडलर के लिए कुछ अनिर्दिष्ट व्यवहार के कारण यह एक गड़बड़ है। इस विशेष स्थिति में, दो: sun.net.www.protocol.file.Handler और sun.net.www.protocol.jar.Handler हैं, और वे प्रत्येक निर्देशिका मामले को थोड़ा अलग तरीके से संभालते हैं।कुछ प्रयोगों के आधार पर, यहां वे एक क्या करना है:

sun.net.www.protocol.file.Handler:

• क्या इस Handler करता है एक FileURLConnection खुला, जब सामना जो exactly what you discovered it did करता है एक निर्देशिका के साथ। आप देख सकते हैं कि यह सिर्फ के साथ एक निर्देशिका है:

  if (resource.getProtocol().equals("file")) { 
      return new File(resource.getPath()).isDirectory(); 
  } 
  

sun.net.www.protocol.jar.Handler:

• यह Handler, दूसरे हाथ पर, एक को खोलता है JarURLConnection जो अंततः makes its way को ZipCoder पर ले गया। यदि आप उस कोड को देखते हैं, तो आपको कुछ दिलचस्प लगेगा: jzentry मूल जेएनआई कॉल से null वापस आ जाएगा क्योंकि वास्तव में, JAR ज़िप फ़ाइल में com/google नामक फ़ाइल नहीं है, और इसलिए यह शून्य पर वापस आती है धारा जो इसे लपेटती है।

हालांकि, एक समाधान है। हालांकि ZipCodercom/google नहीं मिलेगा, यह com/google/ ढूंढ सकता है (इस प्रकार अधिकांश ज़िप इंटरफेस किसी कारण से काम करते हैं)। उस स्थिति में, jzentry मिलेगा, और यह सिर्फ एक शून्य बाइट वापस कर देगा।

तो, इन सभी यादृच्छिक कार्यान्वयन-विशिष्ट व्यवहार के माध्यम से काटने, तो आप शायद यह पता लगाने कर सकते हैं अगर यह पहली बार एक अनुगामी / (which is what URLClassLoaders expect for directories anyway) के साथ संसाधन का उपयोग करने के लिए कोशिश कर रहा द्वारा एक निर्देशिका है। यदि ClassLoader.getResource() गैर-शून्य देता है, तो यह एक निर्देशिका है। यदि ऐसा नहीं होता है, पीछे पीछे स्लैश के बिना प्रयास करें। यदि यह गैर-शून्य देता है, तो यह एक फ़ाइल है। अगर यह अभी भी शून्य हो जाता है, तो यह एक मौजूदा संसाधन भी नहीं है।

किंडा हैकी, लेकिन मुझे नहीं लगता कि कुछ भी बेहतर है। आशा है कि ये आपकी मदद करेगा!

Answer 2

मुझे लगता है कि 2 समाधान हैं।

1. पथ के विश्लेषण के आधार पर निष्क्रिय समाधान। यदि यह .jar या .zip या .war या .ear के साथ समाप्त होता है तो यह एक फ़ाइल है। अन्यथा यह एक निर्देशिका है। मुझे लगता है कि यह दृष्टिकोण 99.99% मामलों में काम करेगा जब तक कि कोई आपको उद्देश्य पर असफल रहने की कोशिश नहीं करता। उदाहरण के लिए एक निर्देशिका की तरह दिखने वाले मुलायम लिंक को परिभाषित करके, लेकिन एक फ़ाइल या vise बनाम है।
2. जेवीएम तर्क की नकल करने का प्रयास करें जो क्लासपाथ के पथों को वर्तमान कार्यशील निर्देशिका के अपेक्षाकृत समझता है। इसलिए, new File(".") का उपयोग कर वर्तमान कार्यशील निर्देशिका पुनर्प्राप्त करें, फिर क्लासपाथ लें, इसे विभाजित करें और इसके प्रत्येक तत्व के लिए new File(".", classPathElement) का उपयोग करें जब तक कि इसे पूर्ण पथ का उपयोग करके परिभाषित न किया जाए।

इसके साथ शुभकामनाएं।

Answer 3

कोई सुरक्षित और जेनेरिक इसका पता लगाने के लिए कोई तरीका नहीं है। जब आप ClassLoader.getResource() का उपयोग करते हैं, तो क्लासलोडर यूआरएल में व्यावहारिक रूप से कुछ भी वापस कर सकता है, सिद्धांत रूप में कुछ भी जो आपने कभी नहीं देखा है यदि क्लासलोडर अपनी यूआरएल योजना (और प्रोटोकॉल) लागू करता है।

आपका एकमात्र विकल्प getResource() द्वारा लौटाए गए यूआरएल का विश्लेषण करना है, प्रोटोकॉल को यह संकेत देना चाहिए कि यह क्या है (उदा। "फ़ाइल: //")। लेकिन सावधान रहें, पर्यावरण के आधार पर यह उन चीज़ों को वापस कर सकता है जिनके लिए आपने योजना नहीं बनाई थी।

लेकिन सिर्फ एक संसाधन का उपयोग करने के लिए, आप ऐसा नहीं कर देखभाल जहां यह (आपको कॉन्फ़िगरेशन संबंधी समस्या डिबगिंग रहे हैं आप परवाह सकता है, लेकिन अपने कोड परवाह नहीं होना चाहिए) से आता है।

सामान्य रूप से आपको लौटाई इनपुटस्ट्रीम की क्षमताओं के बारे में धारणा नहीं करनी चाहिए, यानी मार्क/रीसेट इत्यादि का समर्थन करने पर भरोसा न करें। केवल सुरक्षित संचालन स्ट्रीम को पढ़ना होगा। यदि एक IOException पढ़ने के दौरान होता है तो यह संसाधन (नेटवर्क कनेक्शन खोने आदि) तक पहुंच के साथ एक समस्या इंगित करता है।

संपादित करें: getResource() को आईएमओ केवल संसाधनों को लौटा देना चाहिए (उदा। फाइल या ज़िप फ़ाइल प्रविष्टियां), लेकिन निर्देशिका (क्योंकि वे संसाधन नहीं हैं)। हालांकि मैं ऐसा करने के लिए हर संभव क्लासलोडर पर भरोसा नहीं करता, और मुझे यकीन नहीं है कि सही व्यवहार क्या है (यदि यह कहीं भी निर्दिष्ट है)।