JDK 11 में 90 नई सुविधाएँ (और एपीआई)

नमस्कार, हेब्र! मैं आपके लिए साइमन रिटर के लेख " JDK 11 में 90 नई सुविधाएँ (और एपीआई) " का अनुवाद प्रस्तुत करता हूँ।

कई लोगों के लिए, नए छह महीने के JDK रिलीज़ साइकिल का मतलब है कि कुछ अभी तक यह पता नहीं लगा पाए हैं कि JDK 10 में कौन सी नई सुविधाएँ हैं, और JDK 11 अभी जारी है। शुरुआती ब्लॉगों में से एक में , सभी 109 नए फ़ीचर्स और API को सूचीबद्ध किया गया था। JDK 10 में पाया जाने में कामयाब रहा। इसलिए, JDK 11 के लिए भी ऐसा ही करने का निर्णय लिया गया। हालांकि, एक अलग प्रारूप चुना गया था। इस पोस्ट को दो खंडों में विभाजित किया जाएगा: नई सुविधाएँ जो डेवलपर्स (सार्वजनिक एपीआई) और अन्य सभी के लिए उपलब्ध हैं। इस प्रकार, यदि आप केवल अपने विकास को सीधे प्रभावित करते हैं, तो आप दूसरे भाग को छोड़ सकते हैं।

परिवर्तनों की कुल संख्या 90 हो गई (यह जेईपी प्लस नई कक्षाएं और तरीके हैं, HTTP क्लाइंट और फ्लाइट रिकॉर्डर के लिए अलग-अलग तरीकों को छोड़कर) ( अनुवादक का नोट: जावा फ्लाइट रिकॉर्डर (जेएफआर) ओरेकल के अंतर्निहित विज्ञापनों में से एक था। JDK में, लेकिन जावा 11 से शुरू होकर, JEP 328 के लिए धन्यवाद, इसे ओपन सोर्स में स्थानांतरित कर दिया गया) । हालाँकि JDK 11, JDK 10 की तुलना में ग्यारह बदलावों को कम करने में कामयाब रहा, लेकिन मुझे लगता है कि यह कहना उचित है कि JDK 11 में अधिक कार्यक्षमता जोड़ी गई है, निश्चित रूप से JVM स्तर पर।

डेवलपर के लिए ध्यान देने योग्य नई सुविधाएँ

JDK 11 में काफी कुछ बदलाव हैं जो विकास शैली को प्रभावित कर सकते हैं। एक मामूली वाक्यविन्यास परिवर्तन, कई नए एपीआई और एक संकलक का उपयोग किए बिना एक फ़ाइल में एप्लिकेशन चलाने की क्षमता है ( नोट अनुवादक: तथाकथित शेबंग फ़ाइलें )। इसके अलावा, बड़ा (और ब्रेकिंग) परिवर्तन java.se.ee एकत्रीकरण मॉड्यूल को हटाने का है, जो मौजूदा एप्लिकेशन के JDK 11 के प्रवास को प्रभावित कर सकता है।

JEP 323: लैम्ब्डा पैरामीटर्स के लिए स्थानीय-परिवर्तनीय सिंटैक्स

JDK 10 में, स्थानीय चर अनुमान (या प्रकार का निष्कर्ष) पेश किया गया था ( JEP 286 )। यह कोड को सरल करता है क्योंकि अब आपको स्थानीय चर के प्रकार को स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं है, आप इसके बजाय var का उपयोग कर सकते हैं। JEP 323 इस सिंटैक्स के उपयोग का विस्तार करता है, जो अब लैम्ब्डा एक्सप्रेशन के मापदंडों पर भी लागू होता है। एक सरल उदाहरण:

list.stream() .map((var s) -> s.toLowerCase()) .collect(Collectors.toList()); 

एक चौकस जावा प्रोग्रामर यह संकेत देगा कि लैम्ब्डा के भावों में पहले से ही टाइप इनफैक्शन है, इसलिए var का उपयोग करना (इस मामले में) रीडायरेक्ट होगा। हम आसानी से समान कोड लिख सकते हैं:

  list.stream() .map(s -> s.toLowerCase()) .collect(Collectors.toList()); 

