जावा में लम्बडा एक्सप्रेशंस पार्सिंग

अनुवादक से: लैम्बडामेटेक्टैक्ट शायद सबसे कम जावा जावा तंत्र में से एक है। हमने हाल ही में इसकी खोज की, लेकिन पहले से ही इन क्षमताओं की सराहना की। CUBA फ्रेमवर्क का वर्जन 7.0 लैम्ब्डा एक्सप्रेशन पैदा करने के पक्ष में रिफ्लेक्टिव कॉल से बचकर प्रदर्शन को बेहतर बनाता है। हमारे ढांचे में इस तंत्र के अनुप्रयोगों में से एक है एनोटेशन, एक सामान्य कार्य, स्प्रिंग से EventListener का एनालॉग द्वारा आवेदन इवेंट हैंडलर का बंधन। हम मानते हैं कि लैम्ब्डाफैक्टिंग के सिद्धांतों का ज्ञान कई जावा अनुप्रयोगों में उपयोगी हो सकता है, और हम इस अनुवाद को आपके साथ साझा करने में जल्दबाजी करते हैं।

इस लेख में, हम जावा 8 में लैम्ब्डा एक्सप्रेशन और इन एक्ट्रेसेस की सीमाओं के साथ काम करते हुए कुछ छोटी-छोटी ट्रिक्स दिखाएंगे। लेख के लक्षित दर्शक वरिष्ठ जावा डेवलपर्स, शोधकर्ताओं और टूलकिट डेवलपर्स हैं। com.sun.* बिना केवल सार्वजनिक जावा एपीआई का उपयोग किया जाएगा com.sun.* और अन्य आंतरिक कक्षाएं, इसलिए कोड विभिन्न जेवीएम कार्यान्वयनों के बीच पोर्टेबल है।

शॉर्ट फॉरवर्ड

गुमनाम तरीकों को लागू करने के तरीके के रूप में लैम्ब्डा एक्सप्रेशन जावा 8 में दिखाई दिए और,
कुछ मामलों में, अनाम कक्षाओं के विकल्प के रूप में। बाइटकोड स्तर पर, लैम्ब्डा एक्सप्रेशन को invokedynamic द्वारा बदल दिया जाता है। यह निर्देश एक कार्यात्मक इंटरफ़ेस कार्यान्वयन बनाने के लिए उपयोग किया जाता है और इसकी एकमात्र विधि कॉल को वास्तविक विधि में दर्शाती है, जिसमें लैम्ब्डा अभिव्यक्ति के शरीर में परिभाषित कोड होता है।

उदाहरण के लिए, हमारे पास निम्नलिखित कोड हैं:

 void printElements(List<String> strings){ strings.forEach(item -> System.out.println("Item = %s", item)); } 

