चीजें आप [शायद] जावा के बारे में नहीं जानते थे

अभिवादन, पाठक!

यह लेख उत्पादकता के बारे में मेरी चेतना की धारा को पतला करेगा। आइए जावा और आपके आस-पास ऐसी मज़ेदार चीज़ों के बारे में बात करते हैं जिनके बारे में आप शायद नहीं जानते। मैंने खुद हाल ही में उपरोक्त में से कुछ के बारे में सीखा है, इसलिए मेरा मानना ​​है कि अधिकांश पाठक कम से कम अपने लिए कुछ दिलचस्प क्षण पाएंगे।

मुखर 2 तर्क ले सकते हैं

आमतौर पर, assert उपयोग कुछ स्थिति की जांच करने के लिए किया जाता है और यदि स्थिति संतुष्ट नहीं होती है, तो AssertionError फेंक देता है। सबसे अधिक बार, चेक इस तरह दिखता है:

 assert list.isEmpty(); 

हालाँकि, यह इस तरह हो सकता है:

 assert list.isEmpty() : list.toString(); 

स्मार्ट रीडर ने पहले ही अनुमान लगा लिया है कि दूसरी अभिव्यक्ति (संयोगवश, यह आलसी है) टाइप Object का मान लौटाता है, जिसे AssertionError को पास किया जाता है और उपयोगकर्ता को त्रुटि के बारे में अतिरिक्त जानकारी देता है। अधिक औपचारिक विवरण के लिए, भाषा विनिर्देश के संबंधित अनुभाग देखें: https://docs.oracle.com/javase/specs/jls/se13/html/jls-14.html#jls-14.10

जावा के साथ काम करने के लगभग साढ़े 6 वर्षों के लिए, मैंने केवल एक बार assert कीवर्ड का विस्तारित उपयोग देखा है।

strictfp

यह एक अभिशाप शब्द नहीं है - यह एक अल्पज्ञात खोजशब्द है। प्रलेखन के अनुसार, इसके उपयोग में फ्लोटिंग पॉइंट संख्याओं के लिए सख्त अंकगणित शामिल हैं:

 public interface NonStrict { float sum(float a, float b); } 

में बदल सकते हैं

 public strictfp interface Strict { float sum(float a, float b); } 

साथ ही, इस कीवर्ड को अलग-अलग तरीकों से लागू किया जा सकता है:

 public interface Mixed { float sum(float a, float b); strictfp float strictSum(float a, float b); } 

विकी लेख में इसके उपयोग के बारे में और पढ़ें। संक्षेप में: पोर्टेबिलिटी सुनिश्चित करने के लिए एक बार यह कीवर्ड जोड़ा गया था, जैसा कि विभिन्न प्रोसेसरों पर फ्लोटिंग पॉइंट नंबरों की प्रोसेसिंग की सटीकता अलग हो सकती है।

जारी रखना एक तर्क ले सकता है

मुझे पिछले हफ्ते इसके बारे में पता चला। आमतौर पर हम इस तरह लिखते हैं:

 for (Item item : items) { if (item == null) { continue; } use(item); } 

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

 loop: for (Item item : items) { if (item == null) { continue loop; } use(item); } 

हालाँकि, आप चक्र से बाह्य चक्र पर लौट सकते हैं, यदि कोई हो:

 @Test void test() { outer: for (int i = 0; i < 20; i++) { for (int j = 10; j < 15; j++) { if (j == 13) { continue outer; } } } } 

ध्यान दें कि outer बिंदु पर लौटने पर काउंटर रीसेट नहीं होता है, इसलिए लूप परिमित होता है।

जब कोई तर्क के साथ वार्ग विधि को बुलाते हैं, तो एक खाली सरणी बनाई जाती है

जब हम बाहर से ऐसी विधि की कॉल को देखते हैं, तो ऐसा लगता है कि चिंता करने की कोई बात नहीं है:

 @Benchmark public Object invokeVararg() { return vararg(); } 

हम इस पद्धति में कुछ भी नहीं कर पाए, क्या हमने? लेकिन अगर आप अंदर से देखते हैं, तो सब कुछ इतना रसीला नहीं है:

 public Object[] vararg(Object... args) { return args; } 

