Public static void main(String[] args) अब खत्म

• अब Java का पहला प्रोग्राम public static void main(String[] args) से शुरू करना ज़रूरी नहीं है, और इसे सरल void main() सिंटैक्स में लिखा जा सकता है
• नए सिंटैक्स में IO.readln और IO.println जैसे सरल कॉल्स से ही इनपुट-आउटपुट संभाला जा सकता है, जिससे कोड पहले से कहीं ज़्यादा सहज हो जाता है
• new Scanner(System.in), System.out.println जैसी पुरानी और लंबी लिखावट अब अनावश्यक हो जाती है
• अब तक की असुविधा “आखिरकार खत्म” हो गई है, और Java की बुनियादी संरचना हल्की होने से एंट्री बैरियर कम होगा और सीखना अधिक आसान बनेगा

---

• पारंपरिक रूप से Java में प्रोग्राम शुरू करने के लिए public static void main(String[] args) जैसी लंबी घोषणा की ज़रूरत होती थी
• लेकिन 16 सितंबर 2025 तक, Java के सबसे शुरुआती उदाहरण माने जाने वाले main फ़ंक्शन की यह जटिल घोषणा एक नए सरल रूप से बदल दी गई है
• पुराना तरीका:

  public class Main {  
      public static void main(String[] args) {  
          Scanner scanner = new Scanner(System.in);  
          System.out.print("What is your name? ");  
          String name = scanner.nextLine();  
          System.out.println("Hello, " + name);  
      }  
  }  
  

• नया तरीका:

  void main() {  
      var name = IO.readln("What is your name? ");  
      IO.println("Hello, " + name);  
  }  
  

• लंबे समय से इसकी आलोचना होती रही थी कि यह शुरुआती सीखने वालों के लिए बेवजह लंबा है और ऐसा वाक्यांश है जिसे किसी “जादुई मंत्र” की तरह रटना पड़ता है
• पुरानी घोषणा की झंझट और जटिलता को हटाकर, संक्षिप्त सिंटैक्स लाने से कोड की पठनीयता बेहतर हुई है और Java सीखना शुरू करने की बाधा काफी कम हो गई है
  • अब Scanner, System.out.println जैसे जटिल ऑब्जेक्ट निर्माण और कॉल्स को बेसिक उदाहरण के रूप में इस्तेमाल नहीं किया जाएगा

Good Fucking Riddance = “आखिरकार इससे छुटकारा मिला, अच्छा हुआ यह गया”

[kayws426]

ऐसा लगता है जैसे सिर्फ इसलिए कहा जा रहा है कि पुराना तरीका खत्म हो गया, क्योंकि एक नया तरीका आ गया है.
क्या सच में पुराने तरीके का अब इस्तेमाल नहीं किया जा सकता और सिर्फ नया तरीका ही इस्तेमाल करना होगा?

[jhk0530]

वाह

[jwh926]

क्या मुझे Java फिर से सीखना चाहिए..

[carnoxen]

main मर चुका है। main अमर रहे!

[GN⁺]

Hacker News राय