Var समर्थन क्यों जोड़ें? जवाब एक विशेष मामला है - जब आप लैम्बडा पैरामीटर में एनोटेशन जोड़ना चाहते हैं। यह किसी भी प्रकार की भागीदारी के बिना नहीं किया जा सकता है। एक स्पष्ट प्रकार का उपयोग करने से बचने के लिए, हम इस तरह से चीजों को सरल बनाने के लिए var का उपयोग कर सकते हैं:

  list.stream() .map((@Notnull var s) -> s.toLowerCase()) .collect(Collectors.toList()); 

यह परिवर्तन विशेष रूप से जावा लैंग्वेज स्पेसिफिकेशन (JLS) में आवश्यक परिवर्तन करता है :

पृष्ठ 24: var विशेष पहचानकर्ता का वर्णन।
पृष्ठ ६२ Page-६३०: लैम्बडा पैरामीटर
पृष्ठ ६३६: लम्बदा के भावों का क्रमिक मूल्यांकन
पृष्ठ 746: लैम्ब्डा सिंटैक्स

JEP 330: सिंगल-फाइल सोर्स-कोड प्रोग्राम लॉन्च करें

जावा की आलोचनाओं में से एक सिंटैक्स की अतिरेक है, और यहां तक ​​कि एक तुच्छ एप्लिकेशन को लॉन्च करने से जुड़े "समारोह" एक शुरुआत के लिए प्रवेश सीमा को गंभीरता से बढ़ा सकते हैं। "हैलो वर्ल्ड!" प्रिंट करने वाले एप्लिकेशन को लिखने के लिए, आपको सार्वजनिक स्थैतिक शून्य मुख्य विधि के साथ एक वर्ग लिखने और System.out.println () विधि का उपयोग करने की आवश्यकता है। ऐसा करने के बाद, आपको javac का उपयोग करके कोड संकलित करना होगा। अंत में, आप एक एप्लिकेशन लॉन्च कर सकते हैं जो दुनिया का स्वागत करेगा। अधिकांश आधुनिक भाषाओं में समान स्क्रिप्ट चलाना बहुत सरल और तेज़ है।

JEP 330 एकल-फ़ाइल एप्लिकेशन को संकलित करने की आवश्यकता को समाप्त करता है। अब बस दर्ज करें:

  java HelloWorld.java 

जावा लांचर यह पहचानता है कि फ़ाइल में जावा स्रोत कोड है और इसे निष्पादित करने से पहले कोड को एक .class फ़ाइल में संकलित करता है।

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

एक उदाहरण:

  java -classpath /home/foo/java Hello.java Bonjour 

यह इसके बराबर होगा:

  javac -classpath /home/foo/java Hello.java java -classpath /home/foo/java Hello Bonjour 

यह JEP शेबंग फ़ाइलों के लिए समर्थन भी प्रदान करता है। कमांड लाइन पर जावा लॉन्चर का उल्लेख करने की आवश्यकता को कम करने के लिए, आप इसे स्रोत फ़ाइल की पहली पंक्ति में शामिल कर सकते हैं। उदाहरण के लिए:

  #!/usr/bin/java --source 11 public class HelloWorld { ... 

उपयोग किए गए जावा के संस्करण के साथ-सोर्स फ्लैग की आवश्यकता है।

JEP 321: HTTP क्लाइंट (मानक)

JDK 9 ने HTTP क्लाइंट प्रोटोकॉल ( JEP 110 ) का समर्थन करने के लिए एक नया एपीआई पेश किया। चूंकि जेडीके 9 ने जावा प्लेटफॉर्म मॉड्यूल सिस्टम (जेपीएमएस) प्रदान किया था, इसलिए इस एपीआई को इनक्यूबेटर मॉड्यूल के रूप में शामिल किया गया था। इनक्यूबेटर मॉड्यूल नए एपीआई प्रदान करने के लिए डिज़ाइन किए गए हैं, लेकिन उन्हें जावा एसई मानक में नहीं बदलते हैं। डेवलपर प्रतिक्रिया देकर एपीआई की कोशिश कर सकते हैं। आवश्यक परिवर्तन करने के बाद (यह एपीआई जेडीके 10 में अपडेट किया गया था), मानक का हिस्सा बनने के लिए एपीआई को मुख्य मॉड्यूल में स्थानांतरित किया जा सकता है।

HTTP क्लाइंट एपीआई अब जावा एसई 11 मानक का हिस्सा है। यह JDK, java.net.http के लिए एक नया मॉड्यूल और पैकेज पेश करता है। मुख्य कक्षाएं:

• HttpClient
• HttpRequest
• HttpResponse
• वेब सॉकेट

एपीआई को सिंक्रोनाइज़ या एसिंक्रोनस रूप से उपयोग किया जा सकता है। एसिंक्रोनस मोड में, कंप्लीट फ़ंक्शंस और कंप्लीशनस्टेजेज का उपयोग किया जाता है।

JEP 320: जावा EE और CORBA मॉड्यूल निकालें

JDK 9 में JPMS की शुरुआत के साथ, अखंड rt.jar फ़ाइल को कई मॉड्यूल में विभाजित करना संभव था। JPMS का एक अतिरिक्त लाभ यह है कि अब आप एक जावा रनटाइम वातावरण बना सकते हैं जिसमें केवल आपके आवेदन के लिए आवश्यक मॉड्यूल शामिल हैं, जो समग्र आकार को कम करते हैं। स्पष्ट रूप से परिभाषित सीमाओं के साथ, अप्रचलित मॉड्यूल अब जावा एपीआई से निकालना आसान है। यह वही है जो यह जेईपी करता है; Java.se.ee मेटा मॉड्यूल में छह मॉड्यूल शामिल हैं जो अब Java SE 11 मानक का हिस्सा नहीं होंगे और JDK में शामिल नहीं होंगे।

दूरस्थ मॉड्यूल:

• कोरबा ( अनुवादक का नोट: शांति से विश्राम करें , नरक में जला )
• लेन-देन
• सक्रियण
• xml.bind
• xml.ws
• xml.ws.annotation

ये मॉड्यूल JDK 9 के बाद अप्रचलित (@Deprecated) चिह्नित किए गए हैं और संकलन या रनटाइम में डिफ़ॉल्ट रूप से शामिल नहीं थे। यदि आपने JDK 9 या JDK 10 पर इन मॉड्यूल से एपीआई का उपयोग करके संकलन या चलाने का प्रयास किया है, तो आप असफल रहे होंगे। यदि आप अपने कोड में इन मॉड्यूल से एपीआई का उपयोग करते हैं, तो आपको उन्हें एक अलग मॉड्यूल या लाइब्रेरी के रूप में प्रदान करना होगा। समीक्षाओं को देखते हुए, ऐसा लगता है कि java.xml मॉड्यूल जो JAX-WS, SOAP वेब सेवाओं के समर्थन का हिस्सा हैं, वे सबसे अधिक समस्याएं पैदा करेंगे।

नई सार्वजनिक एपीआई

JDK 11 में कई नए एपीआई इस तथ्य का परिणाम है कि HTTP क्लाइंट मॉड्यूल अब मानक का हिस्सा है, साथ ही साथ फ्लाइट रिकॉर्डर का समावेश भी है।

JDK के विभिन्न संस्करणों की तुलना सहित एपीआई परिवर्तनों की एक पूरी योजनाबद्ध सूची यहां पाई जा सकती है।

यहां सूचीबद्ध सभी नए तरीके हैं जो java.net.http और jdk.jfr मॉड्यूल में शामिल हैं। इसके अलावा सूचीबद्ध नहीं हैं java.security मॉड्यूल में नए तरीके और कक्षाएं हैं, जो JEP 324 और JEP 329 परिवर्तनों के लिए काफी विशिष्ट हैं (छह नए वर्ग और आठ नए तरीके हैं)।

java.io.ByteArrayOutputStream

• शून्य राइटबाइट्स (बाइट []) : आउटपुट के लिए तर्क से सभी बाइट्स लिखते हैं

java.io.FileReader

दो नए निर्माणकर्ता जो आपको चारसेट निर्दिष्ट करते हैं।

java.io.FileWriter

चार नए निर्माणकर्ता जो आपको चारसेट निर्दिष्ट करते हैं।

java.io.InputStream

• io.InputStream nullInputStream () : एक इनपुटस्ट्रीम देता है जो बाइट्स नहीं पढ़ता है। इस पद्धति (और आउटपुटस्ट्रीम, रीडर, और राइटर में से एक) को देखते हुए, सवाल उठता है कि यह क्यों काम में आ सकता है। आप उन्हें / dev / null के रूप में सोच सकते हैं - आउटपुट को फेंकने के लिए जिसे आपको ज़रूरत नहीं है, या इनपुट प्रदान करें जो हमेशा अशक्त बाइट देता है।

java.io.OutputStream

• io.OutputStream nullOutputStream ()

