जावा हमें फ़ाइल नाम से अलग नाम के साथ कक्षा को संकलित करने की अनुमति क्यों देता है?

मेरे पास एक फ़ाइल Test.java और इसके अंदर निम्न कोड है।

public class Abcd
{
        //some code here

}

अब कक्षा संकलित नहीं है, लेकिन जब मैं public संशोधक को हटा देता हूं, तो यह ठीक संकलित करता है।

जावा के पीछे तर्क क्या है जो हमें कक्षा के नाम को संकलित करने की इजाजत देता है जो फ़ाइल नाम से भिन्न होता है जब यह सार्वजनिक नहीं होता है।

मुझे पता है कि यह एक नौसिखिया सवाल है, लेकिन मैं एक अच्छी व्याख्या नहीं पा रहा हूं।

0
दिलचस्प बात यह है कि सी # फ़ाइल के नाम की परवाह नहीं करता है और आपके पास कई शीर्ष-स्तरीय प्रकार हो सकते हैं।
जोड़ा लेखक usr, स्रोत
एक समान प्रश्न की तरह लगता है: stackoverflow.com/questions/7633631/…
जोड़ा लेखक sanket, स्रोत
@ रमेश: इस प्रश्न का शीर्षक और सामग्री बेहतर है .. (अन्य समान लोगों की तुलना में)
जोड़ा लेखक Jayan, स्रोत
इस प्रश्न के लिए इतने सारे उपरोक्त क्यों हैं, सबसे पहले इसके डुप्लिकेट प्रश्न: stackoverflow.com/questions/7633631/…
जोड़ा लेखक G M Ramesh, स्रोत
मुझे संदेह है कि एक "अच्छी व्याख्या" है। यह सार्वजनिक कक्षाओं के लिए एक आवश्यकता थी, लेकिन इसे गैर-सार्वजनिक वर्गों के लिए अनावश्यक समझा जाता था।
जोड़ा लेखक Kayaman, स्रोत
क्योंकि जावा। (क्योंकि यह सार्वजनिक नहीं है, और उसी नामकरण सम्मेलन का पालन नहीं करना है। इसके अलावा, आपको उन लोगों से पूछना होगा जिन्होंने इसका आविष्कार किया था।)
जोड़ा लेखक Dave Newton, स्रोत
जावा फ़ाइल नाम हमेशा उस फ़ाइल के भीतर परिभाषित सार्वजनिक वर्ग को प्रतिबिंबित करना चाहिए। अन्यथा संकलित नहीं किया जा सकता है। आप इसे "सीधी रेखा हमेशा दो अंक" ले सकते हैं।
जोड़ा लेखक Sajmon, स्रोत

8 उत्तर

मुझे लगता है कि उन्हें नेस्टेड कक्षाओं के लिए एक पूर्व शर्त है। अज्ञात वर्ग विशेष रूप से आवश्यक .java फ़ाइलों की संख्या को नाटकीय रूप से कम करते हैं। इसके लिए समर्थन के बिना, आपको अपनी अलग-अलग फाइलों में उपयोग की जाने वाली मुख्य कक्षा से कई अलग-अलग विधि इंटरफ़ेस कार्यान्वयन की आवश्यकता होगी। (मैं विशेष रूप से एक्शन श्रोताओं के बारे में सोच रहा हूं)

ओरेकल की वेबसाइट पर नेस्टेड क्लासेस जावा ट्यूटोरियल में सभी नेस्टेड कक्षाओं का एक अच्छा स्पष्टीकरण है , जिसमें प्रत्येक के उदाहरण हैं। इसका एक कारण भी है कि वे उपयोगी हैं, जो मैं उद्धृत करूंगा:

नेस्टेड क्लासेस का उपयोग क्यों करें?

     