• समय के साथ ऐसे अजनबी कोड को धीरे-धीरे समझने की प्रक्रिया शायद याद आएगी। जब मैंने पहले Python सीखी और फिर Java पर गया, तब मुझे समझ नहीं आता था कि void या String[] जैसे types का मतलब क्या है, और वही बात मुझे रोचक लगती थी। types सीखने के बाद बात समझ में आने लगी, फिर class और object की अवधारणाएँ, और यह भी कि main एक static method के रूप में क्यों मौजूद है। और गहराई में जाने पर यह भी सीखा कि इस class को कब call किया जाता है, तो जो कोड शुरू में सिर्फ boilerplate लगता था वह धीरे-धीरे अर्थपूर्ण लगने लगा। शायद मुझसे ज़्यादा अनुभवी Java developers एक ही पंक्ति में मुझसे कहीं अधिक अर्थ पढ़ लेते होंगे। फिर भी अब इसके हटने से राहत मिलती है

  • सच में बहुत राहत मिलती है। पिछले 30 वर्षों में software education ने developers को 'engineering' के नाम पर बेकार की complexity पैदा करना सिखाया है। उदाहरण के लिए, developer A entry point, callback, interface वगैरह किसी भी ज़रूरत के लिए class बना देता है। नतीजा यह कि हमारे पास class आ जाती है। developer B उसमें instance variables जोड़कर सब कुछ mutable बना देता है, और इससे "implementation का कीचड़" बन जाता है। फिर कोई और developer code reuse के लिए inheritance जोड़ता है, जिससे और complexity और dynamic dispatch के दुःस्वप्न पैदा होते हैं। अंत में reference cycle बन जाते हैं और objects के आपसी रिश्ते उलझ जाते हैं। समय के साथ refactoring और मुश्किल व झंझटभरी होती जाती है, और आख़िर में code मिटाकर फिर से शुरू करना पड़ता है

  • याद है कि जब मैंने विश्वविद्यालय में पहली बार programming सीखी थी, तब यह कोड देखकर professor ने कहा था, "आम तौर पर मैं कोड की हर चीज़ समझाऊँगा, लेकिन इस हिस्से को अभी बस मान लो।" बाद में जब पीछे मुड़कर देखा और महसूस किया कि मैं उस कोड को पूरी तरह समझता हूँ, तो वह काफ़ी शानदार अनुभव था। फिर भी अब लगता है कि समय बदल रहा है, और उससे सुकून मिलता है

  • असल में static class method इस बात से लगभग इनकार जैसा है कि किसी program का single entry point ज़रूरी नहीं कि class से जुड़ा हो। C++ ही नहीं, Python और Ruby जैसी भाषाएँ भी procedural reality को स्वीकार करती हैं, लेकिन Java मानो उपयोगकर्ता की आँखों पर पट्टी बाँधकर उसे "perfect OOP world" में धकेलना चाहता है

  • पुराने class-based तरीके को जानने वाले के नज़रिए से नया style (जैसे Java 21 की unnamed classes) और ज़्यादा सवाल खड़े करता है। क्या यह सचमुच "everything is an object" वाले Java को procedural language में बदल रहा है? अगर command-line arguments चाहिए हों तो क्या होगा, यह जानने की जिज्ञासा है। मैं आम तौर पर Java से बचता रहा हूँ, इसलिए ज़्यादा नहीं जानता, लेकिन यह सवाल मैं सच में जानने के लिए पूछ रहा हूँ

• Java 1.2 के ज़माने में standard input इस तरह पढ़ा जाता था। Scanner class मेरे लिए नई है, इसलिए अजीब लगती है

BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String input = in.readLine();

• मेरा अनुभव भी कुछ ऐसा ही है। बहुत पहले Java इस्तेमाल करते-करते public static void main pattern तो परिचित हो गया था, लेकिन Scanner का इस्तेमाल अटपटा लगता था, इसलिए उसकी वजह ठीक से समझ नहीं पाता था

• मेरे अनुभव में, मैं बड़े projects पर दशकों से काम करता आया हूँ, इसलिए main function कैसे लिखा है, इसका मेरी रोज़मर्रा की ज़िंदगी या career पर बिल्कुल असर नहीं पड़ता। जिज्ञासा यह है कि आप लोगों को लगता है यह बदलाव वास्तव में कितना असर डालेगा

  • अगर आप Android developer हैं, तो main की अवधारणा ही नहीं थी। सच कहूँ तो, सिर्फ़ trivial Hello World की बदसूरत implementation से यह नहीं मापना चाहिए कि वह language बाकी चीज़ों को कितना अच्छी तरह संभालती है

  • बहुत से लोगों ने Java से programming शुरू करते हुए main को दर्जनों बार टाइप किया, लेकिन उन्हें यह बिल्कुल नहीं पता था कि उसका मतलब क्या है

  • working developers के लिए इसका बहुत बड़ा असर नहीं है, लेकिन beginners के लिए यह महत्वपूर्ण मुद्दा है। मैंने पहले Java पढ़ाई है, और "Hello, World" प्रिंट करने से पहले याद करनी पड़ने वाली जादुई पंक्ति (boilerplate) छात्रों के लिए entry barrier बन जाती थी

  • अगर आप command-line interface बना रहे हों तो असर पड़ सकता है, लेकिन Java में CLI बनाना बहुत आम नहीं है

  • पिछले लगभग 5 साल में मैंने codebase में main देखा ही नहीं है। और मैं शायद ही कभी नई class सीधे बनाता हूँ; आम तौर पर framework-specific classes को implement या extend करता हूँ

