जावा: पथ बनाम फ़ाइल

Question

जावा 7 में लिखे गए नए अनुप्रयोगों के लिए, किसी java.io.Fileवस्तु का किसी और उपयोग करने का कोई कारण है या क्या हम इसे पदावनत मान सकते हैं?

मेरा मानना ​​है कि एक java.nio.file.Pathसब कुछ कर सकता है एक java.io.Fileकर सकते हैं और अधिक।

Answer 1

कहानी संक्षिप्त में:

java.io.Fileसबसे अधिक संभावना कभी भी अपूरणीय / असमर्थित नहीं होगी। उस ने कहा, java.nio.file.Pathअधिक आधुनिक काम का हिस्सा है java.nio.file, और सब कुछ java.io.Fileकर सकता है, लेकिन आम तौर पर एक बेहतर तरीके से, और अधिक।

नई परियोजनाओं के लिए, का उपयोग करें Path।

और अगर आपको Fileविरासत के लिए कभी किसी वस्तु की आवश्यकता होती है , तो # Path toFile () कॉल करें

फ़ाइल से पथ पर माइग्रेट करना

यह ओरेकल पेज मतभेदों को उजागर करता है, और मैप्स java.io.File functionalityकोjava.nio.file lib (including Path) functionality

जेनिस जे। हिस और शेरोन ज़खौर का लेख, मई 2009, JDK 7 में NIO.2 फ़ाइल सिस्टम पर चर्चा

Comments

आप ओरेकल की टिप्पणियों को यहां के अंतरों पर पढ़ सकते हैं: docs.oracle.com/javase/tutorial/essential/io/legacy.html

— जोशिया योडर

यह भी ध्यान दें कि "फाइलें" (बहुवचन में) पदावनत नहीं है । यह अनिवार्य रूप से एक सार वर्ग है जो पथ ऑब्जेक्ट्स पर संचालित होता है और पुरानी फ़ाइल वर्ग की कई विशेषताओं को निष्पादित करता है, जैसे कि isDirectory () या मौजूद ()

— जोशिया योडर

अब मैं सोच रहा हूँ: JavaFX 8 में नई फ़ाइल / फ़ोल्डर फ़ोल्डर संवाद क्यों फिर भी Fileइसके बजाय उपयोग करते हैं Path?

— 12

पथ एक इंटरफ़ेस है। एक उदाहरण बनाने के लिए, Paths.get (फ़ाइल नाम) का उपयोग करें। यह नई फ़ाइल (फ़ाइल नाम) .exists () के बजाय Files.exists (Paths.get (फ़ाइल नाम)) लिखने के भ्रम की वजह से हो सकता है कि पुराने API अभी भी उपयोग किया जाता है।

— जोशियाह योडर

Pathअधिक आसानी से "बच्चों को जोड़ने" resolve(...)या "एक स्तर ऊपर ले जाने" के लिए getParent(), आदि के साथ संशोधित किया जा सकता है , जबकि Fileनहीं कर सकते। अनिवार्य रूप से एक बार जब आप पथ को संशोधित करना समाप्त कर लेते हैं, तो आप अक्सर इसे परिवर्तित कर देंगे toFile()ताकि इसे एक FileInputStreamनिर्माता के रूप में विरासत विधियों में भेजा जा सके ।

— मास्टरएचडी

Answer 2

क्या हम इस पर विचार कर सकते हैं?

नहीं, आप इस पर तब तक विचार नहीं कर सकते जब तक कि यह Fileजावदोक में चिह्नित न हो जाए ।

Comments

यहां तक ​​कि अगर यह इनमें से एक है "क्योंकि RFC ऐसा कहता है" -स्वांसर्स, मैं इसे एक अच्छा जवाब नहीं मानूंगा। यह बहुत स्पष्ट है कि फ़ाइल पथ द्वारा प्रतिस्थापित किया जाएगा। यदि आप समय से आगे रहना चाहते हैं, तो आप तुरंत पथ का उपयोग करना शुरू कर सकते हैं और जहां जरूरत हो वहां फ़िले () का उपयोग करें।

