जावा 11 के ग्यारह छिपे हुए मोती

जावा 11 ने कोई भी नवीन सुविधाओं को पेश नहीं किया है, लेकिन इसमें कई रत्न शामिल हैं जो आपने अभी तक नहीं सुने होंगे। पहले से ही String , Optional , Collection और अन्य वर्कहॉर्स में नवीनतम को देखा? यदि नहीं, तो आप पते पर आ गए हैं: आज हम जावा 11 से 11 छिपे हुए रत्नों को देखेंगे!

लैम्ब्डा मापदंडों के लिए प्रकार अनुमान

लंबोदर अभिव्यक्ति लिखते समय, आप स्पष्ट रूप से निर्दिष्ट प्रकारों के बीच चयन कर सकते हैं और उन्हें छोड़ सकते हैं:

 Function<String, String> append = string -> string + " "; Function<String, String> append = (String s) -> s + " "; 

जावा 10 ने var पेश किया , लेकिन इसे लैम्ब्डा में इस्तेमाल नहीं किया जा सका:

 //    Java 10 Function<String, String> append = (var string) -> string + " "; 

जावा 11 में यह पहले से ही संभव है। लेकिन क्यों? ऐसा नहीं लगता है कि var केवल एक टाइप पास से अधिक दिया गया है। हालांकि यह मामला है, var उपयोग से दो मामूली फायदे हैं:

• नियम के अपवाद को हटाकर var और अधिक सार्वभौमिक का उपयोग करता है
• आपको इसके पूर्ण नाम का उपयोग किए बिना एनोटेशन को पैरामीटर प्रकार में जोड़ने की अनुमति देता है

यहाँ दूसरे मामले का एक उदाहरण दिया गया है:

 List<EnterpriseGradeType<With, Generics>> types = /*...*/; types .stream() // ,     @Nonnull   .filter(type -> check(type)) //  Java 10    ~>  .filter((@Nonnull EnterpriseGradeType<With, Generics> type) -> check(type)) //  Java 11    ~>   .filter((@Nonnull var type) -> check(type)) 

हालाँकि, प्रपत्र के लंबर एक्सप्रेशंस (var type, String option, index) -> ... व्युत्पन्न, स्पष्ट और निहित प्रकारों को मिलाकर (var type, String option, index) -> ... को लागू किया जा सकता है, लेकिन ( JEP-323 के ढांचे में ) यह काम नहीं किया गया था। इसलिए, तीन दृष्टिकोणों में से एक को चुनना और लैम्ब्डा अभिव्यक्ति के सभी मापदंडों के लिए इसका पालन करना आवश्यक है। उनमें से किसी एक के लिए एनोटेशन जोड़ने के लिए सभी मापदंडों के लिए var निर्दिष्ट करने की आवश्यकता थोड़ी कष्टप्रद हो सकती है, लेकिन आम तौर पर सहनीय है।

'String::lines' साथ 'String::lines' की स्ट्रीम प्रोसेसिंग

एक बहु-पंक्ति स्ट्रिंग मिला? इसके हर लाइन के साथ कुछ करना चाहते हैं? फिर String::lines सही विकल्प है:

 var multiline = "\r\n\r\n\r\n"; multiline .lines() //Stream<String> .map(line -> "// " + line) .forEach(System.out::println); // : //  //  //  //  

ध्यान दें कि मूल लाइन \r\n स्क्रू सीमांकक का उपयोग करती है और यद्यपि मैं लिनक्स पर हूं, lines() ने अभी भी इसे तोड़ दिया है। यह इस तथ्य के कारण है कि, वर्तमान ओएस के बावजूद, यह विधि \r , \n , और \r\n को पंक्ति विच्छेद के रूप में व्याख्या करती है - भले ही वे एक ही पंक्ति पर मिश्रित हों।