• JEP 445: Unnamed Classes and Instance Main Methods Java 21 में release हुआ
  https://openjdk.org/jeps/445

  • अफ़सोस की बात यह है कि यह feature सिर्फ single-file programs में ही इस्तेमाल हो सके, यह निराशाजनक है। अगर package-level methods या एक ही file में कई classes/records रखने की अनुमति मिलती, तो Java और बेहतर हो सकता था। लेकिन लगता है वे किसी भी हालत में "Java code आम तौर पर लिखने के तरीके पर असर" नहीं डालना चाहते थे

• यह देखना हैरान करने वाला है कि 30 साल बाद Java आख़िरकार काफ़ी अच्छी language में evolve हो रहा है

  • मैंने framework के बिना सीधे Java और C++ में बहुत code लिखा है, और उस समय boilerplate कहीं कम और सरल था। असली सुविधा मुझे लगभग 10 साल पहले महसूस हुई जब lambda जोड़ा गया। lambda आने के बाद code की मात्रा घटी और अनुभव काफ़ी सुखद हो गया। Java लंबे समय तक बेहद explicit रहा, और उसमें ऐसी बहुत दोहराव वाली चीज़ें थीं जो मानो मामूली बातों में सिर्फ typo check करने के लिए हों। Kotlin के उभरने से पहले तक माहौल कुछ ऐसा ही था, लेकिन बाद में lambda और anonymous class जैसी चीज़ों से development experience काफ़ी बेहतर हुआ

  • यह कहना कि Java एक भयानक language थी, बहुत बढ़ा-चढ़ाकर कहा गया दावा है

  • दूसरी तरफ़, मुझे लगता है कि Python जैसी language 30 साल बाद भी अब भी असुविधाजनक है

  • शायद आपने सचमुच बहुत बुरी languages का अनुभव नहीं किया, या फिर "भयानक नहीं" का आपका मानदंड बहुत ऊँचा है

  • फिर भी Java की शानदार backward compatibility और package management system काफ़ी प्रभावशाली हैं

• जैसा कि पिछले comment में कहा गया था, Java developer के रूप में Python मुझे उलटा अजीब लगता है, लेकिन मैं नहीं मानता कि मौजूदा तरीका बुरा है। हाँ, अगर abstraction की बुनियाद समझे बिना सीधे programming शुरू की जाए, तो यह "programming की शुरुआत" के लिए अच्छा विकल्प नहीं हो सकता। जब कोई tool purpose-oriented, paradigm-oriented वगैरह तरीके से डिज़ाइन किया जाता है, तो कभी-कभी उसमें extreme abstraction आ सकती है। Java OOP पर केंद्रित होकर डिज़ाइन की गई है, इसलिए interface जैसे block-level सोच का वहाँ स्वाभाविक होना है। methods/classes के access modifiers भी साफ़ तौर पर इस आधार पर अलग किए गए हैं कि वे किसके लिए हैं (public, protected, default, private आदि)। यानी Java में प्रवेश, उपयोगकर्ता (programmer) की ओर मुख किए interface के exposure से शुरू होता है। यह अजीब लग सकता है, लेकिन कम-से-कम इसमें consistency है

  • भारी syntax का OOP से सीधा संबंध नहीं है। Java के आने से पहले OOP की किसी भी परिभाषा ने यह नहीं कहा था कि "functions class के बाहर मौजूद नहीं हो सकतीं"। Sun ने लंबे समय तक standalone functions की अवधारणा को ठुकराया (static import Java 5 में, closures Java 8 में, compact source files/instance main अब जाकर आए), और नतीजतन आज भी सभी functions class के अंदर ही हैं (व्यावहारिकता और compatibility की वजह से, दार्शनिक कारणों से नहीं)। उसने "everything is an object" पर अड़े रहने की कोशिश की, लेकिन व्यवहार में primitive values लाकर खुद ही विरोधाभास पैदा किया। functions का class के अंदर होना कोई व्यावहारिक लाभ नहीं देता। उलटे, अगर integer जैसी values पर methods define की जा सकतीं तो बेहतर होता। वैसे, Smalltalk जैसी "pure OOP" language में class के बाहर भी functions आज़ादी से define की जा सकती हैं और REPL में भी सीधे code चलाया जा सकता है
    संबंधित लिंक

  • Hello World महत्वपूर्ण इसलिए है, क्योंकि यह program चलाने के लिए ज़रूरी boilerplate और असली output code दोनों को एक साथ दिखा सकता है। और build tool configuration के नज़रिए से देखें तो, कुछ चीज़ें 'boilerplate' से ज़्यादा अभ्यास/टूल सेटअप की प्रक्रिया भी हैं। अगर यह बात शुरू में ही समझा दी जाए, तो बड़ी समस्या नहीं होती

