मैं आज सोना चाहता था, लेकिन फिर असफल हो गया। टेलीग्राम में एक संदेश दिखाई दिया कि कोई व्यक्ति जावा नहीं जा रहा था ... और हम कुछ घंटों के बाद ही थक गए और खुश हो गए।

इस पोस्ट का उपयोग कौन कर सकता है? हां, शायद उन लोगों को छोड़कर जो JDK8 इकट्ठा करते हैं या केवल दुःस्वप्न भयावहता को पढ़ने के लिए प्यार करते हैं। सामान्य तौर पर, मैंने आपको चेतावनी दी है, लेख को तत्काल बंद करें।

तीन समस्याएं:

• नहीं जा रहा ( स्तर एक )
  स्किप करने के लिए एक बहुत उबाऊ हिस्सा। केवल उन लोगों के लिए आवश्यक है जो घटनाओं के इतिहास को पूरी तरह से बहाल करना चाहते हैं;
• नहीं जा रहा ( स्तर दो )
  यह अधिक दिलचस्प है क्योंकि विशिष्ट गलतियों, नेक्रोमेंसी, नेक्रोफिलिया के कुछ जोड़े हैं, जो बीएसडी जीएनयू / लिनक्स से बेहतर है और यह जेडीके के नए संस्करणों पर स्विच करने के लायक क्यों है।
• यहां तक ​​कि अगर यह जा रहा है, यह पपड़ी में गिर जाता है
  अधिक दिलचस्प है। याहु, JVM पपड़ी में गिर गया, चलो इसे लात मारो!

बिल्ली के नीचे जीवन के बारे में अलग-अलग विचारों के साथ, समस्याओं का विस्तृत समाधान दिखाया गया है।

बहुत सारे C ++ होंगे, कोई जावा कोड नहीं होगा। अंत में किसी भी जावेद ने केवल C ++ में लिखना शुरू किया ...

नहीं जा रहा है

जिसने भी कम से कम एक बार जावा का निर्माण किया है, वह जानता है कि यह कुछ इस तरह दिखता है:

hg clone http://hg.openjdk.java.net/jdk8u/jdk8u cd jdk8u sh ./get_source.sh sh ./configure \ --with-debug-level=fastdebug \ --with-target-bits=64 \ --with-native-debug-symbols=internal \ --with-boot-jdk=/home/me/opt/jdk1.8.0_161 make images 

(मेरे सभी उपयोगकर्ताओं को बस "मुझे" कहा जाता है, ताकि आप किसी भी समय किसी भी व्यक्ति को वर्चुअल मशीन दे सकें और अपने स्वयं के उपयोगकर्ता नाम का उपयोग करने से अस्वीकृति पैदा न करें)

बेशक, समस्या यह है कि यह काम नहीं करता है। और बल्कि एक सनकी तरीके से।

पहला गोता स्तर