नेस्टेड कक्षाओं का उपयोग करने के लिए आकर्षक कारणों में निम्नलिखित शामिल हैं:

     
      
  • यह तार्किक रूप से वर्गीकृत वर्गों का एक तरीका है जो केवल एक ही स्थान पर उपयोग किया जाता है : यदि कोई वर्ग केवल एक अन्य वर्ग के लिए उपयोगी है, तो उस वर्ग में इसे एम्बेड करना तार्किक है और दोनों को एक साथ रखें। इस तरह के "सहायक वर्ग" नेस्टिंग अपने पैकेज को अधिक सुव्यवस्थित बनाता है।

  •   
  • यह encapsulation बढ़ता है : दो शीर्ष-स्तरीय कक्षाओं, ए और बी पर विचार करें, जहां बी को ए के सदस्यों तक पहुंच की आवश्यकता है जो अन्यथा होंगी   निजी घोषित कक्षा ए के भीतर कक्षा बी छुपाकर, ए के सदस्य हो सकते हैं   घोषित निजी और बी उन्हें एक्सेस कर सकते हैं। इसके अलावा, बी स्वयं ही हो सकता है   बाहरी दुनिया से छिपा हुआ है।

  •   
  • इससे अधिक पठनीय और रखरखाव योग्य कोड हो सकता है : शीर्ष-स्तरीय कक्षाओं के भीतर छोटे वर्गों को घोंसला करना कोड को उस स्थान के करीब रखता है जहां यह है   इस्तेमाल किया।

  •   

(जोर मेरा)

मैं शुरुआती दिनों में जावा स्पेक से परिचित नहीं हूं, लेकिन एक त्वरित खोज से पता चलता है कि आंतरिक कक्षाएं जावा 1.1 में जोड़े गई थीं।

0
जोड़ा
किसी ऐसे मामले में क्या करना चाहिए जहां एक प्रकार केवल दूसरे प्रकार के भीतर उपयोगी हो, लेकिन पूर्व प्रकार के उदाहरण बाद के उदाहरणों से जुड़े नहीं हैं?
जोड़ा लेखक supercat, स्रोत
नेस्टेड क्लास जावा 1.2 लैंबडा करने का तरीका है या 'सब कुछ एक ऑब्जेक्ट है जब' प्रथम श्रेणी के कार्य '। यह 1.8 सिंटेक्स में बदल रहा है। जब हम जावा के टाइप सिस्टम में बीजगणित डेटा प्रकार मॉडल करना चाहते हैं तो उनका भी उपयोग किया जाता है।
जोड़ा लेखक hawkeye, स्रोत

कारण दरवाजे की प्लेटों के समान ही है। अगर कुछ व्यक्ति आधिकारिक तौर पर कार्यालय में रहता है (घोषित सार्वजनिक) उसका नाम दरवाजा टैग पर होना चाहिए। "एलेक्स जोन्स" या "जासूस कोलंबो" की तरह। अगर कोई सिर्फ कमरे में जाता है, किसी आधिकारिक से बात करता है या फर्श को साफ करता है, तो उनके नाम को आधिकारिक तौर पर दरवाजे पर नहीं रखा जाना चाहिए। इसके बजाए, दरवाजा "उपयोगिता" या "बैठक कक्ष" पढ़ सकता है।

Official name or MyClass.java Meeting room or Test.java

0
जोड़ा
@AndrewBarber, समरूपता पूरी तरह से निर्देशिका के विचार को फिट करती है, लंबे गलियारे में आप दरवाजे की प्लेटों पर सिर्फ चमककर एक व्यक्ति को तुरंत ढूंढ सकते हैं, आपको प्रत्येक कमरे में प्रवेश करने और पूछने की आवश्यकता नहीं है।
जोड़ा लेखक exebook, स्रोत
@MarkoTopolnik मुझे इसमें शामिल नहीं होना चाहिए था; मैं समरूपता में कक्षा-ए भयानक हूं! ;)
जोड़ा लेखक Andrew Barber, स्रोत
निश्चित रूप से एक दिलचस्प सादृश्य; यह थोड़ा सा स्पष्टीकरण के साथ भी बेहतर हो सकता है कि यह सीधे कैसे संबंधित है। ओपी को कनेक्शन बनाने में कुछ कठिनाई हो सकती है (हालांकि मैं इसे पूरी तरह से समझता हूं)
जोड़ा लेखक Andrew Barber, स्रोत
@AndrewBarber मैं इसे लिखना चाहता था, वैसे भी; आपने अभी एक धक्का दिया :) समानता भी सबसे गंभीर चिंता व्यक्त करने में विफल रहता है: केवल इस सुविधा के कारण संकलक को सभी कक्षाओं को खोजने के लिए सभी फाइलों को पार्स करना चाहिए, अन्यथा यह केवल निर्देशिका सूची को पढ़ सकता है और सभी के नामों को जान सकता है शीर्ष स्तर के वर्ग।
जोड़ा लेखक Marko Topolnik, स्रोत
@AndrewBarber मुझे नहीं लगता कि समानता वास्तव में फिट बैठती है क्योंकि यह एक सार्वजनिक वर्ग का मॉडल नहीं करती है, फाइल को कई पैकेज-निजी कक्षाओं के साथ साझा करती है। यह दरवाजा प्लेट की तरह है "हीदर सैंटी, प्रबंधक" पढ़ रहा है, लेकिन कमरे में वास्तव में हीदर और उसके दो सचिव शामिल हैं।
जोड़ा लेखक Marko Topolnik, स्रोत
+1 अच्छा सादृश्य। वास्तव में मुझे इस तरह के औचित्य से प्यार है।
जोड़ा लेखक mok, स्रोत