• अगर compiler किसी trick से अंदरूनी तौर पर class बना रहा है, तो यह सिर्फ़ दिखावटी बदलाव होगा। अगर दूसरे top-level functions अब भी allowed नहीं हैं, तो यह आख़िरकार सिर्फ़ एक special case ही रहेगा, इसलिए अटपटा ही लगेगा

  • C# 9.0 से top level statements को support करता है, लेकिन अंततः वे अंदर से static method में बदल जाते हैं। कई top level functions भी कुछ ऐसा ही करती हैं। वास्तविक उदाहरण: C# decompiled example
    ऐसी tricks वास्तव में उपयोगी compiler transformations के उदाहरण हैं (closure, async state machine आदि)। यह बदलाव भी वैसा ही है

  • C/C++ में सिर्फ main() पर default return 0 लागू होना भी कुछ वैसा ही अटपटा लगता है

  • अगर सिर्फ main को ही top-level function के रूप में allow किया जाए और बाकी सब असंभव हो, तो मुझे यह भी बहुत अच्छा बदलाव नहीं लगता

• समझ नहीं आता कि Java code examples में import lines को क्यों छोड़ा जाता है। अगर boilerplate की complexity दिखानी है, तो import भी ज़रूर लिखना चाहिए

  • आम तौर पर IDE import को अपने-आप manage कर देता है, इसलिए लोग इस पर ध्यान नहीं देते। IO से जुड़े classes हों तो compact example में अलग import की ज़रूरत नहीं पड़ती, इसलिए कोड वास्तव में ऐसे ही काम करता है

  • ज़्यादातर Java IDEs import को अपने-आप manage करती हैं

• अगर public static void main(String[] args) वाले entry point को C# की तरह top-level statement paradigm के रूप में abstract किया जाए, तो boilerplate कम हो सकता है और code ज़्यादा concise हो सकता है। जिज्ञासा है कि ऐसा क्यों नहीं किया गया

  • Paving the on-ramp दस्तावेज़ देखिए

  • अगर entry point एक special exception case के रूप में मौजूद है, तो यह पहले से ही OOP की सीमाओं को स्वीकार करना हुआ। ऐसे में क्या बेहतर नहीं होता कि साहस के साथ कोई नया विकल्प डिज़ाइन किया जाता?

• मुझे लगता है unnamed class approach की अच्छी बात यह है कि इससे global variables लागू करना आसान हो जाता है, hot reload भी संभव हो जाता है, और syntax भी concise हो जाती है। दूसरी ओर, Java file का नाम public class के नाम से मिलना चाहिए, यह बंधन है, इसलिए शायद public class X { } हिस्से को optional बना देना ही काफ़ी होता और ज़रूरत पड़ने पर ही लिखा जाता। unnamed class क्यों लानी पड़ी, यह मुझे ठीक से समझ नहीं आता
  compiler अब भी इसे HelloWorld.class जैसी class में बदलता है, इसलिए उसका नाम implementation detail भर है और source code में उसे सीधे इस्तेमाल नहीं किया जा सकता
  https://openjdk.org/jeps/445