अनुभव चिंताओं की पुष्टि करता है:

 Benchmark Mode Cnt Score Error Units invokeVararg avgt 20 3,715 ± 0,092 ns/op invokeVararg:·gc.alloc.rate.norm avgt 20 16,000 ± 0,001 B/op invokeVararg:·gc.count avgt 20 257,000 counts 

आप null होकर अनावश्यक तर्क से छुटकारा पा सकते हैं:

 @Benchmark public Object invokeVarargWithNull() { return vararg(null); } 

कचरा संग्रहकर्ता वास्तव में बेहतर महसूस करता है:

 invokeVarargWithNull avgt 20 2,415 ± 0,067 ns/op invokeVarargWithNull:·gc.alloc.rate.norm avgt 20 ≈ 10⁻⁵ B/op invokeVarargWithNull:·gc.count avgt 20 ≈ 0 counts 

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

स्विच-केस एक्सप्रेशन java.lang.Class का समर्थन नहीं करता है

यह कोड अभी संकलित नहीं है:

 String to(Class<?> clazz) { switch (clazz) { case String.class: return "str"; case Integer.class: return "int"; default: return "obj"; } } 

इससे निपटो।

असाइनमेंट और Class.isAssignableFrom () की सूक्ष्मताएं

एक कोड है:

 int a = 0; Integer b = 10; a = b; //    

अब सोचें कि यह विधि किस मूल्य पर लौटेगी:

 boolean check(Integer b) { return int.class.isAssignableFrom(b.getClass()); } 

Class.isAssignableFrom() विधि का नाम पढ़ने के बाद, Class.isAssignableFrom() गलत धारणा देता है कि अभिव्यक्ति int.class.isAssignableFrom(b.getClass()) true वापस आ जाएगी। हम प्रकार के एक चर को int प्रकार के एक चर को असाइन कर सकते हैं, क्या हम कर सकते हैं?

हालाँकि, check() विधि false आएगी, क्योंकि दस्तावेज़ में स्पष्ट रूप से कहा गया है कि:

 /** * Determines if the class or interface represented by this * {@code Class} object is either the same as, or is a superclass or * superinterface of, the class or interface represented by the specified * {@code Class} parameter. It returns {@code true} if so; * otherwise it returns {@code false}. If this {@code Class} // <---- !!! * object represents a primitive type, this method returns * {@code true} if the specified {@code Class} parameter is * exactly this {@code Class} object; otherwise it returns * {@code false}. * */ @HotSpotIntrinsicCandidate public native boolean isAssignableFrom(Class<?> cls); 

हालांकि int Integer (और इसके विपरीत) का उत्तराधिकारी नहीं है, संभावित आपसी असाइनमेंट भाषा की एक विशेषता है, और उपयोगकर्ताओं को गुमराह न करने के लिए, प्रलेखन में एक विशेष आरक्षण दिया जाता है।

नैतिक: जब ऐसा लगता है - बपतिस्मा लेने की आवश्यकता है प्रलेखन को फिर से पढ़ने की जरूरत है।

इस उदाहरण से एक और तथ्यहीन तथ्य सामने आया है:

 assert int.class != Integer.class; 

int.class क्लास वास्तव में Integer.TYPE , और इसे देखने के लिए, बस यह देखें कि यह कोड क्या संकलित किया जाएगा:

 Class<?> toClass() { return int.class; } 

Vzhuh:

 toClass()Ljava/lang/Class; L0 LINENUMBER 11 L0 GETSTATIC java/lang/Integer.TYPE : Ljava/lang/Class; ARETURN 

Java.lang.Integer के लिए स्रोत कोड खोलना java.lang.Integer हम इसे देखेंगे:

 @SuppressWarnings("unchecked") public static final Class<Integer> TYPE = (Class<Integer>) Class.getPrimitiveClass("int"); 

Class.getPrimitiveClass("int") पर कॉल को देखते हुए Class.getPrimitiveClass("int") इसे काटने और इसे बदलने के लिए लुभाया जा सकता है:

 @SuppressWarnings("unchecked") public static final Class<Integer> TYPE = int.class; 

