क्या जावा 7 में यह एक-एक-एक बग है?

मुझे नहीं पता कि जावा एपीआई दस्तावेज और जावा कोड पर स्पष्टीकरण और पुष्टि कहां से प्राप्त करें, इसलिए मैं इसे यहां कर रहा हूं।

FileChannel , मुझे एक-एक-एक त्रुटि wrt मिल रहा है एक से अधिक स्थानों में स्थिति फ़ाइल करें और आकार फ़ाइल करें।

यहां सिर्फ एक उदाहरण है। transfer से (...) कहता है:

"यदि दी गई स्थिति से अधिक फ़ाइल के वर्तमान आकार है तो कोई बाइट स्थानांतरित नहीं किया जाता है।"

मैंने पुष्टि की कि ओपनजेडीके कोड में भी यह कोड है ...

public long transferFrom(ReadableByteChannel src, long position, long count)
    throws IOException
{
   //...
    if (position > size())
        return 0;
   //...
}

... फ़ाइल में FileChannelImpl.java दस्तावेज़ में संगत।

अब, उपर्युक्त कोड स्निपेट और एपीआई दस्तावेज पारस्परिक रूप से सुसंगत दिखाई देते हैं, मुझे लगता है कि उपर्युक्त 'से अधिक या बराबर होना चाहिए और न केवल ' से अधिक <<> मजबूत> क्योंकि position फ़ाइल के डेटा में 0-आधारित इंडेक्स होने के कारण, position == size() पर पढ़ने के लिए कॉलर पर वापस जाने के लिए कोई डेटा नहीं होगा! ( position == size() - 1 पर, कम से कम 1 बाइट - फ़ाइल का अंतिम बाइट - कॉलर पर वापस किया जा सकता है।)

यहां एक ही एपीआई दस्तावेज़ पृष्ठ में कुछ अन्य समान उदाहरण दिए गए हैं:

  1. स्थिति (...) : "स्थिति को उस मान पर सेट करना जो से अधिक फ़ाइल का वर्तमान आकार कानूनी है लेकिन फ़ाइल का आकार नहीं बदलता है " ('से अधिक या बराबर' होना चाहिए।)

  2. transferTo (...) : " अगर दी गई स्थिति फ़ाइल से वर्तमान आकार से अधिक है तो नहीं बाइट स्थानांतरित कर दिए जाते हैं। " ('से अधिक या बराबर' होना चाहिए।)

  3. पढ़ें (...) : " अगर दी गई स्थिति फ़ाइल से वर्तमान आकार से अधिक है तो कोई बाइट नहीं पढ़ा जाता है। " ('से अधिक या बराबर' होना चाहिए।)

अंत में, पढ़ें (...) शेष दस्तावेज़ों के साथ भी स्वयं-संगत रहने में विफल रहता है। यहां बताया गया है कि यह क्या कहता है:

पढ़ (...)

     

यह दिखाता है:

     

बाइट्स की संख्या, संभावित रूप से शून्य, या -1 पढ़ी जाती है यदि दी गई स्थिति फ़ाइल के वर्तमान आकार से अधिक के बराबर या बराबर है

तो, इस अकेले उदाहरण में, मैं उन्हें सही चीज़ का जिक्र करता हूं।

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

0
मैंने ~ 2 सप्ताह पहले वहां एक और बग दायर की। डेम से एक पुष्टिकरण और एक बग आईडी प्राप्त हुई कि मेरी बग स्वीकार कर ली गई है, हालांकि ... मैं आज भी बग डेटाबेस में इस बग आईडी और इसकी वर्तमान स्थिति को नहीं देख सकता। तो, सुनिश्चित नहीं है, ये लोग दायर की गई बग के साथ क्या कर रहे हैं।
जोड़ा लेखक Harry, स्रोत
मेरी सलाह कुछ प्रयोगों को चलाने और एक बग रिपोर्ट दर्ज करने के लिए होगी: bugreport.sun.com/bugreport
जोड़ा लेखक Radiodef, स्रोत
बग रिपोर्ट पढ़ने से मेरी धारणा यह है कि वे थोड़ी धीमी हैं (क्योंकि उन्हें उनमें से बहुत कुछ मिलता है) लेकिन यदि रिपोर्ट स्पष्ट है तो वे उन्हें प्राप्त करते हैं। यदि आपके द्वारा उठाए गए मुद्दे से कोई वास्तविक समस्या उत्पन्न हुई है तो यह एक बग की तरह प्रतीत होता है जो उन्हें ठीक करने पर विचार करेगा, यह कुछ ऑपरेटरों को बदल रहा है।
जोड़ा लेखक Radiodef, स्रोत