java.io.Reader

• io.Reader nullReader ()

java.io.Writer

• io.Writer nullWriter ()

java.lang.Character

• स्ट्रिंग toString (int) : यह मौजूदा पद्धति का ओवरलोडेड रूप है, लेकिन char के बजाय int का उपयोग किया जाता है। Int यूनिकोड कोड बिंदु है।

java.lang.CharSequence

• int की तुलना (CharSequence, CharSequence) : CharSequence के दो उदाहरणों की तुलनात्मक रूप से करते हैं। एक नकारात्मक मान, शून्य, या एक सकारात्मक मान लौटाता है यदि पहला क्रम क्रमशः कम, दूसरे के बराबर या उससे अधिक है।

java.lang.ref.Reference

• lang.Object क्लोन () : मुझे स्वीकार करना चाहिए, यह परिवर्तन भ्रम का कारण बनता है। संदर्भ वर्ग क्लोन करने योग्य इंटरफ़ेस को लागू नहीं करता है, और यह विधि CloneNotSupportedException को फेंकता है। इसके समावेश का एक कारण होना चाहिए, शायद भविष्य में कुछ के लिए। ( अनुवादक का नोट: StackOverflow पर एक चर्चा है , OpenJDK में एक टिकट )

java.lang.Runtime

java.lang.System

यहां कोई नई विधियां नहीं हैं, लेकिन यह ध्यान देने योग्य है कि रनफिनालाइज़रऑनऑक्सिट () विधि अब दोनों वर्गों से हटा दी गई है (जेडीके 11 की ओर पलायन करते समय समस्या हो सकती है)।

java.lang.String

मुझे लगता है कि यह JDK 11 में नए एपीआई के मुख्य आकर्षण में से एक है। यहां कुछ उपयोगी नए तरीके हैं।

• बूलियन ब्लैंक () : सही है अगर स्ट्रिंग खाली है या केवल रिक्त स्थान है, अन्यथा गलत है।
• स्ट्रीम लाइनें () : रिटर्न स्ट्रिंग से स्ट्रीम, इस स्ट्रिंग से निकाली गई, लाइन सेपरेटर द्वारा अलग की गई।
• स्ट्रिंग रिपीट (इंट) : एक स्ट्रिंग लौटाता है जिसका मान इस स्ट्रिंग का संघटन है, कई बार दोहराया जाता है।
• स्ट्रिंग स्ट्रिप () : एक स्ट्रिंग लौटाता है जिसका मान यह स्ट्रिंग है, यह स्ट्रिंग की शुरुआत और अंत में सभी रिक्त स्थान को निकालता है।
• स्ट्रिंग स्ट्रिपलीडिंग () : एक स्ट्रिंग देता है जिसका मान यह स्ट्रिंग है, जबकि लाइन की शुरुआत में सभी रिक्त स्थान को हटाता है।
• स्ट्रिंग स्ट्रिपलिंग () : एक स्ट्रिंग देता है जिसका मान यह स्ट्रिंग है, यह स्ट्रिंग के अंत में सभी रिक्त स्थान को हटा देता है।

सबसे अधिक संभावना है, आप पट्टी को देखते हैं () और पूछते हैं: "यह मौजूदा ट्रिम () विधि से कैसे अलग है?" उत्तर रिक्त स्थान की परिभाषा में अंतर पर है। ( अनुवादक का नोट: संक्षेप में, पट्टी) ( यूनिकोड को बेहतर समझती है, स्टैकऑवरफ्लो पर विस्तृत विश्लेषण )

java.lang.StringBuffer

java.lang.StringBuilder

इन दोनों वर्गों में एक नई तुलना () विधि है जो एक स्ट्रिंगबर्गर / स्ट्रिंगबर्स्ट लेती है और एक इंट वापस करती है। लेक्सिकल तुलना विधि चारसोसेन्स में नई तुलना () विधि के समान है।

java.lang.Thread

कोई नई विधि नहीं। नष्ट () और स्टॉप (फेंकने योग्य) तरीके हटा दिए गए हैं। स्टॉप () पद्धति, जिसमें कोई तर्क नहीं है, अभी भी मौजूद है। एक संगतता समस्या के लिए नेतृत्व कर सकते हैं।

java.nio.ByteBuffer

java.nio.CharBuffer

java.nio.DoubleBuffer

java.nio.FloatBuffer

java.nio.LongBuffer