सबसे आश्चर्यजनक बात यह है कि इसी तरह के बदलाव (सभी प्राइमेटीज़ के लिए) के साथ JDK इकट्ठा होगा, और वर्चुअल मशीन शुरू होगी। सच है, वह लंबे समय तक काम नहीं करेगी:

 java.lang.IllegalArgumentException: Component type is null at jdk.internal.misc.Unsafe.allocateUninitializedArray(java.base/Unsafe.java:1379) at java.lang.StringConcatHelper.newArray(java.base/StringConcatHelper.java:458) at java.lang.StringConcatHelper.simpleConcat(java.base/StringConcatHelper.java:423) at java.lang.String.concat(java.base/String.java:1968) at jdk.internal.util.SystemProps.fillI18nProps(java.base/SystemProps.java:165) at jdk.internal.util.SystemProps.initProperties(java.base/SystemProps.java:103) at java.lang.System.initPhase1(java.base/System.java:2002) 

त्रुटि यहाँ क्रॉल करती है:

 class java.lang.StringConcatHelper { @ForceInline static byte[] newArray(long indexCoder) { byte coder = (byte)(indexCoder >> 32); int index = (int)indexCoder; return (byte[]) UNSAFE.allocateUninitializedArray(byte.class, index << coder); //<-- } } 

उल्लिखित परिवर्तनों के साथ, byte.class शून्य हो जाता है और सुरक्षा को तोड़ देता है।

स्प्रिंग डेटा जेपीए आंशिक रूप से कार्यात्मक भंडार की घोषणा करता है

मैं एक उत्सुक गलती के साथ लेख को समाप्त करता हूं जो स्प्रिंग डेट और हाइबरनेट के जंक्शन पर उत्पन्न हुआ था। याद रखें कि हम एक निश्चित इकाई की सेवा करने वाले एक भंडार की घोषणा कैसे करते हैं:

 @Entity public class SimpleEntity { @Id private Integer id; @Column private String name; } public interface SimpleRepository extends JpaRepository<SimpleEntity, Integer> { } 

अनुभवी उपयोगकर्ता जानते हैं कि संदर्भ उठाते समय, स्प्रिंग दिनांक सभी रिपॉजिटरी की जांच करती है और वर्णन करने की कोशिश करते समय तुरंत पूरे एप्लिकेशन को नष्ट कर देती है, उदाहरण के लिए, एक क्वेरी वक्र:

 public interface SimpleRepository extends JpaRepository<SimpleEntity, Integer> { @Query(", ,  ?") Optional<SimpleEntity> findLesserOfTwoEvils(); } 

हालाँकि, कुछ भी हमें एक मुख्य कुंजी प्रकार के साथ भंडार की घोषणा करने से नहीं रोकता है:

 public interface SimpleRepository extends JpaRepository<SimpleEntity, Long> { } 

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

 IllegalArgumentException: Provided id of the wrong type for class SimpleEntity. Expected: class java.lang.Integer, got class java.lang.Long 

बात यह है कि स्प्रिंग दिनांक इकाई कुंजी और उससे जुड़ी रिपॉजिटरी की कुंजी की कक्षाओं की तुलना नहीं करता है। यह एक अच्छे जीवन से नहीं होता है, लेकिन कुछ मामलों में सही कुंजी प्रकार जारी करने के लिए हाइबरनेट की अक्षमता के कारण: https://hibernate.atlassian.net/browse/HHH-10690

मेरे जीवन में मुझे यह केवल एक बार मिला: स्प्रिंग डेट्स के परीक्षणों (ट्रॉली) में, उदाहरण के लिए, org.springframework.data.jpa.repository.query.PartTreeJpaQueryIntegrationTests$UserRepository Long में टाइप किया जाता Integer , और User इकाई में Integer उपयोग किया जाता है। और यह काम करता है!

यह सब, मुझे उम्मीद है कि मेरी समीक्षा आपके लिए उपयोगी और दिलचस्प थी।

मैं आपको नए साल की बधाई देता हूं और आपको गहरी और व्यापक खुदाई करने की कामना करता हूं!