लाइनों की एक धारा में कभी लाइन विभाजक नहीं होते हैं। लाइनें खाली हो सकती हैं ( "\n\n \n\n" , जिसमें 5 लाइनें शामिल हैं), लेकिन मूल पंक्ति की अंतिम पंक्ति को अनदेखा कर दिया जाता है यदि वह खाली है ( "\n\n" ; 2 लाइनें)। (अनुवादक द्वारा ध्यान दें: यह उनके लिए line , लेकिन string , और हमारे पास दोनों हैं)।

split("\R") विपरीत, lines() आलसी हैं और, मैं उद्धृत करता हूं , "नई लाइन ब्रेक के लिए तेजी से खोज करके बेहतर प्रदर्शन [...] प्रदान करता है"। (यदि कोई सत्यापन के लिए जेएमएच पर एक बेंचमार्क दर्ज करना चाहता है, तो मुझे बताएं)। यह प्रसंस्करण एल्गोरिथ्म को भी बेहतर ढंग से दर्शाता है और अधिक सुविधाजनक डेटा संरचना (सरणी के बजाय स्ट्रीम) का उपयोग करता है।

'String::strip' , आदि के साथ व्हाट्सएप को हटाना।

प्रारंभ में, String में व्हाट्सएप को हटाने के लिए एक trim विधि थी, जिसे U+0020 तक के कोड के साथ सब कुछ माना जाता था। हां, BACKSPACE ( U+0008) BELL ( U+0007 ) की तरह सफेद स्थान है, लेकिन LINE SEPARATOR ( U+2028 ) को अब ऐसा नहीं माना जाता है।

जावा 11 ने strip विधि की शुरुआत की, जिसके दृष्टिकोण में अधिक बारीकियाँ हैं। यह जावा 5 से Character::isWhitespace का उपयोग करता है यह निर्धारित करने के लिए कि वास्तव में क्या हटाने की आवश्यकता है। इसके प्रलेखन से यह स्पष्ट है कि यह:

• SPACE SEPARATOR , LINE SEPARATOR , PARAGRAPH SEPARATOR , लेकिन एक अप्रतिहत स्थान नहीं
• HORIZONTAL TABULATION ( U+0009 ), LINE FEED ( U+000A ), U+000B ( U+000B ), FORM FEED ( U+000C ), U+000C ( U+000D )
• FILE SEPARATOR ( U+001C ), GROUP SEPARATOR ( U+001D ), U+001D ( U+001E ), UNIT SEPARATOR ( U+001F )

एक ही तर्क के साथ, दो और सफाई के तरीके हैं, stripLeading और stripTailing , जो कि उनसे अपेक्षित है।

और अंत में, यदि आपको यह पता लगाना है कि क्या isBlank हटाने के बाद लाइन खाली हो जाती है, तो वास्तव में उन्हें हटाने की कोई आवश्यकता नहीं है - बस का उपयोग isBlank :

 " ".isBlank(); //  ~> true " ".isBlank(); //   ~> false 

'String::repeat' साथ दोहराए जाने वाले तार

विचार पकड़ें:

चरण 1: JDK पर नजर रखना

चरण 2: StackOverflow संबंधित प्रश्न ढूँढना

चरण 3: भविष्य के परिवर्तनों के आधार पर एक नए उत्तर के साथ आने वाला

चरण 4: ????

चरण 4: लाभ

जैसा कि आप कल्पना कर सकते हैं, String में एक नया repeat(int) विधि है। यह ठीक अपेक्षाओं के अनुरूप काम करता है, और चर्चा करने के लिए बहुत कम है।

'Path::of' साथ पथ बनाना

मुझे वास्तव में Path एपीआई पसंद है, लेकिन विभिन्न विचारों (जैसे Path , File , URL , URI और String ) के बीच पथ परिवर्तित करना अभी भी कष्टप्रद है। दो बिंदुओं की प्रतिलिपि बनाकर जावा 11 में यह बिंदु कम भ्रामक हो गया है Paths::get विधियों में Path::of Paths::get Path::of विधियों की

 Path tmp = Path.of("/home/nipa", "tmp"); Path codefx = Path.of(URI.create("http://codefx.org")); 

उन्हें विहित माना जा सकता है, क्योंकि दोनों पुराने Paths::get तरीके नए विकल्पों का उपयोग करते हैं।