इस कोड को जावा कंपाइलर द्वारा कुछ इस तरह से परिवर्तित किया जाएगा:

 private static void lambda_forEach(String item) { // Java  System.out.println("Item = %s", item); } private static CallSite bootstrapLambda(Lookup lookup, String name, MethodType type) { // //lookup =  VM //name = "lambda_forEach",  VM //type = String -> void MethodHandle lambdaImplementation = lookup.findStatic(lookup.lookupClass(), name, type); return LambdaMetafactory.metafactory(lookup, "accept", MethodType.methodType(Consumer.class), //  - MethodType.methodType(void.class, Object.class), //  Consumer.accept    lambdaImplementation, //     - type); } void printElements(List<String> strings) { Consumer<String> lambda = invokedynamic# bootstrapLambda, #lambda_forEach strings.forEach(lambda); } 

invokedynamic निर्देश को मोटे तौर पर ऐसे जावा कोड के रूप में दर्शाया जा सकता है:

 private static CallSite cs; void printElements(List<String> strings) { Consumer<String> lambda; //begin invokedynamic if (cs == null) cs = bootstrapLambda(MethodHandles.lookup(), "lambda_forEach", MethodType.methodType(void.class, String.class)); lambda = (Consumer<String>)cs.getTarget().invokeExact(); //end invokedynamic strings.forEach(lambda); } 

जैसा कि आप देख सकते हैं, LambdaMetafactory का उपयोग LambdaMetafactory बनाने के लिए किया जाता है जो एक फैक्ट्री विधि प्रदान करता है जो लक्ष्य विधि के लिए एक हैंडलर देता है। यह विधि invokeExact का उपयोग करके कार्यात्मक इंटरफ़ेस का कार्यान्वयन invokeExact । यदि लैम्ब्डा अभिव्यक्ति में कैप्चर किए गए चर हैं, तो invokeExact इन चर को वास्तविक मापदंडों के रूप में स्वीकार करता है।

Oracle JRE 8 में, मेटाफ़ैक्चुअली गतिशील रूप से ObjectWeb Asm का उपयोग करके जावा वर्ग उत्पन्न करता है, जो एक वर्ग बनाता है जो एक कार्यात्मक इंटरफ़ेस लागू करता है। अतिरिक्त फ़ील्ड्स को बनाए गए वर्ग में जोड़ा जा सकता है यदि लैम्ब्डा एक्सप्रेशन बाहरी चर को कैप्चर करता है। यह जावा गुमनाम वर्गों की तरह दिखता है, लेकिन निम्नलिखित अंतर हैं:

• एक अनाम वर्ग जावा संकलक द्वारा उत्पन्न होता है।
• लैम्ब्डा अभिव्यक्ति को लागू करने के लिए वर्ग रनटाइम पर JVM द्वारा बनाया गया है।

मेटाफैक्टिक कार्यान्वयन जेवीएम विक्रेता और संस्करण पर निर्भर करता है

बेशक, invokedynamic का उपयोग केवल जावा में लैम्ब्डा अभिव्यक्तियों के लिए नहीं किया जाता है। जेवीएम वातावरण में गतिशील भाषाओं को चलाने के दौरान इसका मुख्य रूप से उपयोग किया जाता है। नैशॉर्न जावास्क्रिप्ट इंजन , जिसे जावा में बनाया गया है, इस निर्देश का भारी उपयोग करता है।

इसके बाद, हम LambdaMetafactory क्लास और उसकी क्षमताओं पर ध्यान केंद्रित करेंगे। निम्नलिखित
इस लेख का खंड मानता है कि आप बहुत अच्छी तरह से समझते हैं कि मेटाफैक्टिक तरीके कैसे काम करते हैं और MethodHandle क्या MethodHandle

लंबोदर भावों के साथ टोटके

इस अनुभाग में, हम यह दिखाएंगे कि रोजमर्रा के कार्यों में उपयोग के लिए गतिशील लैम्ब्डा कैसे बनाया जाए।

अपवादों और लंबोदर की जाँच की

यह कोई रहस्य नहीं है कि जावा में मौजूद सभी कार्यात्मक इंटरफेस चेक किए गए अपवादों का समर्थन नहीं करते हैं। नियमित रूप से जाँच किए गए अपवादों के फायदे बहुत लंबे समय तक (और अभी भी गर्म) बहस हैं।

लेकिन क्या होगा अगर आपको जावा स्ट्रीम के संयोजन में लैम्बडा एक्सप्रेशन के अंदर चेक किए गए अपवादों के साथ कोड का उपयोग करने की आवश्यकता है? उदाहरण के लिए, आपको स्ट्रिंग की सूची को URL की सूची में इस तरह परिवर्तित करना होगा:

 Arrays.asList("http://localhost/", "https://github.com").stream() .map(URL::new) .collect(Collectors.toList()) 

URL (स्ट्रिंग) के निर्माण में एक फेंकने योग्य अपवाद घोषित किया गया है, इसलिए इसे सीधे फंक्शनल क्लास में एक विधि संदर्भ के रूप में उपयोग नहीं किया जा सकता है।

आप कहेंगे: "नहीं, शायद अगर आप इस ट्रिक का उपयोग यहां करते हैं":

 public static <T> T uncheckCall(Callable<T> callable) { try { return callable.call(); } catch (Exception e) { return sneakyThrow(e); } } private static <E extends Throwable, T> T sneakyThrow0(Throwable t) throws E { throw (E)t; } public static <T> T sneakyThrow(Throwable e) { return Util.<RuntimeException, T>sneakyThrow0(e); } //   //return s.filter(a -> uncheckCall(a::isActive)) // .map(Account::getNumber) // .collect(toSet()); 

यह एक गंदी हैक है। और यहाँ क्यों है:

• ट्राइ-कैच ब्लॉक का उपयोग किया जाता है।
• अपवाद फिर से फेंक दिया जाता है।
• जावा में टाइप इरेज़र का गंदा उपयोग।

समस्या को और अधिक "कानूनी" तरीके से हल किया जा सकता है, निम्नलिखित तथ्यों के ज्ञान का उपयोग करके:

• चेक किए गए अपवाद जावा कंपाइलर स्तर पर ही पहचाने जाते हैं।
• throws सेक्शन जेवीएम स्तर पर सिमेंटिक वैल्यू के बिना एक विधि के लिए सिर्फ मेटाडेटा है।
• जाँच और सामान्य अपवाद JVM में बाइटकोड स्तर पर अप्रभेद्य हैं।

समाधान throws खंड के बिना एक विधि में Callable.call विधि को लपेटने के लिए है:

 static <V> V callUnchecked(Callable<V> callable){ return callable.call(); } 

यह कोड संकलित नहीं करता है क्योंकि Callable.call पद्धति Callable.call throws खंड में जाँच अपवाद घोषित किया है। लेकिन हम गतिशील रूप से निर्मित लैम्ब्डा अभिव्यक्ति का उपयोग करके इस अनुभाग को हटा सकते हैं।

पहले हमें एक कार्यात्मक इंटरफ़ेस घोषित करने की आवश्यकता है जिसमें throws सेक्शन नहीं है।
लेकिन कौन Callable.call कॉल प्रतिनिधि कर पाएगा:

 @FunctionalInterface interface SilentInvoker { MethodType SIGNATURE = MethodType.methodType(Object.class, Callable.class);//  INVOKE <V> V invoke(final Callable<V> callable); } 

दूसरा कदम है LambdaMetafactory का उपयोग करके इस इंटरफेस का LambdaMetafactory और SilentInvoker.invoke विधि को SilentInvoker.invoke विधि का कॉल प्रतिनिधि करना। जैसा कि पहले उल्लेख किया गया है, SilentInvoker.invoke को SilentInvoker.invoke स्तर पर नजरअंदाज किया जाता है, इसलिए SilentInvoker.invoke विधि अपवाद घोषित किए बिना Callable.call विधि को कॉल कर सकती है:

 private static final SilentInvoker SILENT_INVOKER; final MethodHandles.Lookup lookup = MethodHandles.lookup(); final CallSite site = LambdaMetafactory.metafactory(lookup, "invoke", MethodType.methodType(SilentInvoker.class), SilentInvoker.SIGNATURE, lookup.findVirtual(Callable.class, "call", MethodType.methodType(Object.class)), SilentInvoker.SIGNATURE); SILENT_INVOKER = (SilentInvoker) site.getTarget().invokeExact(); 

तीसरा, हम एक सहायक विधि लिखते हैं जो अपवाद घोषित किए बिना Callable.call को कॉल करता है:

 public static <V> V callUnchecked(final Callable<V> callable) /*no throws*/ { return SILENT_INVOKER.invoke(callable); } 

अब आप चेक किए गए अपवादों के साथ किसी भी समस्या के बिना स्ट्रीम को फिर से लिख सकते हैं:

 Arrays.asList("http://localhost/", "https://dzone.com").stream() .map(url -> callUnchecked(() -> new URL(url))) .collect(Collectors.toList()); 

यह कोड समस्याओं के बिना संकलित करता है क्योंकि callUnchecked चेक किए गए अपवादों की घोषणा नहीं करता है। इसके अलावा, इस पद्धति को कॉल करना मोनोमोर्फिक इनलाइन कैशिंग का उपयोग करके इनलाइन किया जा सकता है, क्योंकि यह पूरे जेवीएम में केवल एक वर्ग है जो SilentOnvoker इंटरफ़ेस लागू करता है

यदि Callable.call का कार्यान्वयन रन समय में अपवाद फेंकता है, तो इसे कॉलिंग फ़ंक्शन द्वारा बिना किसी समस्या के Callable.call जाएगा:

 try{ callUnchecked(() -> new URL("Invalid URL")); } catch (final Exception e){ System.out.println(e); } 

इस पद्धति की संभावनाओं के बावजूद, आपको हमेशा निम्नलिखित अनुशंसा को याद रखना चाहिए:

कॉल किए गए अपवादों के साथ चेक किए गए अपवादों को छिपाएं केवल यदि आप सुनिश्चित हैं कि कॉल कोड कोई अपवाद नहीं फेंकेंगे

निम्न उदाहरण इस दृष्टिकोण का एक उदाहरण दिखाता है:

 callUnchecked(() -> new URL("https://dzone.com")); // URL        MalformedURLException 

इस पद्धति का पूर्ण कार्यान्वयन यहां है , यह SNAMP ओपन सोर्स प्रोजेक्ट का हिस्सा है।

गेटर्स एंड सेटर्स के साथ काम करना

यह अनुभाग उन लोगों के लिए उपयोगी होगा जो विभिन्न डेटा प्रारूपों जैसे कि JSON, थ्रिफ्ट, इत्यादि के लिए क्रमांकन / deserialization लिखते हैं। इसके अलावा, यह काफी उपयोगी हो सकता है यदि आपका कोड JavaBeans में गेटर्स और सेटर्स के लिए प्रतिबिंब पर बहुत अधिक निर्भर करता है।

जावाबीन में घोषित एक गेटटर एक ऐसी विधि है जिसका नाम getXXX जिसमें कोई पैरामीटर नहीं है और void अलावा एक रिटर्न डेटा प्रकार है। जावाबीन में घोषित एक setXXX नामक एक विधि है, जिसमें एक पैरामीटर और रिटर्निंग void । इन दो सूचनाओं को कार्यात्मक इंटरफेस के रूप में दर्शाया जा सकता है:

• गेट्टर को फंक्शन क्लास द्वारा दर्शाया जा सकता है, जिसमें तर्क इस का मूल्य है।
• सेटर को BiConsumer वर्ग द्वारा दर्शाया जा सकता है, जिसमें पहला तर्क this , और दूसरा वह मान है जो सेटर को दिया गया है।

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

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

 private static final Cache<Method, Function> GETTERS = CacheBuilder.newBuilder().weakValues().build(); private static final Cache<Method, BiConsumer> SETTERS = CacheBuilder.newBuilder().weakValues().build(); 

दूसरे, हम कारखाने के तरीकों का निर्माण करेंगे जो कि गटर या सेटर के संदर्भ में कार्यात्मक इंटरफ़ेस का एक उदाहरण बनाते हैं।

 private static Function createGetter(final MethodHandles.Lookup lookup, final MethodHandle getter) throws Exception{ final CallSite site = LambdaMetafactory.metafactory(lookup, "apply", MethodType.methodType(Function.class), MethodType.methodType(Object.class, Object.class), //signature of method Function.apply after type erasure getter, getter.type()); //actual signature of getter try { return (Function) site.getTarget().invokeExact(); } catch (final Exception e) { throw e; } catch (final Throwable e) { throw new Error(e); } } private static BiConsumer createSetter(final MethodHandles.Lookup lookup, final MethodHandle setter) throws Exception { final CallSite site = LambdaMetafactory.metafactory(lookup, "accept", MethodType.methodType(BiConsumer.class), MethodType.methodType(void.class, Object.class, Object.class), //signature of method BiConsumer.accept after type erasure setter, setter.type()); //actual signature of setter try { return (BiConsumer) site.getTarget().invokeExact(); } catch (final Exception e) { throw e; } catch (final Throwable e) { throw new Error(e); } } 

कार्यात्मक इंटरफेस (टाइप एरासुरे के बाद) और वास्तविक प्रकार के तर्कों और रिटर्न वैल्यू में Object के प्रकार के तर्कों के बीच स्वचालित प्रकार रूपांतरण samMethodType और samMethodType (क्रमशः, मेटाफैक्ट विधि के तीसरे और पांचवें तर्क) के बीच अंतर का उपयोग करके हासिल किया जाता है। विधि के बनाए गए उदाहरण का प्रकार - यह उस विधि का विशेषज्ञता है जो लंबोदर अभिव्यक्ति के कार्यान्वयन को प्रदान करता है।

तीसरा, हम इन फैक्टरियों के लिए कैशिंग के समर्थन से एक मुखौटा बनाएंगे:

 public static Function reflectGetter(final MethodHandles.Lookup lookup, final Method getter) throws ReflectiveOperationException { try { return GETTERS.get(getter, () -> createGetter(lookup, lookup.unreflect(getter))); } catch (final ExecutionException e) { throw new ReflectiveOperationException(e.getCause()); } } public static BiConsumer reflectSetter(final MethodHandles.Lookup lookup, final Method setter) throws ReflectiveOperationException { try { return SETTERS.get(setter, () -> createSetter(lookup, lookup.unreflect(setter))); } catch (final ExecutionException e) { throw new ReflectiveOperationException(e.getCause()); } } 

जावा प्रतिबिंब एपीआई का उपयोग करके Method वर्ग के एक उदाहरण से प्राप्त विधि जानकारी आसानी से एक MethodHandle परिवर्तित हो MethodHandle । इस बात को ध्यान में रखें कि कक्षा के उदाहरण के तरीकों में हमेशा एक छिपा हुआ पहला तर्क होता है, जो इस विधि को पास करने के लिए उपयोग किया जाता है। स्टैटिक विधियों में ऐसा कोई पैरामीटर नहीं है। उदाहरण के लिए, Integer.intValue() पद्धति का वास्तविक हस्ताक्षर int intValue(Integer this) जैसा दिखता है। इस चाल का उपयोग गेटर्स और सेटर के लिए कार्यात्मक आवरण के हमारे कार्यान्वयन में किया जाता है।

और अब कोड का परीक्षण करने का समय है:

 final Date d = new Date(); final BiConsumer<Date, Long> timeSetter = reflectSetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("setTime", long.class)); timeSetter.accept(d, 42L); //the same as d.setTime(42L); final Function<Date, Long> timeGetter = reflectGetter(MethodHandles.lookup(), Date.class.getDeclaredMethod("getTime")); System.out.println(timeGetter.apply(d)); //the same as d.getTime() //output is 42 

कैश्ड गेटर्स और सेटर के साथ इस दृष्टिकोण को प्रभावी रूप से क्रमांकन / डिसेरिएलाइज़ेशन लाइब्रेरी (जैसे जैक्सन) में उपयोग किया जा सकता है जो क्रमांकन और डीरिएलाइज़ेशन के दौरान गेटर्स और सेटर का उपयोग करते हैं।

LambdaMetaFactory उपयोग करके गतिशील रूप से उत्पन्न कार्यान्वयन के साथ कार्यात्मक इंटरफेस को कॉल करना जावा परावर्तन एपीआई के माध्यम से कॉल करने की तुलना LambdaMetaFactory काफी तेज है

कोड का पूर्ण संस्करण यहां पाया जा सकता है , यह SNAMP लाइब्रेरी का हिस्सा है।

सीमाएँ और कीड़े

इस खंड में, हम जावा कंपाइलर और जेवीएम में लैम्ब्डा अभिव्यक्तियों से जुड़े कुछ बग और सीमाओं को देखेंगे। इन सभी सीमाओं को OpenJDK और Oracle JDK में विंडोज और लिनक्स के लिए javac संस्करण 1.8.0_131 के साथ पुन: प्रस्तुत किया जा सकता है।

विधि संचालकों से लंबोदर भाव बनाना

जैसा कि आप जानते हैं, लैम्ब्डामैटाफैक्टिक का उपयोग करके एक लैम्ब्डा अभिव्यक्ति का निर्माण गतिशील रूप से किया जा सकता है। ऐसा करने के लिए, आपको एक हैंडलर - MethodHandle क्लास को परिभाषित करने की आवश्यकता है, जो कार्यात्मक इंटरफ़ेस में परिभाषित एकमात्र विधि के कार्यान्वयन को इंगित करता है। आइए इस सरल उदाहरण पर एक नज़र डालें:

 final class TestClass { String value = ""; public String getValue() { return value; } public void setValue(final String value) { this.value = value; } } final TestClass obj = new TestClass(); obj.setValue("Hello, world!"); final MethodHandles.Lookup lookup = MethodHandles.lookup(); final CallSite site = LambdaMetafactory.metafactory(lookup, "get", MethodType.methodType(Supplier.class, TestClass.class), MethodType.methodType(Object.class), lookup.findVirtual(TestClass.class, "getValue", MethodType.methodType(String.class)), MethodType.methodType(String.class)); final Supplier<String> getter = (Supplier<String>) site.getTarget().invokeExact(obj); System.out.println(getter.get()); 

यह कोड इसके बराबर है:

 final TestClass obj = new TestClass(); obj.setValue("Hello, world!"); final Supplier<String> elementGetter = () -> obj.getValue(); System.out.println(elementGetter.get()); 

लेकिन क्या होगा अगर हम विधि हैंडलर की जगह लेते हैं जो कि हैंडलर के साथ getValue को इंगित करता है कि गेट्टर फ़ील्ड प्रतिनिधित्व करते हैं:

 final CallSite site = LambdaMetafactory.metafactory(lookup, "get", MethodType.methodType(Supplier.class, TestClass.class), MethodType.methodType(Object.class), lookup.findGetter(TestClass.class, "value", String.class), //field getter instead of method handle to getValue MethodType.methodType(String.class)); 

यह कोड, जैसा कि अपेक्षित था, काम करना चाहिए क्योंकि findGetter एक हैंडलर देता है जो गेटर फ़ील्ड्स को इंगित करता है और सही हस्ताक्षर है। लेकिन, यदि आप इस कोड को चलाते हैं, तो आपको निम्न अपवाद दिखाई देंगे:

 java.lang.invoke.LambdaConversionException: Unsupported MethodHandle kind: getField 

यदि हम MethodHandleProxies का उपयोग करते हैं, तो दिलचस्प है, क्षेत्र के लिए गेट्टर ठीक काम करता है:

 final Supplier<String> getter = MethodHandleProxies .asInterfaceInstance(Supplier.class, lookup.findGetter(TestClass.class, "value", String.class) .bindTo(obj)); 

यह ध्यान दिया जाना चाहिए कि MethodHandleProxies गतिशील रूप से MethodHandleProxies अभिव्यक्तियों को बनाने का एक अच्छा तरीका नहीं है, क्योंकि यह वर्ग केवल एक प्रॉक्सी वर्ग में MethodHandle को लपेटता है और invocationHandler.invoke को MethodHandle.vokeWithArguments को दर्शाता है । यह दृष्टिकोण जावा रिफ्लेक्शन का उपयोग करता है और बहुत धीमा है।

जैसा कि पहले दिखाया गया है, रनटाइम में लैम्बडा एक्सप्रेशन बनाने के लिए सभी मेथड हैंडलर का इस्तेमाल नहीं किया जा सकता है।

केवल कुछ प्रकार के विधि संचालकों का उपयोग गतिशील रूप से लंबोदर अभिव्यक्ति बनाने के लिए किया जा सकता है।

यहाँ वे हैं:

• REF_invokeInterface: इंटरफ़ेस विधियों के लिए Lookup.findVirtual का उपयोग करके बनाया जा सकता है
• REF_invokeVirtual: क्लास वर्चुअल तरीकों के लिए Lookup.findVirtual का उपयोग करके बनाया जा सकता है
• REF_invokeStatic: स्थिर तरीकों के लिए Lookup.findStatic का उपयोग करके बनाया गया
• REF_newInvokeSpecial: निर्माणकर्ताओं के लिए Lookup.findConstructor का उपयोग करके बनाया जा सकता है
• REF_invokeSpecial: Lookup.findSpecial का उपयोग करके बनाया जा सकता है
  निजी तरीकों और कक्षा आभासी तरीकों के साथ शुरुआती बाध्यकारी के लिए

अन्य प्रकार के हैंडलर LambdaConversionException त्रुटि को LambdaConversionException देंगे।

सामान्य अपवाद

यह बग जावा कंपाइलर और throws सेक्शन में जेनेरिक अपवादों को फेंकने की क्षमता से संबंधित है। निम्न कोड उदाहरण इस व्यवहार को प्रदर्शित करता है:

 interface ExtendedCallable<V, E extends Exception> extends Callable<V>{ @Override V call() throws E; } final ExtendedCallable<URL, MalformedURLException> urlFactory = () -> new URL("http://localhost"); urlFactory.call(); 

इस कोड को संकलित करना होगा क्योंकि URL वर्ग का निर्माता एक MalformedURLException फेंकता है। लेकिन यह संकलन नहीं करता है। निम्न त्रुटि संदेश प्रदर्शित होता है:

 Error:(46, 73) java: call() in <anonymous Test$CODEgt; cannot implement call() in ExtendedCallable overridden method does not throw java.lang.Exception 

लेकिन, अगर हम लैम्बडा एक्सप्रेशन को एक अनाम वर्ग से बदल देते हैं, तो कोड संकलित करता है:

 final ExtendedCallable<URL, MalformedURLException> urlFactory = new ExtendedCallable<URL, MalformedURLException>() { @Override public URL call() throws MalformedURLException { return new URL("http://localhost"); } }; urlFactory.call(); 

यह इस प्रकार है:

जेनेरिक अपवादों के लिए प्रकार का निष्कर्ष लैम्ब्डा अभिव्यक्तियों के संयोजन में सही ढंग से काम नहीं करता है

पैरामीटर प्रकार की सीमाएं

आप & का उपयोग करके कई प्रकार के प्रतिबंधों के साथ एक सामान्य वस्तु का निर्माण कर सकते हैं: <T extends A & B & C & ... Z> चिह्न है।
जेनेरिक मापदंडों को निर्धारित करने की इस पद्धति का उपयोग शायद ही कभी किया जाता है, लेकिन एक निश्चित तरीके से कुछ प्रतिबंधों के कारण जावा में लंबोदर भाव प्रभावित होते हैं:

• प्रत्येक प्रकार की बाधा, पहले को छोड़कर, एक इंटरफ़ेस होना चाहिए।
• ऐसी जेनेरिक के साथ एक वर्ग का शुद्ध संस्करण केवल सूची से पहले प्रकार की बाधा को ध्यान में रखता है।

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

 final class MutableInteger extends Number implements IntSupplier, IntConsumer { //mutable container of int value private int value; public MutableInteger(final int v) { value = v; } @Override public int intValue() { return value; } @Override public long longValue() { return value; } @Override public float floatValue() { return value; } @Override public double doubleValue() { return value; } @Override public int getAsInt() { return intValue(); } @Override public void accept(final int value) { this.value = value; } } static <T extends Number & IntSupplier> OptionalInt findMinValue(final Collection <T> values) { return values.stream().mapToInt(IntSupplier::getAsInt).min(); } final List <MutableInteger> values = Arrays.asList(new MutableInteger(10), new MutableInteger(20)); final int mv = findMinValue(values).orElse(Integer.MIN_VALUE); System.out.println(mv); 

यह कोड बिल्कुल सही है और सफलतापूर्वक संकलन करता है। MutableInteger वर्ग जेनेरिक प्रकार T की बाधाओं को संतुष्ट करता है:

• MutableInteger Number से विरासत में मिला है।
• MutableInteger लागू IntSupplier ।

लेकिन रनटाइम पर अपवाद के साथ कोड क्रैश हो जाएगा:

 java.lang.BootstrapMethodError: call site initialization exception at java.lang.invoke.CallSite.makeSite(CallSite.java:341) at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:307) at java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:297) at Test.minValue(Test.java:77) Caused by: java.lang.invoke.LambdaConversionException: Invalid receiver type class java.lang.Number; not a subtype of implementation type interface java.util.function.IntSupplier at java.lang.invoke.AbstractValidatingLambdaMetafactory.validateMetafactoryArgs(AbstractValidatingLambdaMetafactory.java:233) at java.lang.invoke.LambdaMetafactory.metafactory(LambdaMetafactory.java:303) at java.lang.invoke.CallSite.makeSite(CallSite.java:302) 

ऐसा इसलिए होता है क्योंकि JavaStream पाइपलाइन केवल एक शुद्ध प्रकार को पकड़ती है, जो हमारे मामले में, Number वर्ग है और यह IntSupplier इंटरफ़ेस को लागू नहीं करता है। इस समस्या को स्पष्ट रूप से एक अलग विधि में पैरामीटर प्रकार घोषित करके तय किया जा सकता है, जिसका उपयोग विधि के संदर्भ के रूप में किया जाता है:

 private static int getInt(final IntSupplier i){ return i.getAsInt(); } private static <T extends Number & IntSupplier> OptionalInt findMinValue(final Collection<T> values){ return values.stream().mapToInt(UtilsTest::getInt).min(); } 

यह उदाहरण संकलक और रनटाइम में गलत प्रकार के निष्कर्ष को प्रदर्शित करता है।

संकलित समय और रनटाइम पर लैम्ब्डा अभिव्यक्तियों का उपयोग करने के साथ संयोजन में कई सामान्य पैरामीटर प्रकार के प्रतिबंधों को संभालना सुसंगत नहीं है