ध्यान दें कि जावा केस-संवेदी है, लेकिन फाइल सिस्टम की आवश्यकता नहीं है। यदि फ़ाइल का मूल नाम "abcd" है, लेकिन कक्षा "एबीसीडी" है, तो क्या यह केस-असंवेदनशील फाइल सिस्टम पर नियम के अनुरूप होगी? निश्चित रूप से जब किसी मामले-संवेदनशील व्यक्ति को पोर्ट नहीं किया जाता है।

या मान लीजिए कि आपके पास एबीसीडी नामक एक कक्षा है, और एक कक्षा एबीसीडी (चलो इसे एक बुरा विचार नहीं है: यह हो सकता है) और कार्यक्रम एक केस असंवेदनशील फाइल सिस्टम में पोर्ट किया गया है। अब आपको न केवल फाइलों का नाम बदलना है, बल्कि कक्षाओं, ओह!

या अगर कोई फ़ाइल नहीं है तो क्या होगा? मान लें कि आपके पास जावा कंपाइलर है जो मानक इनपुट पर इनपुट ले सकता है। तो फिर कक्षा को "मानक इनपुट" नाम दिया जाना चाहिए?

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

0
जोड़ा
मैं जो कहता हूं उससे सहमत हूं, लेकिन मुझे नहीं पता कि यह विशेष रूप से इस हद तक प्रश्न का उत्तर देता है कि नामकरण वास्तुकला के परिणामस्वरूप कुछ समस्याएं गैर-सार्वजनिक वर्ग के नामों से अलग होने की अनुमति दे सकती हैं फ़ाइल नाम बीटीडब्लू, केस-सेंसिटीविटी के संबंध में, यदि मैं किसी भी क्षेत्र में कोई भाषा प्राप्त कर रहा था, तो Foo घोषित किया गया था, पहचानकर्ता <कोड> FOO , foo , foo , आदि सभी बाहरी क्षेत्रों में मौजूद होने पर भी "अपरिभाषित" होंगे। ऐसा डिज़ाइन फ़ाइल नामों के लिए केस-सेंसिटीविटी समस्या को खत्म कर देगा।
जोड़ा लेखक supercat, स्रोत

जावा विनिर्देश बताता है कि प्रति फ़ाइल में केवल एक ही सार्वजनिक कक्षा में ही हो सकता है। इस मामले में, वर्ग का नाम फ़ाइल नाम से मेल खाना चाहिए। फ़ाइल नाम के बावजूद सभी गैर-सार्वजनिक वर्गों का कोई नाम होने की अनुमति है।