'Files::readString' और 'Files::writeString' साथ पढ़ना और लिखना

यदि मुझे एक बड़ी फ़ाइल से पढ़ने की आवश्यकता है, तो मैं आमतौर पर Files::lines उपयोग करता हूं Files::lines इसकी लाइनों की एक आलसी धारा प्राप्त करने के लिए लाइनें। इसी तरह, एक बड़ी मात्रा में डेटा लिखने के लिए जिसे मेमोरी में इसकी संपूर्णता में संग्रहीत नहीं किया जा सकता है, मैं Files::write उपयोग करता हूं Files::write उन्हें Iterable<String> रूप में Files::write हुए।

लेकिन जब मैं एक लाइन के रूप में एक फ़ाइल की सामग्री को संसाधित करना चाहता हूं तो सरल मामले के बारे में क्या? यह बहुत सुविधाजनक नहीं है, क्योंकि Files::readAllBytes और Files::readAllBytes का उपयुक्त संस्करण Files::write बाइट सरणियों पर कार्य Files::write हैं।

और फिर Java 11 प्रकट होता है, जिसमें readString और readString जोड़ते readString Files :

 String haiku = Files.readString(Path.of("haiku.txt")); String modified = modify(haiku); Files.writeString(Path.of("haiku-mod.txt"), modified); 

स्पष्ट और उपयोग करने में आसान। यदि आवश्यक हो, तो आप Charset को readString पास कर सकते हैं, और readString में एक OpenOptions सरणी भी।

खाली I / O 'Reader::nullReader' , आदि के साथ।

एक OutputStream जरूरत है जो कहीं भी नहीं लिखता है? या एक खाली InputStream ? Reader और Writer बारे में क्या कुछ नहीं है? जावा 11 में यह सब है:

 InputStream input = InputStream.nullInputStream(); OutputStream output = OutputStream.nullOutputStream(); Reader reader = Reader.nullReader(); Writer writer = Writer.nullWriter(); 

(अनुवादक का नोट: commons-io ये कक्षाएं लगभग 2014 से मौजूद हैं।)

हालांकि, मुझे आश्चर्य है - क्या वास्तव में सबसे अच्छा उपसर्ग null ? मुझे यह पसंद नहीं है कि इसका उपयोग "जानबूझकर अनुपस्थिति" के लिए कैसे किया जाता है ... शायद यह बेहतर होगा कि noOp का उपयोग noOp ? (अनुवादक का नोट: सबसे अधिक संभावना यह उपसर्ग /dev/null के सामान्य उपयोग के कारण चुना गया था।)

{ } ~> [ ] 'Collection::toArray' साथ 'Collection::toArray'

आप संग्रह को सरणियों में कैसे परिवर्तित करते हैं?

 //  Java 11 List<String> list = /*...*/; Object[] objects = list.toArray(); String[] strings_0 = list.toArray(new String[0]); String[] strings_size = list.toArray(new String[list.size()]); 

पहला विकल्प, objects , प्रकारों के बारे में सभी जानकारी खो देता है, इसलिए यह उड़ान में है। बाकी के बारे में क्या? दोनों भारी हैं, लेकिन पहले कम है। उत्तरार्द्ध आवश्यक आकार की एक सरणी बनाता है, ताकि यह अधिक उत्पादक दिखे (अर्थात, यह "अधिक उत्पादक लगता है", विश्वसनीयता देखें)। लेकिन क्या यह वास्तव में अधिक उत्पादक है? नहीं, इसके विपरीत, यह धीमा (फिलहाल) है।

लेकिन मुझे इसकी परवाह क्यों करनी चाहिए? क्या ऐसा करने का बेहतर तरीका नहीं है? जावा 11 में हैं:

 String[] strings_fun = list.toArray(String[]::new); 