— क्रिस

@ क्रिस को जेडीके से कभी भी हटाया नहीं गया क्योंकि उन्होंने 1.02 में AWT इवेंट मॉडल को बदल दिया था। यह बिल्कुल स्पष्ट नहीं है। यह गलत है।

— लोरेन का मार्किव

@downvoters यह उत्तर मूल रूप से एक तनातनी है। यह गलत नहीं हो सकता। नायब जब से मैंने यह उत्तर लिखा है, पाँच वर्षों में, जावा 8 बाद में दिखाई दिया है, और java.io.Fileअभी भी न तो हटाया गया है और न ही हटाया गया है, और अभी भी जावदोक में यह सुझाव देने के लिए कुछ भी नहीं है कि इनमें से कोई भी बात कभी भी होगी।

— लोर्ने की

@EJP मैंने अभी आपकी उस टिप्पणी को गलत ठहराया है। हालाँकि, मुझे पूरी तरह से यकीन नहीं है कि जब आप कहते हैं कि आप सही हैं तो उत्तर एक टॉटोलॉजी है। यह प्रश्न, जिसे "राय-आधारित" होने के लिए संभवतः तोड़ दिया जाना चाहिए था, "क्या हम इसे पदावनत मान सकते हैं "। ठीक है, हाँ, ओपी और किसी और को कर सकते हैं , लेकिन यह नहीं है।

— माइक कृंतक

@mikerodent मेरा सुझाव है कि प्रश्न के बारे में वास्तव में क्या है, इसका केवल एक विलक्षण गलत अर्थ है। इसके अलावा एक आंशिक उद्धरण।

— लोर्ने

Answer 3

अधिक जानकारी के लिए इस लेख को देखें - http://www.oracle.com/technetwork/articles/javase/nio-139333.html

मूल रूप से फ़ाइल।पैथ अब से जाने का रास्ता होगा, लेकिन जैसा कि व्यापक रूप से जाना जाता है जावा लोग बैक-संगतता रखने के लिए जाते हैं इसलिए मुझे लगता है कि उन्होंने इसे छोड़ दिया है।

Comments

क्या आप कृपया लिंक अपडेट करेंगे? मैं इस लेख को पढ़ना चाहूंगा।

— जॉन बी

दुर्भाग्य से मुझे ओरेकल वेब पेज पर मूल लेख नहीं मिला। यहाँ एक तरह से

— वर्बैक

मुझे लेख को फिर से एक सामान्य ओरेकल की ओर मिला - जवाब देने के लिए लिंक जोड़ा गया।

— डंकन जोन्स

Answer 4

का बहुत अच्छा जवाब पूरा करूंगा @mmcrae।

क्या कोई java.io.ile ऑब्जेक्ट का उपयोग करने का कोई कारण है या क्या हम इसे पदावनत मान सकते हैं?

JDK कक्षाएं बहुत ही कम पदावनत हैं।
आप JDK 8 API पर पहले JDK के बाद से हटाए गए सभी वर्गों की सूची को देख सकते हैं ।
इसमें कक्षाओं का केवल एक छोटा सा हिस्सा होता है जो Oracle दस्तावेज और जावा समुदाय उपयोग करने के लिए हतोत्साहित करता है।
java.util.Date, java.util.Vector, java.util.Hashtable... के साथ इतने सारे दोष पदावनत नहीं कर रहे हैं वर्गों रहे हैं।
पर क्यों ?
क्योंकि वैचारिक रूप से कुछ का deprecatedमतलब अभी भी है लेकिन उपयोग करने के लिए हतोत्साहित करना क्योंकि यह निश्चित रूप से हटा दिया जाएगा।
हजारों प्रोग्राम इन खराब डिज़ाइन किए गए वर्गों पर भरोसा करते हैं।
ऐसी कक्षाओं के लिए, जावा एपीआई डेवलपर्स ऐसा संकेत नहीं देंगे।

उत्तर @EJPवास्तव में सही है:

जब तक और जब तक कि यह जावदोक में अंकित न हो।

इसलिए, मुझे लगता है कि आपका प्रश्न इसके संदर्भ में अधिक समझ में आता है:
"जैसा कि हमारे पास विकल्प है, क्या हमें नए विकास के लिए उपयोग करना चाहिए java.io.Fileया java.nio.file.Pathयदि उत्तर है java.nio.file.Path, तो क्या आप आसानी से java.io.Fileउपयोग करने वाले विरासत परियोजनाओं के लिए लाभ उठा सकते हैं java.io.File?"

मेरा मानना ​​है कि एक java.nio.file.Path सब कुछ एक java.io.ile कर सकता है। और कर सकते हैं।

आपके पास जवाब है।

विरासत IO के बारे में यह oracle ट्यूटोरियल आपकी सोच की पुष्टि करता है।

जावा एसई 7 रिलीज से पहले, java.io.Fileक्लास I / O फ़ाइल के लिए उपयोग किया जाने वाला तंत्र था, लेकिन इसमें कई कमियां थीं।

जब वे असफल हुए तो कई विधियाँ अपवाद नहीं थीं, इसलिए एक उपयोगी त्रुटि संदेश प्राप्त करना असंभव था। उदाहरण के लिए, यदि कोई फ़ाइल विलोपन विफल हो गया, तो प्रोग्राम को एक "डिलीट फेल" प्राप्त होगा, लेकिन यह नहीं पता होगा कि क्या ऐसा इसलिए था क्योंकि फ़ाइल मौजूद नहीं थी, उपयोगकर्ता के पास अनुमतियां नहीं थीं, या कोई अन्य समस्या थी।

नाम बदलने की विधि लगातार प्लेटफार्मों भर में काम नहीं किया। प्रतीकात्मक लिंक के लिए कोई वास्तविक समर्थन नहीं था।

मेटाडेटा के लिए अधिक समर्थन वांछित था, जैसे फ़ाइल अनुमतियां, फ़ाइल स्वामी और अन्य सुरक्षा विशेषताएँ।

फ़ाइल मेटाडेटा एक्सेस करना अक्षम था।

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

विश्वसनीय कोड लिखना संभव नहीं था, जो किसी फ़ाइल ट्री पर फिर से चल सकता है और उचित रूप से प्रतिक्रिया कर सकता है यदि परिपत्र प्रतीकात्मक लिंक थे।

कई कमियों के साथ java.io.File, हमें नए विकास के लिए इस वर्ग का उपयोग करने के लिए वास्तव में कोई कारण नहीं है।
और यहां तक ​​कि विरासत कोड का उपयोग करने के लिए java.io.File, ओरेकल उपयोग करने के लिए संकेत देता है Path।

शायद आपके पास विरासत कोड है जो java.io.File का उपयोग करता है और अपने कोड के लिए न्यूनतम प्रभाव के साथ java.nio.file.Path कार्यक्षमता का लाभ लेना चाहता है।

Java.io.File वर्ग, toPath विधि प्रदान करता है, जो एक पुरानी शैली फ़ाइल उदाहरण को java.nio.file.Path उदाहरण में परिवर्तित करता है, जो इस प्रकार है:

Path input = file.toPath();

फिर आप पथ श्रेणी के लिए उपलब्ध समृद्ध सुविधा का लाभ उठा सकते हैं।

उदाहरण के लिए, मान लें कि आपके पास कुछ कोड है जो फ़ाइल को हटा दिया गया है:

file.delete();

आप निम्न प्रकार से Files.delete विधि का उपयोग करने के लिए इस कोड को संशोधित कर सकते हैं:

Path fp = file.toPath();
Files.delete(fp);

Comments

संक्षेप में, वह / वह वास्तव में इस पर विचार कर सकती है यदि वह चाहती है।

— माइक कृंतक

@ माइक कृंतक बिल्कुल सही। वैचारिक रूप से उसे / उसे चाहिए जबकि उसे समझाया कारणों के लिए जावदोक के मामले में ऐसा नहीं है।