0
जोड़ा
@ मार्कोटोपोलनिक: कोड का उपयोग करने वाले कोड के पास स्थित घोषणाएं अक्सर रखरखाव को कम कर सकती हैं। यदि कोई वर्ग कुछ सार्वजनिक क्षेत्रों के उद्देश्य के लिए पूरी तरह से मौजूद है, और फ़ील्ड के अर्थशास्त्र उन कोडों द्वारा निर्धारित किए जाते हैं जो उन्हें पढ़ते हैं और लिखते हैं, तो उस वर्ग को उसी फ़ाइल में होना चाहिए जो कोड पढ़ता है और लिखता है रखरखाव को फ़ाइल में रखने से आसान है।
जोड़ा लेखक supercat, स्रोत
आपको अनुमति है। लेकिन आप फ़ाइल नाम के अनुसार उन्हें नाम देने के लिए बाध्य नहीं हैं।
जोड़ा लेखक Andrei Nicusan, स्रोत
खैर, अगर विपरीत मामले के लिए बाधा लगा दी गई थी, तो किसी को प्रति फ़ाइल एक से अधिक कक्षा घोषित करने की अनुमति नहीं दी जाएगी (क्योंकि इसका मतलब यह होगा कि नामकरण बाधा सभी प्रकार के वर्गों पर लगाई जाएगी, भले ही सार्वजनिक या गैर सार्वजनिक)।
जोड़ा लेखक Andrei Nicusan, स्रोत
मेरे 2 सेंट: शायद इसे क्लासपाथ के अंदर कक्षाओं के त्वरित स्थानीयकरण के लिए इस तरह से डिजाइन किया गया था। इस सम्मेलन के साथ, फ़ाइल खोज/पथ का निरीक्षण कक्षा की खोज के लिए पर्याप्त है। इस सम्मेलन के बिना, क्लासपाथ क्लास लोडर को कक्षाएं खोजने के लिए फ़ाइलों को खोलने और पार्स करने की आवश्यकता हो सकती है
जोड़ा लेखक Andrei Nicusan, स्रोत
लेकिन "जावा के पीछे तर्क क्या है" हमें यह?
जोड़ा लेखक Marko Topolnik, स्रोत
@ isnot2bad आपका तर्क केवल तभी समझ में आता है जब आप स्पष्ट रूप से यह मानते हैं कि जावा प्रति फ़ाइल एक से अधिक कक्षाओं की अनुमति देता है। हालांकि, सवाल यह है कि, यदि जावा के पास पहले से ही एक सार्वजनिक वर्ग के एक सार्वजनिक वर्ग का प्रतिबंध है, तो उसके पास प्रति फ़ाइल अधिक गैर-सार्वजनिक कक्षाओं का अतिरिक्त प्रावधान क्यों है। यह एक ही फ़ाइल में बिल्कुल में अधिक कक्षाओं की अनुमति क्यों देता है?
जोड़ा लेखक Marko Topolnik, स्रोत
@AndreiNicusan यह तर्क देने का तर्क है कि एक सार्वजनिक वर्ग अपनी फाइल में होना चाहिए। प्रश्न विपरीत मामले के लिए तर्क के बारे में है।
जोड़ा लेखक Marko Topolnik, स्रोत
@ isnot2bad क्या आप कह रहे हैं कि हम नहीं पैकेज-निजी क्लासिस को अपनी फ़ाइल में घोषित करने की अनुमति दे रहे हैं?
जोड़ा लेखक Marko Topolnik, स्रोत
@MarounMaroun लेकिन हमें रोकने के पीछे तर्क क्या है?
जोड़ा लेखक Marko Topolnik, स्रोत
@MarkoTopolnik क्योंकि यह हमें नहीं रोकता है: डी
जोड़ा लेखक Maroun, स्रोत
@MarkoTopolnik हाँ, यकीन है। लेकिन मुझसे नहीं पूछा गया था। और यहां तक ​​कि अगर यह थे - आप पहले ही जवाब दे चुके हैं।
जोड़ा लेखक isnot2bad, स्रोत
@MarkoTopolnik नहीं, मैं बस इतना कहता हूं कि केवल एक वर्ग सार्वजनिक हो सकता है। बेशक, सार्वजनिक कक्षा होने की आवश्यकता नहीं है। लेकिन चूंकि सभी वर्गों में अद्वितीय नाम होना चाहिए, केवल एक फ़ाइल नाम से मेल खाता है, और वह सार्वजनिक वर्ग है (यदि कोई है ...)
जोड़ा लेखक isnot2bad, स्रोत
@ मार्को जावा एक ही फ़ाइल में परिभाषित कई वर्गों की अनुमति देता है (जब तक कि उनमें से केवल एक ही सार्वजनिक हो)। चूंकि एक ही पैकेज के सभी वर्गों का एक अलग नाम होना चाहिए, गैर-सार्वजनिक वर्गों को फ़ाइल नाम के अलावा अन्य नाम रखने की अनुमति देने के अलावा कोई अन्य विकल्प नहीं है।
जोड़ा लेखक isnot2bad, स्रोत