2 उत्तर

यह एक-एक-एक बग नहीं है जिसमें कोई व्यवहार समस्या सही नहीं है? सबसे अच्छा एक डॉक्टर समस्या पर। दस्तावेज़ यहां गलत नहीं हैं शायद पूरा नहीं हो सकता है।

However I am not sure they are missing something. position == size() is not an exceptional situation. It is a situation where 0 bytes can be read kind of by definition. position > size() is exceptional: less than 0 bytes can be read. It needs a note. Does an exception throw? Or nothing. read() is different since it has to return a byte so having 0 to read is the exceptional condition too.

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

(या आप का मतलब है कि यह कुछ दस्तावेज नहीं है?)

0
जोड़ा
शॉन, आपके उत्तर से संतुष्ट नहीं है। मैं जावा 7 के फाइलसिस्टमप्रोवाइडर एसपीआई का उपयोग कर एक पूर्ण रूप से कस्टम फाइल सिस्टम लिखने की कोशिश कर रहा हूं, इसलिए मुझे पता होना चाहिए कि जावा के वर्तमान और भावी रिलीज को मेरे कोड से खुश रखने के लिए मुझे कौन सा अर्थशास्त्र प्रदान करना है। [Contd ...]
जोड़ा लेखक Harry, स्रोत
मैं इसे दस्तावेज और कोड दोनों के साथ एक समस्या के रूप में देख रहा हूँ। यदि कोड में> = था, तो यह केवल एक प्रलेखन बग होता और मैं <अंतर्निहित स्थिति और आकार हैंडलिंग के बारे में अपने अंतर्निहित वृत्ति पर भरोसा कर सकता था। लेकिन यह भी दिया गया है कि दस्तावेज भी सभी जगहों पर पूरी तरह से आत्मनिर्भर नहीं है, अब मैं वास्तव में उलझन में हूं कि लिखने के लिए तर्क क्या है जो आज और कल भविष्य में रिलीज/जावा के पैच के साथ काम करेगा। मुझे इन रिलीज को सक्रिय रूप से ट्रैक करना होगा और मेरे ग्राहकों को यह लागू नहीं करना होगा या जावा के रिलीज पैच को लागू करना होगा, जो थोड़े से बेकार है।
जोड़ा लेखक Harry, स्रोत
@ हैरी मैं आपके लिए सॉफ़्टवेयर या दस्तावेज़ नहीं लिख रहा हूं, या दावा कर रहा हूं कि वे सही या सुसंगत हैं। बस जो आप पढ़ रहे हैं उसे पार्स करने में मदद करने की कोशिश कर रहे हैं। लेकिन, क्या व्यवहार संदिग्ध है? ऐसा लगता है कि व्यवहार को पूरी तरह से position == size() मामले में भी निर्दिष्ट किया गया है, केवल आपके द्वारा बोले गए वाक्यों से नहीं, और भले ही यह अच्छा होगा।
जोड़ा लेखक Sean Owen, स्रोत
यह मेरे लिए एक डॉक्टर की समस्या की तरह लगता है, उदाहरण के लिए स्थानांतरण से कहता है कि यदि स्थिति> आकार है तो कोई बाइट पढ़ा नहीं जाता है, लेकिन यदि स्थिति == आकार है तो कोई बाइट भी स्थानांतरित नहीं किया जाना चाहिए। इसलिए मैं सिर्फ ओपी को सुझाव दूंगा कि क्या यह टूटा जा सकता है और यदि ऐसा है तो एक बग रिपोर्ट दर्ज करें।
जोड़ा लेखक Radiodef, स्रोत

यह जावाडोक में थोड़ा स्पष्ट हो सकता है और अब यहां ट्रैक किया गया है:

https://bugs.openjdk.java.net/browse/JDK-8029370

ध्यान दें कि जावाडोक को स्पष्ट करने से फ़ाइलChannel के कार्यान्वयन के लिए कुछ भी नहीं बदला जाना चाहिए (उदाहरण के लिए, स्थानांतरण विधियां स्थानांतरित बाइट्स की संख्या लौटाती हैं, इसलिए स्थिति 0 या आकार के आकार के बाद होती है)।

0
जोड़ा