java.nio.ShortBuffer

इन सभी वर्गों में अब बेमेल () विधि है, जो इस बफर और पारित बफर के बीच पहले बेमेल के सापेक्ष सूचकांक को ढूंढती है और वापस लौटाती है।

java.nio.channels.SelectionKey

• int interestOpsAnd (int) : एटोमिकली इस कुंजी (कुंजी के हित) को मौजूदा हितों के बिटवाइज चौराहे ("और") और पारित मूल्य पर सेट करता है।
• int interestOpsOr (int) : एटोमिक रूप से मौजूदा कुंजी के बिट सेट यूनियन ("या") में इस कुंजी (कुंजी के हित) के हितों और पारित मूल्य को निर्धारित करता है।

java.nio.channels.Selector

• int select (java.util.function.Consumer, long) : कुंजी पर उन क्रियाओं का चयन और प्रदर्शन करें जिनके संबंधित चैनल I / O संचालन के लिए तैयार हैं। लंबे तर्क एक समयबाह्य है।
• int select (java.util.function.Consumer) : ऊपर जैसा, लेकिन बिना टाइमआउट के।
• int selectNow (java.util.function.Consumer) : ऊपर की तरह, केवल नॉन-ब्लॉकिंग।

java.nio.file.Files

• स्ट्रिंग रीडस्ट्रिंग (पाथ) : एक फाइल से स्ट्रिंग में सभी सामग्री पढ़ता है, यूटीएफ -8 एन्कोडिंग का उपयोग करके बाइट्स से पात्रों तक डिकोडिंग।
• स्ट्रींग रीडस्ट्रिंग (पथ, चारसेट) : जैसा कि ऊपर बताया गया है, बाइट्स से वर्णों तक डिकोड करने वाले अंतर के साथ निर्दिष्ट ऑफसेट का उपयोग होता है।
• पथ राइटिंगस्ट्रिंग (पथ, चारसेंसेंस, java.nio.file.OpenOption []) : एक फ़ाइल के लिए चारसहायता लिखें। वर्णों को UTF-8 एन्कोडिंग का उपयोग करके बाइट्स में एन्कोड किया गया है।
• पथ राइटिंगस्ट्रिंग (पथ, चारसेंसेंस, java.nio.file.Charset, OpenOption []) : ऊपर के रूप में ही, वर्ण वर्ण में निर्दिष्ट एन्कोडिंग का उपयोग करके बाइट्स में एन्कोड किए गए हैं।

java.nio.file.Path

• पथ (स्ट्रिंग, स्ट्रिंग []) : पथ के स्ट्रिंग तर्क से पथ देता है या तार के अनुक्रम, जो संयुक्त होने पर पथ स्ट्रिंग बनाते हैं।
• पाथ (net.URI) : यूआरआई से पाथ लौटाता है।

java.util.Collection

• ऑब्जेक्ट [] toArray (java.util.function.IntFunction) : इस संग्रह में सभी तत्वों से युक्त एक सरणी देता है, जो दिए गए सरणी को आवंटित करने के लिए दिए गए पीढ़ी फ़ंक्शन का उपयोग करता है।

java.util.concurrent.PriorityBlockingQueue

java.util.PriorityQueue

• शून्य forEach (java.util.function.Consumer) : जब तक सभी तत्वों को संसाधित नहीं किया जाता है या कार्रवाई एक अपवाद फेंकता है, तब तक प्रत्येक Iterable तत्व के लिए पारित कार्रवाई करता है।
• बूलियन रिमूवल (java.util.Collection) : इस संग्रह के सभी तत्वों को हटाता है जो निर्दिष्ट संग्रह (वैकल्पिक संचालन) में भी निहित हैं।
• बूलियन removeIf (java.util.function.Predicate) : इस संग्रह के सभी तत्वों को हटाता है जो दिए गए विधेय को संतुष्ट करता है।
• बूलियन रिटेल ऑल (java.util.Collection) : इस संग्रह में केवल उन तत्वों को सहेजता है जो हस्तांतरित संग्रह (वैकल्पिक संचालन) में निहित हैं।

java.util.concurrent.TimeUnit

• लॉन्ग कन्वर्ट (java.time.Duration) : इस अवधि के लिए पारित अवधि परिवर्तित करता है।

java.util.function.Predicate

• Predicate not (Predicate) : विधेय लौटाता है, जो कि प्रेषित विधेय का निषेध है।