तर्क एक .java फ़ाइल प्रति एक से अधिक शीर्ष-स्तरीय वर्ग की अनुमति देना है।

Many classes—such as event listeners—are of local use only and the earliest versions of Java did not support nested classes. Without this relaxation of the "filename = class name" rule, each and every such class would have required its own file, with the unavoidable result of endless proliferation of small .java files and the scattering of tightly coupled code.

जैसे ही जावा ने नेस्टेड कक्षाएं शुरू कीं, इस नियम का महत्व काफी हद तक कम हो गया। आज आप कई सैकड़ों जावा फाइलों के माध्यम से जा सकते हैं, कभी इसका पीछा नहीं करते जो इसका लाभ उठाते हैं।

0
जोड़ा
@ वैल इनकार करते हैं कि अन्य लोग एक टेक्स्ट एडिटर और सीएलआई टूल्स का विकास करने के लिए उपयोग करेंगे क्योंकि आप जिस आईडीई को पसंद करते हैं वह सिर्फ मूर्खतापूर्ण है क्योंकि यह कहने के लिए आईडीई बनाने में कोई बात नहीं है क्योंकि आप उनके बिना विकास कर सकते हैं। गुणवत्ता कोड बनाने के लिए दोनों दृष्टिकोण अच्छे डेवलपर्स द्वारा उपयोग किए जाते हैं; और उनमें से एक को सुलझाने और कुम्बाया गाते हुए सभी डेवलपर्स की बाधाओं की तुलना में एकमात्र चीज यह है कि हम सभी सहमत होंगे कि सबसे अच्छी प्रोग्रामिंग भाषा क्या है।
जोड़ा लेखक Dan Neely, स्रोत
@MarkoTopolnik आप शीर्ष-स्तर कक्षा को कैसे परिभाषित करते हैं?
जोड़ा लेखक Geek, स्रोत
@ वैल: कुछ प्रोग्रामर कई भाषाओं में कोड विकसित करते हैं; कुछ मामलों में, प्रोग्रामर के लिए प्रत्येक भाषा के लिए एक अलग आईडीई का उपयोग करने के बजाय प्रत्येक भाषा के लिए एक आईडीई का उपयोग करना आसान हो सकता है।
जोड़ा लेखक supercat, स्रोत
ऐतिहासिक जानकारी के लिए +1 विशेष रूप से - मुझे संदेह है कि नेस्टेड/गुमनाम वर्गों के आगमन के साथ, यदि वही निर्णय अब किया जाना चाहिए (पिछली संगतता की देखभाल नहीं करना) तो यह केवल एक शीर्ष स्तर की कक्षा को अनुमति देने के लिए और अधिक समझदार होगा फ़ाइल।
जोड़ा लेखक Michael Berry, स्रोत
@Val आईडीई के साथ मेरा अनुभव, अपवाद के बिना , पिछले 15 वर्षों में - और मैं उन्हें कोशिश करता रहता हूं, क्योंकि क्रॉस-रेफरेंसिंग वे सुनिश्चित करते हैं कि चमकदार दिखती है - (ए) वे लगातार अंतराल में हैं मेरे पीछे एक अच्छा आधे दर्जन अक्षर, और (बी) अगर वे नॉनट्रिविअल आकार की परियोजनाओं को लोड करने के लिए कहा जाता है तो वे दुर्घटनाग्रस्त हो जाते हैं। यह कि आपका लाभ भिन्न होता है इसका मतलब यह नहीं है कि मैं अपने अनुभव के बारे में झूठ बोल रहा हूं। नोट: "नॉनट्रिविअल साइज" का मेरा विचार कोड की लाखों लाइनों में मापा जाता है, क्योंकि यह काम करने के लिए मुझे किराए पर लिया जाता है।
जोड़ा लेखक zwol, स्रोत
Emacs (या विम, अपने जहर उठाओ) का संयोजन और यूनिक्स शैल उपयोगिताओं शायद एक आधुनिक आईडीई के रूप में सब कुछ पर अपनी उंगलियों के रूप में नहीं हैं, और वे सीखने के लिए निश्चित रूप से कठिन हैं, लेकिन उनके पास दो जबरदस्त है हर आईडीई की तुलना में फायदे मैंने कभी कोशिश की है: वे कभी भी क्रैश नहीं होते हैं, इससे कोई फर्क नहीं पड़ता कि कोडबेस कितना बड़ा है, और वे मेरे टाइपिंग के साथ रह सकते हैं।
जोड़ा लेखक zwol, स्रोत
रिकॉर्ड के लिए, यह मेरा मापन है जबकि एक प्रोजेक्ट (केवल 200 केएलओसी, स्वीकार्य रूप से) ग्रहण में खुला है: 250 डब्ल्यूपीएम 10 सेकंड से अधिक रहता है, कोई अंतराल नहीं।
जोड़ा लेखक Marko Topolnik, स्रोत
@geek यह एक वर्ग के लिए मानक शब्द है जो किसी अन्य वर्ग के भीतर निहित नहीं है।
जोड़ा लेखक Marko Topolnik, स्रोत
@DanielPryden आईडीई दर्दनाक रूप से शुरू करने के लिए धीमे हैं, लेकिन मैंने कभी भी उनमें से किसी को भी (या किसी और के) टाइपिंग के पीछे पीछे नहीं देखा है। ग्रहण भी अधिकांश रिफैक्टरिंग को इतनी तेजी से चलाता है कि मैं उन्हें संपादन कोड का एक त्वरित तरीका के रूप में उपयोग करता हूं।
जोड़ा लेखक Marko Topolnik, स्रोत
@val यह वास्तव में डेव था जो grep के बारे में बात कर रहा था, लेकिन वह उसी grep के बारे में बात कर रहा था जो मैं, और दुनिया भर के लाखों लोग हर दिन उपयोग करते हैं।
जोड़ा लेखक Marko Topolnik, स्रोत
@ डेव न्यूटन यहां हम जावा पर "सरल" डिज़ाइन आवश्यकता को पूरा करते हैं। कक्षाओं को परिभाषित करने की आजादी देना कहीं भी समझदारी से करने की ज़िम्मेदारी लाता है।
जोड़ा लेखक Marko Topolnik, स्रोत
@geek मुझे एक आधिकारिक परिभाषा शब्द शीर्ष-स्तरीय वर्ग और यह जो मैं ऊपर बताता हूं उससे भिन्न है: कक्षाएं जो स्थिर वर्ग के सदस्य हैं और कक्षाएं हैं जो पैकेज सदस्य हैं, दोनों को शीर्ष-स्तरीय कक्षाएं कहा जाता है।
जोड़ा लेखक Marko Topolnik, स्रोत
@ berry120 काफी संभवतः, क्योंकि यह भत्ता संकलन करते समय फ़ाइल खोज को जटिल बनाता है।
जोड़ा लेखक Marko Topolnik, स्रोत
@MarkoTopolnik और मनुष्यों द्वारा कक्षा की खोज, हालांकि मैं अभी भी कहता हूं कि खोज के दौरान grep/ack आपके सबसे अच्छे दोस्त हैं।
जोड़ा लेखक Dave Newton, स्रोत
+1, यह वास्तव में एक कारण प्रदान करता है, जो प्रश्न है।
जोड़ा लेखक Dave Newton, स्रोत
@ वैल: मुझे पता है कि कुछ बेहतरीन प्रोग्रामर किसी भी आईडीई को Emacs पसंद करते हैं। अब, मैं सहमत हूं कि इंटेलिजे आईडीईए जावा कोड विकसित करने के लिए एक उत्कृष्ट आईडीई है, लेकिन इसका मतलब यह नहीं है कि ऐसा करने का यही एकमात्र तरीका है। यह नियंत्रण सिद्धांत के उलझन की तरह है: कभी-कभी आप एक ढांचे (आईडीई) में कोड लिखना चाहते हैं, अन्य बार आप केवल लाइब्रेरी (संपादक) चाहते हैं। त्वरित संपादन कार्यों के लिए, मुझे लगता है कि विम एक बड़ी आईडीई की तुलना में तेज़ और आसान है, और यह स्थानीय रूप से एसएसएच पर भी काम करता है। एक्लिप्स और इंटेलिजे निश्चित रूप से उच्च अंत हार्डवेयर पर भी तेज नहीं हैं, खासकर एक बड
जोड़ा लेखक Daniel Pryden, स्रोत
दुर्भाग्यवश, मैं प्रश्न नहीं बना सकता (प्रोग्रामर.se? में)। अन्यथा, मैं यह पूछना चाहूंगा कि जावा आईडीई वास्तव में प्रोग्रामर की टाइपिंग गति को सीमित करता है या नहीं। वे पृष्ठभूमि मोड में संकलित लगते हैं। तो, मेरा मानना ​​है कि आईडीई की गति सीमा एक निंदा है। दूसरा, यह कहकर कि आईडीई छोटी हैं और पाठ संपादकों के विरोध में असफल एक शुद्ध हेरफेर है। मैंने 10 वर्षों तक उनके साथ काम किया है और मुझे याद नहीं है कि वे असफल हो रहे हैं। तो, दर्पण देता है: आईडीई इमेक्स के विपरीत बग-फ्री और स्थिर हैं। ठीक? हमें यह दिखाने के लिए धन्यवाद कि अच्छे जावा डेवलपर्स वे हैं जो निंदा और गंदे जोड़ों को फैलाते हैं।
जोड़ा लेखक Val, स्रोत
क्या आपका मतलब है कि जावा विकास के लिए डिज़ाइन-टू-जावा आईडीई (जिसमें आपका टेक्स्ट एडिटर भी शामिल है) के बजाय टेक्स्ट एडिटर का उपयोग करने के फायदे हैं? क्या आपका मतलब है कि टेक्स्ट खोज में आईडीई-आधारित क्लास घोषणा (डेटाबेस) लुकअप पर फायदे हैं? "आपका पसंदीदा आईडीई" क्या है? क्या यह कहना एक मजबूत तर्क है कि आपका सादा पाठ संपादक पूर्णतया जावा आईडीई से कम नहीं है? मैं समझता हूं कि "अच्छे डेवलपर" निम्न-स्तरीय प्रोग्रामिंग का उपयोग करते हैं: उनके पास कोई विकल्प नहीं है। फिर भी, आईडीई सभी मानकों द्वारा सादा पाठ संपादक से बेहतर प्रदर्शन करता है और यह एक साधारण तथ्य है। यह "मेरी वरीयता" नहीं है।
जोड़ा लेखक Val, स्रोत
@MarkoTopolnik चलो, हम यहां 21 शताब्दी में हैं, इंटेलिजे आइडिया ने अपना 13 वां जन्मदिन मनाया है। आप किस grep के बारे में बात कर रहे हैं?
जोड़ा लेखक Val, स्रोत