— davidxxx

Answer 5

हां, लेकिन Java7 के अपने मानक API सहित कई मौजूदा API, अभी भी केवल Fileप्रकार के साथ काम करते हैं ।

Comments

Path ऑब्जेक्ट्स को Path.toFile () का उपयोग करके फ़ाइल ऑब्जेक्ट में कनवर्ट किया जा सकता है , फिर मानक API का उपयोग करें।

— जैकट्रैड्स

तो आपका जवाब है 'हां लेकिन नहीं'?

— लोर्ने

Answer 6

Java.io.File को पदावनत नहीं किया जाता है। हाँ java.nio.file.Path बेहतर है, लेकिन जब तक Java.io.File का उपयोग करते हुए अभी भी बहुत सारे कार्यक्रम और पाठ्य पुस्तकें हैं, यदि केवल विरासत कारणों से, इसे पदावनत नहीं माना जाना चाहिए, तो यह बहुत महत्वपूर्ण है। ऐसा करने से बिना किसी लाभ के काम करने के लिए बस एक स्पैनर फेंकना होगा। उदाहरण के लिए एंड्रॉइड फ्रेमवर्क अपनी कुछ मूल फ़ाइल हैंडलिंग सुविधाओं के लिए फ़ाइल का उपयोग करता है, कई अन्य चीजें करता है।

Comments

उन्होंने यह नहीं पूछा कि क्या Pathबेहतर था। उन्होंने पूछा कि क्या Fileपदावनत कर दिया गया।

— लोर्न के

@ ईजेपी मुझे लगता है कि आप पांडित्य से थोड़े ज्यादा हैं। ओपी ने पूछा कि क्या java.io.File को अपदस्थ किया गया था और मैंने उत्तर दिया था कि .. उन्होंने यह भी कहा "मेरा मानना ​​है कि java.nio.file.Path सब कुछ java.io.ile कर सकता है। बहुत कुछ कर सकता है।" मैं केवल उनकी टिप्पणी की पुष्टि कर रहा था, यह शायद ही एक वोट के लायक था।

— एंड्रयू एस

Answer 7

जावा 7 में लिखे गए नए अनुप्रयोगों के लिए, java.io.ile ऑब्जेक्ट का उपयोग करने का कोई कारण है या क्या हम इसे पदावनत मान सकते हैं?

यह कहने के लिए थोड़ा सा है: "क्या नेपोलियन को रूस पर आक्रमण करना चाहिए, या ये ब्रसेल्स स्प्राउट्स वास्तव में स्वादिष्ट हैं?"

प्रश्न के दूसरे भाग के रूप में, आप वास्तव में इसे पदावनत मान सकते हैं। जनवरी 2018 तक, यह पदावनत नहीं है। लेकिन वहाँ आप को रोकने के लिए कुछ भी नहीं है पर विचार यह इतना। चाहे वह आपको इस जीवन में किसी भी लाभ की खरीद करेगा या अगला कहना असंभव है।

Comments

मैं आपकी उपमा नहीं समझता।

— तुनकी

किसी भी "या" प्रश्न में दो तार्किक विकल्प प्रस्तुत करने चाहिए, दोनों अनिवार्य रूप से एक ही प्रश्न का उत्तर देते हैं।

— माईक कृंतक

क्षमा करें, यह इस संदर्भ में अत्यधिक पांडित्यपूर्ण लगता है। विचार "मैं उपयोग करना चाहता हूं File। क्या मुझे हां या नहीं करना चाहिए?"

— तुनकी

हाँ, मैं मानता हूँ कि यह एक लोडेड सवाल है ... खासकर तब से जब मौजूदा 3 पार्टी एपीआई का बहुत अधिक उपयोग अभी Fileभी कर रहे हैं। यह जल्द ही कभी भी मरने वाला नहीं है।

— तुनकी

it isn't deprecated. But there's nothing to stop you *considering* it soजबरदस्त हंसी।

— डॉन चेडल