Collection::toArray का एक नया संस्करण Collection::toArray IntFunction<T[]> Collection::toArray , जो IntFunction<T[]> , अर्थात् स्वीकार करता है। एक फ़ंक्शन जो सरणी का आकार प्राप्त करता है और आवश्यक आकार की एक सरणी देता है। इसे संक्षेप में T[]::new (एक प्रसिद्ध T ) के एक निर्माता के संदर्भ के रूप में व्यक्त किया जा सकता है।

दिलचस्प तथ्य, Collection#toArray(IntFunction<T[]>) का डिफ़ॉल्ट कार्यान्वयन हमेशा सरणी जनरेटर को 0 से गुजरता है। सबसे पहले, मैंने फैसला किया कि यह समाधान शून्य लंबाई के सरणियों के लिए सबसे अच्छा प्रदर्शन पर आधारित था, लेकिन अब मुझे लगता है कि इसका कारण यह हो सकता है कि कुछ संग्रह के लिए, आकार की गणना करना बहुत महंगा ऑपरेशन हो सकता है और आपको Collection के डिफ़ॉल्ट कार्यान्वयन में इस दृष्टिकोण का उपयोग नहीं करना चाहिए। हालाँकि, विशिष्ट संग्रह कार्यान्वयन, जैसे कि ArrayList , इस दृष्टिकोण को बदल सकता है, लेकिन वे जावा 11 में नहीं बदलते हैं। इसके लायक नहीं, मुझे लगता है।

'Optional::isEmpty' साथ अनुपस्थिति की जांच

Optional के प्रचुर उपयोग के साथ, विशेष रूप से बड़ी परियोजनाओं में, जहां आप अक्सर गैर- Optional दृष्टिकोण का सामना करते हैं, आपको अक्सर यह जांचना होगा कि क्या इसका कोई मूल्य है। इसके लिए एक Optional::isPresent । विधि विधि है। लेकिन बस के रूप में अक्सर आप विपरीत पता करने की जरूरत है - कि Optional खाली है। कोई समस्या नहीं, बस का उपयोग करें !opt.isPresent() , ठीक है?

बेशक, यह ऐसा हो सकता है, लेकिन if इसकी स्थिति उलटी नहीं है if तर्क को समझना लगभग हमेशा आसान होता है। और कभी-कभी Optional कॉल की लंबी श्रृंखला के अंत में पॉप अप करता है और यदि आपको इसे कुछ भी नहीं जांचने की आवश्यकता है, तो आपको शर्त लगाना होगा ! बहुत शुरुआत में:

 public boolean needsToCompleteAddress(User user) { return !getAddressRepository() .findAddressFor(user) .map(this::canonicalize) .filter(Address::isComplete) .isPresent(); } 

उस स्थिति में, इसे छोड़ें ! बहुत आसान है। जावा 11 से शुरू करना बेहतर विकल्प है:

 public boolean needsToCompleteAddress(User user) { return getAddressRepository() .findAddressFor(user) .map(this::canonicalize) .filter(Address::isComplete) .isEmpty(); } 

Inverting 'Predicate::not' साथ 'Predicate::not'

Inverting की बात कर रहे हैं ... Predicate इंटरफ़ेस में एक negate आवृत्ति negate : यह एक नया predicate लौटाता है जो एक ही जाँच करता है, लेकिन इसके परिणाम का संकेत देता है। दुर्भाग्य से, मैं शायद ही कभी इसका उपयोग करने का प्रबंधन करता हूं ...

 //      Stream .of("a", "b", "", "c") // ,  ~>        .filter(s -> !s.isBlank()) //          ~>  .filter((String::isBlank).negate()) // ,  ~>       .filter(((Predicate<String>) String::isBlank).negate()) .forEach(System.out::println); 

समस्या यह है कि मैं शायद ही कभी उदाहरण के लिए उपयोग किया है। अधिक बार, मैं इस तरह के उदाहरण को एक विधि के लिंक के माध्यम से प्राप्त करना चाहता हूं (और इसे उल्टा कर सकता हूं), लेकिन इसके लिए काम करने के लिए, संकलक को पता होना चाहिए कि विधि के संदर्भ को क्या लाया जाए - इसके बिना, यह कुछ भी नहीं कर सकता है। और अगर आप (String::isBlank).negate() उपयोग करते हैं तो ठीक यही होता है: संकलक अब यह नहीं जानता है कि String::isBlank इस पर होना चाहिए और इसे String::isBlank देना चाहिए। एक सही ढंग से निर्दिष्ट जाति इसे ठीक करती है, लेकिन किस कीमत पर?