मैं इसे दूसरी तरफ देखता हूं। मामलों की प्राकृतिक स्थिति प्रोग्रामर के लिए कक्षा के नाम और फ़ाइल नाम दोनों को स्वतंत्र रूप से चुनने के लिए होगी। शायद संकलन के दौरान पैकेज के बाहर से सार्वजनिक कक्षाओं को खोजने में आसान बनाने के लिए, एक विशेष प्रतिबंध है कि एक सार्वजनिक वर्ग संबंधित नाम वाली फ़ाइल में हो।

0
जोड़ा

यह भी एक अन्य बिंदु है कि कई उत्तरों को इंगित करने के लिए याद किया गया है कि public घोषणा के बिना, JVM कभी नहीं जानता कि किन वर्गों की मुख्य विधि को लागू करने की आवश्यकता है। एक .java फ़ाइल में घोषित सभी वर्गों में सभी मुख्य विधियां हो सकती हैं, लेकिन मुख्य विधि केवल सार्वजनिक रूप से चिह्नित कक्षा पर चलती है। HTH

0
जोड़ा

जावा फ़ाइल की वजह से एक से अधिक कक्षाएं हो सकती हैं, इसमें एक जावा फ़ाइल में दो कक्षाएं हो सकती हैं। लेकिन एक जावा फ़ाइल में एक वर्ग को फ़ाइल नाम के समान नाम होना चाहिए यदि इसमें कोई सार्वजनिक वर्ग है।

0
जोड़ा
नहीं, वह नियम केवल सार्वजनिक वर्गों के लिए लागू है।
जोड़ा लेखक Evin Ugur, स्रोत