आइए चलाने की कोशिश करें:

 /home/me/git/jdk8u/hotspot/src/os/linux/vm/os_linux.inline.hpp:127:18: warning: 'int readdir_r(DIR*, dirent*, dirent**)' is deprecated [-Wdeprecated-declarations] if((status = ::readdir_r(dirp, dbuf, &p)) != 0) { ^~~~~~~~~ 

सबसे पहले, आपको समझने के लिए, मैंने इसे स्थापित किया है:

 $ g++ --version g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. 

संकलक पहले ताजगी नहीं है, 8.2 नहीं है, लेकिन यह भी काम करना चाहिए।

सी ++ डेवलपर्स केवल संकलक के संस्करण पर सॉफ़्टवेयर का परीक्षण करना पसंद करते हैं जो उन्होंने स्थापित किया है। आमतौर पर विभिन्न प्लेटफार्मों पर परीक्षण करने की इच्छा सामान्य अर्थ में gcc और clang के बीच के अंतर के क्षेत्र में कहीं समाप्त होती है। इसलिए, पहले रन- -Werror ("त्रुटियों के रूप में चेतावनी -Werror ") के लिए यह बिल्कुल सामान्य है और फिर अन्य सभी संस्करणों में कोड माना जाएगा।

यह एक ज्ञात समस्या है, और यह स्पष्ट है कि इसे कैसे हल किया जाए। आपको अपने पर्यावरण चर CXX_FLAGS को सेट करने की आवश्यकता है, जिसमें त्रुटियों का सही स्तर निर्धारित करना है।

 export CXX_FLAGS=-Wno-error=deprecated-declarations -Wno-error-deprecated-declarations 

और फिर हम अद्भुत देखते हैं:

 Ignoring CXXFLAGS found in environment. Use --with-extra-cxxflags 

ठीक है, सिस्टम का निर्माण, जो आप चाहते हैं! हम इसे एक से कॉन्फ़िगर करते हैं:

 hg clone http://hg.openjdk.java.net/jdk8u/jdk8u cd jdk8u sh ./configure \ --with-extra-cflags='-Wno-cpp -Wno-error=deprecated-declarations' \ --with-extra-cxxflags='-Wno-cpp -Wno-error=deprecated-declarations' \ --with-debug-level=fastdebug \ --with-target-bits=64 \ --with-native-debug-symbols=internal \ --with-boot-jdk=/home/me/opt/jdk1.8.0_161 make images 

और त्रुटि वही रहती है!
हम भारी तोपखाने से गुजरते हैं: स्रोत कोड।

 grep -rl "Werror" . 

किसी भी ऑटो-जेनरेट की गई टोपी की एक बड़ी मात्रा बाहर गिर जाती है, जिसके बीच सार्थक फाइलों की झलक होती है:

 ./common/autoconf/flags.m4 ./hotspot/make/bsd/makefiles/gcc.make ./hotspot/make/solaris/makefiles/gcc.make ./hotspot/make/aix/makefiles/xlc.make 

flags.m4 हम आसानी से "CXXFLAGS की अनदेखी" और अधिक परिपक्व हार्ड-कोडेड ध्वज CCXX_FLGS (हाँ, दो अक्षर C) के बारे में पिछला संदेश पाते हैं, जो तुरंत CFLAGS बजाय और XX_FLAGS बजाय कार्य करता है। सुविधाजनक! दो तथ्य दिलचस्प हैं:

• यह ध्वज कॉन्फ़िगर मापदंडों के माध्यम से पारित नहीं किया गया है;
• डिफ़ॉल्ट मान सार्थक और संदिग्ध रूप से इन मापदंडों के समान हैं:

  # Setup compiler/platform specific flags to CFLAGS_JDK, # CXXFLAGS_JDK and CCXXFLAGS_JDK (common to C and CXX?) if test "x$TOOLCHAIN_TYPE" = xgcc; then # these options are used for both C and C++ compiles CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -Wall -Wno-parentheses -Wextra -Wno-unused -Wno-unused-parameter -Wformat=2 \ -pipe -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE" 

यह सवाल टिप्पणियों में बहुत अच्छा लगता है - लेकिन क्या, झंडे आम हैं? सच?

हम लोकतंत्र और अधिनायकवादी रूप से इसे वहां हार्डकोड नहीं खेलेंगे - ("कोई त्रुटि नहीं दिखाते"):

  CCXXFLAGS_JDK="$CCXXFLAGS $CCXXFLAGS_JDK -w -ffreestanding -fno-builtin -Wno-parentheses -Wno-unused -Wno-unused-parameter -Wformat=2 \ 

और - चीयर्स! - पहली गलती हम पर हुई। वह अब रिपोर्टिंग नहीं कर रही है, और सामान्य तौर पर सब कुछ ठीक है। ऐसा लगता होगा।

दूसरा गोता स्तर

लेकिन अब यह अन्य नए स्थानों के ढेर में गिर रहा है!

यह पता चला है कि हमारे -w काम करता है, लेकिन विधानसभा के सभी हिस्सों को अग्रेषित नहीं किया जाता है। हम मेकफाइल्स को ध्यान से पढ़ते हैं और समझ नहीं पाते हैं कि वास्तव में इस पैरामीटर को कैसे आगे बढ़ाया जा सकता है। वास्तव में उसके बारे में भूल गए?

Google के सही सवाल ("क्यों निर्माण करने के लिए cxx नहीं मिलता है?") को जानने के बाद, हम जल्दी से बग पेज पर यह कहते हैं कि "कॉन्फ़िगर --with-extra-cxxflags हॉटस्पॉट को प्रभावित नहीं करता है" ( JDK-815367 )।

कौन सा वादा JDK 12. में तय हो सकता है। अद्भुत - विधानसभा में सबसे महत्वपूर्ण बिल्ड पैरामीटर का उपयोग नहीं किया जाता है!

पहला विचार है, ठीक है, चलो अपनी आस्तीन ऊपर रोल करें और गलतियों को ठीक करें!

त्रुटि 1.xn [12]

 dependencies.cpp: In function 'static void Dependencies::write_dependency_to(xmlStream*, Dependencies::DepType, GrowableArray<Dependencies::DepArgument>*, Klass*)': dependencies.cpp:498:6: error: '%d' directive writing between 1 and 10 bytes into a region of size 9 [-Werror=format-overflow=] void Dependencies::write_dependency_to(xmlStream* xtty, ^~~~~~~~~~~~ dependencies.cpp:498:6: note: directive argument in the range [0, 2147483647] 

खैर, हमें शायद इस क्षेत्र में विस्तार करने की आवश्यकता है। एक सौ पाउंड, किसी ने "आई एम लकी!" पर क्लिक करके बफर की गणना की। गूगल में।

लेकिन आप कैसे समझेंगे कि आपको कितनी जरूरत है? नीचे एक और प्रकार का शोधन है:

 stdio2.h:34:43: note: '__builtin___sprintf_chk' output between 3 and 12 bytes into a destination of size 10 __bos (__s), __fmt, __va_arg_pack ()); 

स्थिति 12 कुछ सार्थक लगती है, जिसके साथ अब आप गंदे पैरों के साथ स्रोत में टूट सकते हैं।

हम dependencies.cpp में चढ़ते हैं। dependencies.cpp और निम्न चित्र का निरीक्षण करें:

 DepArgument arg = args->at(j); if (j == 1) { if (arg.is_oop()) { xtty->object("x", arg.oop_value()); } else { xtty->object("x", arg.metadata_value()); } } else { char xn[10]; sprintf(xn, "x%d", j); if (arg.is_oop()) { xtty->object(xn, arg.oop_value()); } else { xtty->object(xn, arg.metadata_value()); } } 

समस्याग्रस्त रेखा पर ध्यान दें:

 char xn[10]; sprintf(xn, "x%d", j); 

हम 10 से 12 बदलते हैं, फिर से इकट्ठा होते हैं और ... विधानसभा चली गई है!

लेकिन क्या मैं केवल इतना ही चतुर हूं और सभी समय के बग को तय करता हूं? कोई सवाल नहीं, हम फिर से अपने मेगापैच को Google में डालते हैं: char xn[12];

और हम देखते हैं ... हाँ, यह सही है। व्लादिमीर JDK-8184309 , व्लादिमीर इवानोव द्वारा प्रतिबंधित, बिल्कुल उसी तरह के फिक्स होते हैं।

लेकिन लब्बोलुआब यह है कि यह केवल JDK 10 में तय किया गया है और nifiga को jdk8u के लिए वापस नहीं भेजा गया है। यह सवाल है कि जावा के नए संस्करणों की आवश्यकता क्यों है।

त्रुटि 2. स्ट्रैम्प

 fprofiler.cpp: In member function 'void ThreadProfiler::vm_update(TickPosition)': /home/me/git/jdk8ut/hotspot/src/share/vm/runtime/fprofiler.cpp:638:56: error: argument 1 null where non-null expected [-Werror=nonnull] bool vm_match(const char* name) const { return strcmp(name, _name) == 0; } 

पिछले कड़वे अनुभव से तंग आकर, हम तुरंत यह देखने के लिए जाते हैं कि जेडीके 11 में इस स्थान पर क्या है और ... यह फ़ाइल नहीं है। निर्देशिका संरचना भी कुछ refactoring से गुजरा है।

लेकिन आप हमसे दूर नहीं हो सकते!

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

सबसे पहले आपको मृतकों की आत्मा से अपील करनी चाहिए और पता लगाना चाहिए कि उनकी मृत्यु कब हुई:

 $ hg log --template "File(s) deleted in rev {rev}: {file_dels % '\n {file}'}\n\n" -r 'removes("**/fprofiler.cpp")' File(s) deleted in rev 47106: hotspot/src/share/vm/runtime/fprofiler.cpp hotspot/src/share/vm/runtime/fprofiler.hpp hotspot/test/runtime/MinimalVM/Xprof.java 

अब आपको उनकी मृत्यु का कारण जानने की आवश्यकता है:

 hg log -r 47106 changeset: 47106:bed18a111b90 parent: 47104:6bdc0c9c44af user: gziemski date: Thu Aug 31 20:26:53 2017 -0500 summary: 8173715: Remove FlatProfiler 

तो, हमारे पास एक हत्यारा है: gziemski । आइए जानें कि उसने इस दुर्भाग्यपूर्ण फ़ाइल को क्यों निकाला।

ऐसा करने के लिए, कमिट के सारांश में निर्दिष्ट टिकट में वसा पर जाएं। यह JDK-8173715 है :

FlatProfiler निकालें:
हम मानते हैं कि यह तकनीक अब उपयोग में नहीं है और जीसी के लिए रूट स्कैनिंग का एक स्रोत है।

शिह बीस के लिए। वास्तव में, अब हम लाश को ठीक करने के लिए आमंत्रित हैं ताकि निर्माण हो सके। जो इतना विघटित हो गया है कि OpenJDK के हमारे नेक्रोमांटर सहयोगियों ने भी इसे छोड़ दिया।

आइए मरे हुए आदमी को फिर से ज़िंदा करें और उससे यह पूछने की कोशिश करें कि उसे आखिर क्या याद था। वह संशोधन में पहले से ही मृत था 47106, जिसका अर्थ है कि संशोधन में एक कम है - यह "पहले से एक सेकंड" है:

 hg cat "~/git/jdk11/hotspot/src/share/vm/runtime/fprofiler.cpp" -r 47105 > ~/tmp/fprofiler_new.cpp cp ~/git/jdk8u/hotspot/src/share/vm/runtime/fprofiler.cpp ~/tmp/fprofiler_old.cpp cd ~/tmp diff fprofiler_old.cpp fprofiler_new.cpp 

दुर्भाग्य से, return strcmp(name, _name) == 0; संबंध में कुछ भी नहीं return strcmp(name, _name) == 0; नहीं में। एक कुंद तेज वस्तु (आरएम उपयोगिता) के साथ एक झटका से रोगी की मृत्यु हो गई, लेकिन मृत्यु के समय वह पहले से ही बीमार था।

आइए त्रुटि के सार में खुदाई करें।

यहाँ कोड लेखक हमें क्या बताना चाहेंगे:

  const char *name() const { return _name; } bool is_compiled() const { return true; } bool vm_match(const char* name) const { return strcmp(name, _name) == 0; } 

अब थोड़ा दर्शन।

खंड 7.1.4 में C11 मानक, "पुस्तकालय कार्यों का उपयोग", स्पष्ट रूप से कहता है:

निम्नलिखित कथनों में से प्रत्येक तब तक लागू होता है जब तक कि स्पष्ट रूप से विस्तृत विवरणों में अन्यथा वर्णित न हो: यदि किसी फ़ंक्शन का तर्क अमान्य मान (जैसे [...] एक अशक्त सूचक [...]] [...], व्यवहार अपरिभाषित है।

यही है, अब पूरा सवाल यह है कि क्या कुछ "स्पष्ट रूप से कहा गया है" । strcmp खंड में strcmp के वर्णन में इस तरह का कुछ भी नहीं लिखा गया है, और मेरे पास आपके लिए कोई अन्य अनुभाग नहीं है।

यानी हमारे यहां अपरिभाषित व्यवहार है।

बेशक, आप कोड के इस टुकड़े को ले सकते हैं और इसे फिर से लिख सकते हैं, इसके सत्यापन के साथ। लेकिन मुझे पूरी तरह से यकीन नहीं है कि मैं उन लोगों के तर्क को सही ढंग से समझता हूं जो यूबी का उपयोग करते हैं जहां यह नहीं होना चाहिए। उदाहरण के लिए, कुछ प्रणालियाँ शून्य dereferencing के लिए SIGSERV उत्पन्न करती हैं, और एक हैक प्रेमी इसका लाभ उठा सकता है, लेकिन यह व्यवहार अनिवार्य नहीं है और किसी अन्य प्लेटफ़ॉर्म पर शुरू हो सकता है।

हां, निश्चित रूप से, कोई कहेगा कि आप अपने लिए मूर्ख हैं, कि आप जीसीसी 7.3 का उपयोग कर रहे हैं, लेकिन जीसीसी 4 में सब कुछ इकट्ठा होगा। लेकिन अपरिभाषित व्यवहार! = अनिर्दिष्ट! = कार्यान्वयन परिभाषित। यह पिछले दो के लिए पुराने संकलक में काम करने के लिए निर्धारित किया जा सकता है। और छठे संस्करण में यूबी यूबी था।

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

एक और तरीका है

जैसा कि आप जानते हैं, अच्छे हीरो हमेशा घूमते हैं।

यहां तक ​​कि अगर हम यूबी के बारे में हमारे दर्शन को नजरअंदाज करते हैं, तो वहां अविश्वसनीय समस्याएं हैं। इस तथ्य पर नहीं कि सुबह तक उनकी मरम्मत की जा सकती है। इस तथ्य पर नहीं कि मैं इसे अपने कुटिल हाथों से नहीं कर सकता। इससे भी कम तथ्य यह है कि यह अपस्ट्रीम में स्वीकार किया जाएगा: jdk8u में अंतिम पैच 6 सप्ताह पहले था, और यह नए टैग का वैश्विक मर्ज था।

ज़रा सोचिए कि ऊपर दिया गया कोड वास्तव में सही लिखा गया है। वह सब जो हमारे और उसके निष्पादन के बीच खड़ा है, एक चेतावनी है, जिसे निर्माण प्रणाली में बग के कारण त्रुटि के रूप में माना जाता था। लेकिन हम एक बिल्ड सिस्टम बना सकते हैं।

रिविया के विचर गेराल्ट ने एक बार कहा था:

"बुराई बुराई है, Stregobor," चुड़ैल ने गंभीरता से कहा, उठ रहा है। - छोटे, बड़े, औसत - सब कुछ समान है, अनुपात मनमाना है, और सीमाएं धुंधली हैं। मैं एक पवित्र धर्मपरायण व्यक्ति नहीं हूँ, न केवल मैंने अपने जीवन में अच्छा किया है। लेकिन अगर आपको एक बुराई और दूसरे के बीच चयन करना है, तो मैं बिल्कुल नहीं चुनना पसंद करता हूं।

- Zło to zło, Stregoborze - rzekł powa wnie wiedźmin wstaj zc। - मिंज़्ज़े, विक्सज़े, ,rednie, wszystko jedno, proporcje spor umowne एक ग्रेनाइट जटार्ट। नी जेस्टेम ąwiątobliwym pustelnikiem, nie samo dobro czyniłem w ciyciu। एले जेएली मैम वायबिएरॉव पोमीzyडज़ी जेडेनिम ज़ालम ए ड्रिग्म, टू वोल, नी वेयबिएर वेक्ले।

यह द लास्ट विश का एक उद्धरण है, जो एक कहानी है जिसे लेवर एविल कहा जाता है। हम सभी जानते हैं कि गेराल्ट लगभग कभी भी एक तटस्थ चरित्र की भूमिका नहीं निभा सकता था, और यहां तक ​​कि एक और क्लासिक अराजक व्यवहार के कारण मर गया।

तो चलिए कम बुराई का एक त्वरित प्रदर्शन करते हैं। चलो निर्माण प्रणाली के बारे में जाने।

बहुत शुरुआत में, हमने पहले ही यह निकास देख लिया था:

 grep -rl "Werror" . ./common/autoconf/flags.m4 ./hotspot/make/linux/makefiles/gcc.make ./hotspot/make/bsd/makefiles/gcc.make ./hotspot/make/solaris/makefiles/gcc.make ./hotspot/make/aix/makefiles/xlc.make 

इन दो फाइलों की तुलना करने पर, मैंने चेहरे के साथ पूरे चेहरे को तोड़ दिया और दो प्लेटफार्मों की संस्कृति में अंतर का एहसास किया:

BSD स्वतंत्रता और पसंद के बारे में एक कहानी है:

 # Compiler warnings are treated as errors ifneq ($(COMPILER_WARNINGS_FATAL),false) WARNINGS_ARE_ERRORS = -Werror endif 

GNU / Linux एक सत्तावादी शुद्धतावादी शासन है:

 # Compiler warnings are treated as errors WARNINGS_ARE_ERRORS = -Werror 

खैर, यह XX_FLAGS माध्यम से लिनक्स पर भेजा जाएगा, XX_FLAGS गणना करते समय इस चर को ध्यान में नहीं रखा जाता है! जीएनयू / लिनक्स के निर्माण में, हमारे पास केवल उन विकल्पों का अनुसरण करने के अलावा कोई विकल्प नहीं है जो ऊपर से लॉन्च किए गए हैं।

ठीक है, या आप इसे आसान बना सकते हैं और WARNINGS_ARE_ERRORS के मूल्य को एक छोटे से बदल सकते हैं, लेकिन कोई कम शक्तिशाली -w । आप कैसे पसंद करते हैं, एलोन मस्क?

जैसा कि आप अनुमान लगा सकते हैं, यह पूरी तरह से इस निर्माण समस्या को हल करता है।

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

ऐसा लगता है कि सब कुछ इकट्ठा हुआ और कोई अतिरिक्त समस्या नहीं आई। हालांकि, निश्चित रूप से, मैंने परीक्षण शुरू करने की हिम्मत नहीं की। फिर भी, रात, मेरी आँखें एक साथ चिपकना शुरू हो जाती हैं, और किसी तरह मैं रेफ्रिजरेटर से ऊर्जा के चार डिब्बे - अंतिम उपाय तक नहीं जाना चाहता।

पपड़ी में गिरता है

विधानसभा पारित हो गई है, निष्पादनयोग्य उत्पन्न हुए हैं, हम महान हैं।

और इसलिए हम फिनिश लाइन पर आ गए। या नहीं आया?

हमारी विधानसभा निम्नलिखित तरीके से निहित है:

 export JAVA_HOME=~/git/jdk8u/build/linux-x86_64-normal-server-fastdebug/jdk export PATH=$JAVA_HOME/bin:$PATH 

जब आप java निष्पादन योग्य चलाने की कोशिश करते हैं, तो यह तुरंत क्रैश हो जाता है। जो परिचित नहीं हैं उनके लिए - यह कुछ इस तरह दिखता है:

उसी समय, एलेक्स के पास डेबियन 9.5 है, और मेरे पास उबंटू है। जीसीसी के दो अलग-अलग संस्करण, दो अलग दिखने वाले क्रस्ट। मैं strcmp मैनुअल पैच और कुछ और स्थानों के साथ निर्दोष मज़ाक है, एलेक्स नहीं करता है। क्या समस्या है?

यह कहानी एक अलग कहानी के योग्य है, लेकिन यहाँ सीधे शुष्क निष्कर्ष पर जाते हैं, अन्यथा मैं इस पोस्ट को कभी नहीं जोड़ूंगा।

समस्या यह है कि हमारे पसंदीदा C ++ pogromists ने फिर से अपरिभाषित व्यवहार का उपयोग किया है।

(इसके अलावा, जहां यह किसी अज्ञात तरीके से संकलक के कार्यान्वयन पर निर्भर करता है। हालांकि, हमें याद रखना चाहिए कि यूबी हमेशा यूबी है, यहां तक ​​कि संकलक के एक ज्ञात संस्करण पर भी इसे रखना असंभव है)

एक जगह पर हम एक अंडर-डिज़ाइन वर्ग के क्षेत्र में जाते हैं, और सब कुछ टूट जाता है। यह मत पूछो कि यह कैसे हुआ, सब कुछ जटिल है।

एक जाविस्टा के लिए यह कल्पना करना बहुत मुश्किल है कि निर्माणकर्ता से सीधे एक लिंक जारी करने के अलावा, एक निर्माणाधीन वर्ग में कैसे बदल सकता है। सौभाग्य से, अद्भुत C ++ भाषा सभी या लगभग सब कुछ कर सकती है। मैं एक निश्चित छद्म कोड के साथ एक उदाहरण लिखूंगा:

 class A { A() { _b.Show(); } private: static B _b; }; A a; BA::_b; int main() { } 

एक अच्छा डिबग है!

यदि आप C ++ 98 [class.cdtor] को देखते हैं:

गैर-पीओडी वर्ग प्रकार की वस्तु के लिए ... निर्माण कार्य शुरू होने से पहले ... ऑब्जेक्ट के किसी भी गैर-स्थिर सदस्य या आधार वर्ग का जिक्र करने से अपरिभाषित व्यवहार होता है।

कुछ संस्करण के जीसीसी (और मेरे पास 7.3) के साथ शुरू होकर, "लाइफटाइम डेड स्टोर एलिमिनेशन" का एक अनुकूलन दिखाई दिया, जो मानता है कि हम किसी वस्तु को केवल उसके जीवन काल के दौरान संदर्भित करते हैं, और जीवन काल के बाहर सब कुछ खांसी करता है।

समाधान नई आशाओं को निष्क्रिय करने और पुराने जीसीसी में वापस आने के रूप में है:

 CFLAGS += -fno-strict-aliasing -fno-lifetime-dse -fno-delete-null-pointer-checks 

इसे लेकर यहां चर्चा चल रही है ।
किसी कारण के लिए, चर्चा प्रतिभागियों ने फैसला किया कि यह अपस्ट्रीम में शामिल नहीं होगा। लेकिन आपको अभी भी इसे भेजने की कोशिश करनी होगी।

इन विकल्पों को हमारे ./hotspot/make/linux/makefiles/gcc.make जोड़ें, फिर से सब कुछ फिर से इकट्ठा करें और पोषित लाइनों को देखें:

 t$ ~/git/jdk8u/build/linux-x86_64-normal-server-fastdebug/jdk/bin/java -version openjdk version "1.8.0-internal-fastdebug" OpenJDK Runtime Environment (build 1.8.0-internal-fastdebug-me_2018_09_10_08_14-b00) OpenJDK 64-Bit Server VM (build 25.71-b00-fastdebug, mixed mode) 

निष्कर्ष

आपने शायद सोचा था कि निष्कर्ष होगा: "जावा कुछ प्रकार का नरक है, कोड में कचरा है, कोई समर्थन नहीं है, सब कुछ खराब है।"

ऐसा नहीं है! इसके विपरीत, ऊपर दिए गए उदाहरण बताते हैं कि ओपनजेडके के हमारे दोस्त, नेक्रोमैंकर्स किस भयानक बुराई से हमें बचाए हुए हैं।

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

केवल दुख की बात है, सबसे अधिक संभावना है, जो त्रुटियां मिली हैं, उन्हें jdk8u में स्वीकार किए जाने की संभावना नहीं है। हमने JDK 8 को केवल इसलिए लिया क्योंकि हमारे लिए इसे अभी और अभी पैच करना आसान है, और हमें JDK 11 से निपटना होगा। फिर भी, 2018 में JDK 8 का उपयोग करने के लिए IMHO है, यह एक बहुत बुरा अभ्यास है, और हम इसे अच्छे जीवन से नहीं करते हैं। शायद भविष्य में हमारे जीवन में सुधार होगा, और आप जेडीके 11 और जेडीके 12 की दुनिया से कई और अविश्वसनीय कहानियाँ पढ़ेंगे।

चित्रों के बिना इस तरह के एक उबाऊ पाठ पर ध्यान देने के लिए धन्यवाद :-)

विज्ञापन का मिनट। जोकर 2018 सम्मेलन बहुत जल्द आयोजित किया जाएगा, जहां जावा और जेवीएम में कई प्रमुख विशेषज्ञ होंगे। आधिकारिक वेबसाइट पर वक्ताओं और रिपोर्टों की पूरी सूची देखें। मैं वहां भी रहूंगा, जीवन और ओपनजेडके के लिए मिलना और पीसना संभव होगा।