जेएसपी तुलना ऑपरेटर व्यवहार

Question

मैं जेएसपी के <c:if> टैग में दो अलग-अलग प्रकारों की तुलना करना चाहता हूं। असल में बाएं एक Number है लेकिन सही एक स्ट्रिंग है और यदि वह स्ट्रिंग किसी संख्या में पार्स हो सकती है तो मुझे कोई त्रुटि नहीं मिलती है, लेकिन यदि स्ट्रिंग को Number पर पार्स नहीं किया जा सकता है तो मुझे javax.el.ELException: Cannot convert No of type class java.lang.String to class java.lang.Long प्राप्त होता है।

व्यावहारिक रूप से :

$ {1 == ""} // काम करता है ठीक
$ {1 == "4"} // काम करता है ठीक
$ {1 == "हाँ"} // अपवाद को ट्रिगर करता है।

लेकिन यहां तक ​​कि तीसरी तुलना जेएसपी के पिछले संस्करणों में भी ठीक काम करती है लेकिन अब यह अपवाद का कारण बनती है।

क्या == का व्यवहार समय के साथ बदल गया है?

कोई सुझाव अत्यधिक

Answer 1

== का व्यवहार लेकिन नहीं बदला है {expr} का व्यवहार बदल जाता है ...

संस्करणों के बारे में:

JSP Specification,

की पश्चगामी संगतता अनुभाग में हैं संस्करण विशिष्ट एड कम है 2.1 से अधिक, तो {expr} वाक्यविन्यास है जिसे केवल स्ट्रिंग अक्षर के रूप में संसाधित किया जाता है।

तो, ईएल 2.0 तक सभी एक स्ट्रिंग शाब्दिक रूप में इलाज किया जाएगा और साथ .equals== रूप equals आंतरिक रूप से (Reference here) में परिवर्तित हो जाएगा की तुलना में है, लेकिन 2.1 में यह स्ट्रिंग के लिए परिवर्तित नहीं किया जाएगा और यह कहते हुए अपवाद होगा कि javax.el.ELException: Cannot convert No of type class java.lang.String to class java.lang.Long

तुलना के बारे में:

ईएल संस्करण 2.1 की JSP specification JSP.2.3.5.7, निम्नलिखित निर्दिष्ट किया जाता है में ...

01,235,

1. यदि ए शून्य है या बी शून्य है == या eq के लिए झूठी वापसी है, तो सच है!= या ne

2. ए या बी बाइट, लघु, चरित्र, पूर्णांक, या लांग विवश दोनों एक और बी लांग रहा है, ऑपरेटर

हां, तो में पहला मामला

लागू

${1 =="" } // ans is false as second one is null as per 1st rule. 

और दूसरे मामले में,

${1 =="4" } // ans is false as both are different after coercing to Long as per 2nd rule. 

दोनों को आंतरिक प्रकार के रूपांतरण के साथ उपरोक्त मामले में लंबे समय तक ले जाया जाएगा।

लेकिन तीसरे मामले में, ${1 =="Yes" } जहां दूसरी स्ट्रिंग (मजबूर) लांग में परिवर्तित नहीं किया जा सकता है और java.el.ELException संदेश के साथ फेंक दिया जाएगा कि "प्रकार वर्ग java.lang.String का कोई वर्ग जावा के लिए कनवर्ट नहीं कर सकता। lang.Long "।

Answer 2

सराहना कर रहे हैं JSP 2.1 के रूप में, JSP एकीकृत अभिव्यक्ति भाषा (एकीकृत ईएल) है, जो अभिव्यक्ति भाषा JSP 2.0 द्वारा की पेशकश का एक संघ और के लिए बनाई गई अभिव्यक्ति भाषा का प्रतिनिधित्व करता है का उपयोग करता है जावासेवर फेस टेक्नोलॉजी।

यह बहुत संभावना है कि व्यवहार थोड़ा अलग हो सकता है।

पूर्ण प्रकार रूपांतरण नियमों के लिए जावासेवर पेज 2.1 अभिव्यक्ति भाषा विशिष्टता (here से उपलब्ध) के अनुभाग 1.18 देखें।