यह JDK 11 में मेरे पसंदीदा नए एपीआई में से एक है। एक उदाहरण के रूप में, आप इस कोड को परिवर्तित कर सकते हैं:

  lines.stream() .filter(s -> !s.isBlank()) 

में

  lines.stream() .filter(Predicate.not(String::isBlank)) 

या अगर हम स्थैतिक आयात का उपयोग करते हैं:

  lines.stream() .filter(not(String::isBlank)) 

व्यक्तिगत रूप से, मेरा मानना ​​है कि यह संस्करण अधिक समझने योग्य और संक्षिप्त है।

java.util.Optional

java.util.OptionalInt

java.util.OptionalDouble

java.util.OptionalLong

• बूलियन इस्मिप्ट () : यदि कोई मूल्य नहीं है, तो सच है, अन्यथा गलत है।

java.util.regex.Pattern

• Prateate asMatchPredicate () : मुझे लगता है कि यह नए JDK 11. एपीआई का रत्न हो सकता है। एक विधेय बनाता है जो यह जाँचता है कि क्या यह टेम्पलेट दिए गए इनपुट स्ट्रिंग से मेल खाता है।

java.util.zip.Deflater

• int deflate (बाइटबफ़र) : इनपुट को संपीड़ित करता है और इसके साथ निर्दिष्ट बफर को भरता है।

  
  

• int deflate (ByteBuffer, int) : इनपुट को संपीड़ित करता है और इसके साथ निर्दिष्ट बफर को भरता है। संपीड़ित डेटा की वास्तविक राशि लौटाता है।

  
  

• शून्य सेटटॉर (बाइटबफ़र) : इस बफ़र में बाइट्स के संपीड़न के लिए निर्दिष्ट शब्दकोश सेट करता है। यह एक मौजूदा विधि का ओवरलोडेड रूप है जिसे बाइट सरणी के बजाय एक बाइटबफ़र अब स्वीकार कर सकता है।

  
  

• शून्य सेटइन्पुट (बाइटबफ़र) : इनपुट को संपीड़ित करने के लिए सेट करता है। मौजूदा पद्धति का ओवरलोड रूप भी।

  
  

java.util.zip.Inflater

• int inflate (बाइटबफ़र) : डीकंप्रेस बफ़र निर्दिष्ट बफ़र में। अनजिप बाइट्स की वास्तविक संख्या देता है।
• शून्य सेटटॉर (बाइटबफ़र) : इस बफ़र में निर्दिष्ट शब्दकोश को बाइट्स में सेट करता है। किसी मौजूदा पद्धति का अधिभार रूप।
• शून्य सेटइन्पुट (बाइटबफ़र) : विघटन के लिए इनपुट सेट करता है। किसी मौजूदा पद्धति का अधिभार रूप।

javax.print.attribute.standard.DialogOwner

यह JDK 11 में एक नया वर्ग है। इसका उपयोग प्रिंट संवाद या पेज सेटअप के अनुरोध के लिए किया जाता है। सभी विंडो या किसी विशिष्ट विंडो के शीर्ष पर प्रदर्शित होना चाहिए।

javax.swing.DefaultComboBoxModel

javax.swing.DefaultListModel

• शून्य addAll (संग्रह) : संग्रह में मौजूद सभी तत्वों को जोड़ता है।
• शून्य addAll (int, Collection) : निर्दिष्ट सूचकांक से शुरू होकर संग्रह में मौजूद सभी तत्वों को जोड़ता है।

javax.swing.ListSelectionModel

• int [] getSelectedIndices () : चयनित मॉडल में सभी चुने हुए सूचकांकों की एक सरणी को आरोही क्रम में लौटाता है।
• int getSelectedItemsCount () : चयनित आइटमों की संख्या लौटाता है।

jdk.jshell.EvalException

• jshell.JShellException getCause () : निष्पादन क्लाइंट में एक फेंकने योग्य कारण आवरण लौटाता है जो एक EvalException द्वारा प्रतिनिधित्व किया जाता है, या अशक्त यदि कारण मौजूद नहीं है या अज्ञात है।

नई सुविधाएँ (सार्वजनिक API नहीं)

JEP 181: नेस्ट-बेस्ड एक्सेस कंट्रोल

