2025 में जावा में वर्तमान निर्देशिका: 3 तरीके और जाल

मैं कहाँ हूँ? या जावा एप्लिकेशन की फ़ाइल सिस्टम में कैसे न खोएँ

हर Java-डेवलपर ने अपने जीवन में कम से कम एक बार यह प्रश्न पूछा है: "वास्तव में, मेरा कोड कहाँ निष्पादित हो रहा है?" ऐसा लगता है कि आप IDE से प्रोग्राम चला रहे हैं, सब कुछ काम करता है। लेकिन जैसे ही आप इसे सर्वर या Docker-कंटेनर में ले जाते हैं — और जो फ़ाइलें jar-फ़ाइल के पास होनी चाहिए थीं, वे /opt/app या /tmp की गहराइयों में कहीं पहुँच जाती हैं। परिचित स्थिति?

प्रश्न "How to get the current working directory in Java?" Stack Overflow पर सबसे लोकप्रिय प्रश्नों में से एक है। और यह व्यर्थ नहीं है: उत्तर स्पष्ट लगता है, लेकिन व्यवहार में इसमें कई छिपे हुए खतरे हैं। इस लेख में हम 2025 की सर्वोत्तम प्रथाओं पर चर्चा करेंगे: current working directory को मज़बूती से कैसे प्राप्त करें, कब इस पर भरोसा किया जा सकता है, और कब विकल्पों की तलाश करना बेहतर है।

अस्वीकरण: लेख Java 17+ (LTS) के लिए लिखा गया है, लेकिन उदाहरण Java 11 और नए संस्करणों के साथ संगत हैं। यदि आप अभी भी Java 8 पर हैं — तुरंत अपडेट करें, लेकिन कोड काम करेगा।

क्लासिक तरीका: System.getProperty("user.dir")

सबसे सरल और व्यापक रूप से उपयोग की जाने वाली विधि — सिस्टम प्रॉपर्टी user.dir तक पहुँचना। यह वही है जो आप Stack Overflow पर 90% उत्तरों में देखेंगे:

public class WorkingDirectoryExample {\n    public static void main(String[] args) {\n        String cwd = System.getProperty("user.dir");\n        System.out.println("वर्तमान निर्देशिका: " + cwd);\n    }\n}

आउटपुट पर आपको क्या मिलेगा? उस फ़ोल्डर का पथ जहाँ से JVM लॉन्च किया गया था। यदि आप प्रोजेक्ट के रूट से चला रहे हैं — तो यह /Users/you/projects/my-app होगा। यदि target/ से — तो target/ होगा।

यह हमेशा विश्वसनीय क्यों नहीं है?

समस्या #1: IDE और बिल्ड-सिस्टम धोखा देते हैं। IntelliJ IDEA डिफ़ॉल्ट रूप से working directory को मॉड्यूल के रूट के बराबर सेट करता है। Maven — प्रोजेक्ट के रूट के बराबर। Gradle — मॉड्यूल के रूट के बराबर। लेकिन इसे लॉन्च कॉन्फ़िगरेशन में ओवरराइड किया जा सकता है। परिणामस्वरूप, स्थानीय मशीन पर कोड काम करता है, लेकिन सर्वर पर नहीं।

समस्या #2: Unit-टेस्ट। JUnit या TestNG के माध्यम से चलाने पर, working directory प्रोजेक्ट का रूट हो सकता है, या बिल्ड फ़ोल्डर हो सकता है। यह रनर की सेटिंग्स पर निर्भर करता है।

समस्या #3: वेब-एप्लिकेशन और माइक्रोसर्विसेज़। कंटेनरों (Tomcat, Jetty) में, working directory अक्सर $CATALINA_HOME/bin या / के बराबर होती है। इसका आपकी WAR-फ़ाइल से कोई संबंध नहीं है।

आधुनिक दृष्टिकोण: java.nio.file.Paths

Java 7 से शुरू करके, हमारे पास NIO.2 API के माध्यम से एक अधिक "जावा-शैली" तरीका है:

import java.nio.file.Paths;\n\npublic class NioWorkingDirectory {\n    public static void main(String[] args) {\n        String cwd = Paths.get("").toAbsolutePath().toString();\n        System.out.println("वर्तमान निर्देशिका (NIO): " + cwd);\n    }\n}

यहाँ क्या हो रहा है? Paths.get("") एक खाली पथ का संदर्भ बनाता है, जिसे वर्तमान निर्देशिका के सापेक्ष पथ के रूप में व्याख्यायित किया जाता है। विधि toAbsolutePath() इसे निरपेक्ष में हल करती है। परिणाम — वही user.dir, लेकिन अधिक सख्त टाइपिंग के साथ।

लाभ:

\n
• Path ऑब्जेक्ट के साथ काम करता है, स्ट्रिंग के साथ नहीं (विभाजकों के साथ कम त्रुटियाँ)
\n
• आधुनिक API में तुरंत उपयोग किया जा सकता है
\n
• क्रॉस-प्लेटफ़ॉर्म (Windows बनाम Linux)
\n

नुकसान: वही — यह अभी भी प्रक्रिया की working directory है।

विकल्प: File("")

उन लोगों के लिए जो NIO पर स्विच नहीं करना चाहते (हालाँकि व्यर्थ):

import java.io.File;\n\npublic class FileWorkingDirectory {\n    public static void main(String[] args) {\n        String cwd = new File("").getAbsolutePath();\n        System.out.println("वर्तमान निर्देशिका (File): " + cwd);\n    }\n}

बिल्कुल वही जो Paths.get("").toAbsolutePa