हालांकि एक सरल उपाय है। negate आवृत्ति negate उपयोग न करें, लेकिन जावा 11 से नई स्थिर विधि Predicate.not(Predicate<T>) :

 Stream .of("a", "b", "", "c") //   `java.util.function.Predicate.not` .filter(not(String::isBlank)) .forEach(System.out::println); 

पहले से बेहतर!

'Pattern::asMatchPredicate' साथ विधेय के रूप में नियमित अभिव्यक्ति

क्या कोई नियमित अभिव्यक्ति है? उस पर डेटा फ़िल्टर करने की आवश्यकता है? इस बारे में कैसे:

 Pattern nonWordCharacter = Pattern.compile("\\W"); Stream .of("Metallica", "Motörhead") .filter(nonWordCharacter.asPredicate()) .forEach(System.out::println); 

मुझे यह विधि पाकर बहुत खुशी हुई! यह जोड़ने योग्य है कि यह जावा 8 से एक विधि है। उफ़, मैंने इसे याद किया। जावा 11 ने एक और समान विधि जोड़ी: Pattern::asMatchPredicate । अंतर क्या है?

• asPredicate जाँचता है कि स्ट्रिंग या स्ट्रिंग का हिस्सा पैटर्न से मेल खाता है (जैसे काम करता है s -> this.matcher(s).find() )।
• asMatchPredicate जाँचता है कि संपूर्ण स्ट्रिंग पैटर्न से मेल खाती है ( s -> this.matcher(s).matches() तरह काम करती है)

उदाहरण के लिए, हमारे पास एक नियमित अभिव्यक्ति है जो फोन नंबरों की जांच करती है, लेकिन इसमें ^ और $ एक पंक्ति की शुरुआत और अंत को ट्रैक करने के लिए नहीं है। फिर निम्नलिखित कोड काम नहीं करेगा जैसा कि आप उम्मीद कर सकते हैं:

 prospectivePhoneNumbers .stream() .filter(phoneNumberPatter.asPredicate()) .forEach(this::robocall); 

क्या आपको कोई गलती नज़र आई? " -152 ? +1-202-456-1414" जैसी एक लाइन को फ़िल्टर्ड किया जाएगा, क्योंकि इसमें एक मान्य फ़ोन नंबर है। दूसरी ओर, Pattern::asMatchPredicate इसकी अनुमति नहीं देगा, क्योंकि संपूर्ण स्ट्रिंग अब पैटर्न से मेल नहीं खाएगी।

आत्म परीक्षण

यहाँ सभी ग्यारह मोतियों का अवलोकन है - क्या आपको अभी भी याद है कि प्रत्येक विधि क्या करती है? यदि हां, तो आपने परीक्षा पास कर ली है।

• String :
  
  • Stream<String> lines()
  • String strip()
  • String stripLeading()
  • String stripTrailing()
  • boolean isBlank()
  • String repeat(int)
• Path :
  
  • static Path of(String, String...)
  • static Path of(URI)
• Files :
  
  • String readString(Path) throws IOException
  • Path writeString(Path, CharSequence, OpenOption...) throws IOException
  • Path writeString(Path, CharSequence, Charset, OpenOption...) throws IOException
• InputStream : static InputStream nullInputStream()
• static OutputStream nullOutputStream() : static OutputStream nullOutputStream()
• Reader : static Reader nullReader()
• Writer : static Writer nullWriter()
• Collection : T[] toArray(IntFunction<T[]>)
• Optional : boolean isEmpty()
• Predicate : static Predicate<T> not(Predicate<T>)
• Pattern : Predicate<String> asMatchPredicate()

जावा 11 के साथ मज़े करो!