जावा (और अन्य भाषाएँ) आंतरिक कक्षाओं के माध्यम से नेस्टेड कक्षाओं का समर्थन करती हैं। सही संचालन के लिए, संकलक को कुछ चालें करनी चाहिए। उदाहरण के लिए:

  public class Outer { private int outerInt; class Inner { public void printOuterInt() { System.out.println("Outer int = " + outerInt); } } } 

संकलन करने से पहले कंपाइलर इसे कुछ इस तरह बनाता है:

  public class Outer { private int outerInt; public int access$000() { return outerInt; } } 

  class Inner$Outer { Outer outer; public void printOuterInt() { System.out.println("Outer int = " + outer.access$000()); } } 

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

यह JEP एक "सॉकेट" की अवधारणा का प्रतिनिधित्व करता है, जहां एक ही सॉकेट के दो सदस्य (बाहरी और हमारे उदाहरण से आंतरिक) पड़ोसी हैं। * .Class फ़ाइल प्रारूप में दो नई विशेषताएँ जोड़ी गईं: NestHost और NestMembers। ये परिवर्तन अन्य बाइटकोड-संकलित भाषाओं के लिए भी उपयोगी हैं जो नेस्टेड वर्गों का समर्थन करते हैं।

यह सुविधा java.lang.Class के लिए तीन नए तरीके प्रदान करती है:

• कक्षा getNestHost ()
• कक्षा [] getNestMembers ()
• बूलियनNestmateOf (क्लैज़)

इस विशेषता को जावा वर्चुअल मशीन स्पेसिफिकेशन (JVMS) में भी बदलाव की आवश्यकता है, विशेष रूप से खंड 5.4.4 एक्सेस कंट्रोल में।

जेईपी 309: डायनामिक क्लास-फाइल कांस्टेंट

यह JEP निरंतर पूल CONSTANT_Dynamic (अक्सर प्रस्तुतियों में शंकु के रूप में संदर्भित) के साथ नए रूप का समर्थन करने के लिए * .class फ़ाइल स्वरूप के विस्तार का वर्णन करता है। एक गतिशील निरंतर का विचार एक ऑक्सीमोरोन प्रतीत होता है, लेकिन, वास्तव में, आप इसे जावा में अंतिम मान के रूप में सोच सकते हैं। निरंतर पूल का मान संकलन चरण (अन्य स्थिरांक के विपरीत) पर सेट नहीं किया गया है, लेकिन बूटस्ट्रैप विधि का उपयोग रन टाइम पर मूल्य निर्धारित करने के लिए किया जाता है। इसलिए, मूल्य गतिशील है, लेकिन चूंकि इसका मूल्य केवल एक बार निर्धारित होता है, इसलिए यह स्थिर भी है।

यह सुविधा मुख्य रूप से उन लोगों के लिए उपयोगी होगी जो नई भाषाओं और संकलक विकसित कर रहे हैं। जेवीएम पर चलने के लिए कौन बाईटेकोड और * .class फाइल्स जेनरेट करेगा। यह कुछ कार्यों को सरल करेगा।

यह सुविधा एक नया वर्ग प्रदान करती है java.lang.invoke.ConstantBootstraps जिसमें नौ नए तरीके हैं। मैं उन सभी को यहाँ सूचीबद्ध नहीं करूँगा; ये गतिशील रूप से गणना की गई स्थिरांक के लिए बूटस्ट्रैप विधियाँ हैं।

इस सुविधा को विशेष रूप से JVMS में परिवर्तन की आवश्यकता थी, विशेष रूप से, कैसे विशेष बाइट कोड और कॉन्स्टेंट पूल के खंड 4.4 का उपयोग किया जाता है।

JEP 315: Aarch64 आंतरिक सुधार

यह रेड हैट द्वारा योगदान दिया गया JEP था। JVM अब आर्म 64 कमांड सेट में उपलब्ध अधिक विशिष्ट निर्देशों का उपयोग कर सकता है। विशेष रूप से, यह पाप (), कॉस (), और लॉग () java.lang.Math वर्ग के तरीकों में सुधार करता है।

जेईपी 318: एप्सिलॉन कचरा कलेक्टर

रेड हैट ने भी इस JEP में योगदान दिया। एप्सिलॉन कचरा कलेक्टर कुछ असामान्य है क्योंकि यह कचरा इकट्ठा नहीं करता है! नई ऑब्जेक्ट बनाते समय आवश्यक होने पर यह नई मेमोरी आवंटित करेगा, लेकिन लिंक के बिना ऑब्जेक्ट द्वारा कब्जा किए गए स्थान को मुक्त नहीं करता है।

ऐसा लगता है, फिर, क्या बात है? कम से कम दो उपयोग हैं:

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

यदि ढेर स्थान समाप्त हो जाता है, तो बाद के जेवीएम ऑपरेशन को तीन तरीकों में से एक में कॉन्फ़िगर किया जा सकता है:

• एक नियमित OutOfMemoryError कहा जाता है।
• हीप को रीसेट करें
• जेवीएम को रोकना और संभवतः एक बाहरी कार्य करना (उदाहरण के लिए, डिबगर शुरू करना)।

जेईपी 324: कर्व 25519 और करवे 448 के साथ मुख्य समझौता

क्रिप्टोग्राफिक मानक लगातार बदल रहे हैं और सुधार कर रहे हैं। इस मामले में, एक अण्डाकार वक्र के साथ मौजूदा डिफी-हेलमैन योजना को वक्र 2525 और कर्व 44 से बदल दिया जाता है। यह RFC-7748 में परिभाषित एक महत्वपूर्ण समझौता योजना है।

JEP 327: यूनिकोड 10

जावा प्लेटफॉर्म सभी वर्ण सेटों के प्रसंस्करण को सक्षम करने के लिए यूनिकोड का समर्थन करता है। चूंकि यूनिकोड को संस्करण 10 में अपडेट किया गया है, इसलिए जेडडीके को मानक के इस संस्करण का समर्थन करने के लिए भी अपडेट किया गया है।

मैं हमेशा यह देखने के लिए आतुर रहता हूं कि नए संस्करणों में यूनिकोड डेवलपर्स क्या शामिल हैं। यूनिकोड 10 में 8,518 नए पात्र हैं। इसमें बिटकॉइन प्रतीक, नुशु चरित्र सेट (चीनी महिलाओं द्वारा कविताओं को लिखने के लिए उपयोग किया जाता है), और सोओम्बो और ज़नाबाजार स्क्वायर (संस्कृत, तिब्बती और मंगोलियाई भाषा लिखने के लिए ऐतिहासिक बौद्ध ग्रंथों में इस्तेमाल किए गए पात्र हैं)। लंबे समय से प्रतीक्षित (जाहिरा तौर पर) कोलबर्ट इमोजी सहित कई अन्य इमोजी भी जोड़े गए हैं।

याद रखें, JDK 9 से शुरू होकर, आप संपत्ति फ़ाइलों (.properties) में UTF-8 का उपयोग कर सकते हैं। इसका मतलब है कि ऐसी फ़ाइलों में किसी भी यूनिकोड चरित्र का उपयोग किया जा सकता है। जिसमें इमोजीस भी शामिल हैं। या नुशु।

JEP 328: फ्लाइट रिकॉर्डर

Flight Recorder — JVM. JDK 11 Oracle JDK. , Oracle Oracle JDK OpenJDK, OpenJDK.

JEP :

• API
• , JVM HotSpot JDK

: jdk.jfr jdk.management.jfr.

JEP 329: ChaCha20 and Poly1305 Cryptographic Algorithms

JEP 324, , JDK. ChaCha20 ChaCha20-Poly1305, RFC 7539. ChaCha20 — , , RC4.

JEP 331: Low-overhead Heap Profiling

, JEP, Google. Java JVM.

:

• ,
• ( , GC VM)
• Java.

JEP 332: Transport Layer Security (TLS) 1.3

TLS 1.3 (RFC 8446) " " TLS . JDK , Datagram Transport Layer Security (DTLS).

JEP 333: ZGC A Scalable, Low Latency Garbage Collector

, , () . ( , Weak Generational Hypothesis ) ( ) GC . "" , . .

ZGC — region-based ( G1), NUMA aware compacting . .

pauseless , C4 Zing JVM.

JEP 335: Deprecate the Nashorn Scripting Engine

Nashorn JDK 8 Rhino Javascript . , Nashorn API jjs Java. , . Graal VM , , .

JEP 336: Deprecate the Pack200 Tools and APIs

Pack200 — JAR-, Java SE 5.0. JPMS JDK 9 Pack200 JDK. pack200 unpack200 API Pack200 java.util.jar JDK. , .

निष्कर्ष

JDK 11 — LTS JDK ( ). , , , , JVM , .

Zulu JDK 11 !

JDK 11?

( . : , )