कुछ लोग दावा क्यों करते हैं कि जावा का जेनेरिक कार्यान्वयन खराब है?

115

मैंने कभी-कभी सुना है कि जेनेरिक के साथ, जावा इसे सही नहीं मिला। (निकटतम संदर्भ, यहां )

मेरी अनुभवहीनता को क्षमा करें, लेकिन क्या उन्हें बेहतर बना सकता है?

java generics

— sdellysse
स्रोत

23

मुझे इसे बंद करने का कोई कारण नहीं दिखता; जेनेरिक के बारे में सभी बकवास के साथ, जावा और सी # के बीच अंतर के बारे में कुछ स्पष्टीकरण होने से लोगों को गलत सूचना देने वाले लोगों को चकमा देने में मदद मिल सकती है।

— रोब

146

खराब:

प्रकार की जानकारी संकलन समय पर खो जाती है, इसलिए निष्पादन समय पर आप यह नहीं बता सकते हैं कि यह किस प्रकार का "मतलब" है
मूल्य प्रकारों के लिए उपयोग नहीं किया जा सकता (यह एक Biggie है - .NET में List<byte>वास्तव में byte[]उदाहरण के लिए समर्थित है , और कोई बॉक्सिंग की आवश्यकता नहीं है)
जेनेरिक विधियों को कॉल करने के लिए सिंटैक्स बेकार है (IMO)
बाधाओं के लिए सिंटैक्स भ्रमित कर सकता है
वाइल्डकार्डिंग आम तौर पर भ्रमित करने वाला होता है
उपरोक्त - कास्टिंग आदि के कारण विभिन्न प्रतिबंध

अच्छा:

वाइल्डकार्डिंग कॉलिंगर्स / कंट्रोवर्सी को कॉलिंग साइड पर निर्दिष्ट करने की अनुमति देता है, जो कई स्थितियों में बहुत साफ है
कुछ भी नही से अच्छा है!

— जॉन स्कीट
स्रोत

51

@Paul: मुझे लगता है कि मैं वास्तव में एक अस्थायी टूटना पसंद करूंगा, लेकिन बाद में एक सभ्य एपीआई। या .NET रूट ले लो और नए संग्रह प्रकारों को पेश करें। (2.0 में .NET जेनरिक ने 1.1 ऐप नहीं तोड़े।)

— जॉन स्कीट

6

एक बड़े मौजूदा कोड बेस के साथ, मुझे यह तथ्य पसंद है कि मैं जेनेरिक का उपयोग करने के लिए एक विधि के हस्ताक्षर को बदलना शुरू कर सकता हूं, जो हर किसी को कॉल किए बिना बदल सकता है।

— पॉल टॉम्बलिन

38

लेकिन उस के डाउनसाइड विशाल और स्थायी हैं। एक बड़ी अल्पकालिक जीत है, और एक दीर्घकालिक हानि IMO है।

— जॉन स्कीट

11

जॉन - "यह कुछ भी नहीं की तुलना में बेहतर है" व्यक्तिपरक है :)

— MetroidFan2002

6

@Rogerio: आपने दावा किया कि मेरा पहला "खराब" आइटम सही नहीं है। मेरा पहला "खराब" आइटम कहता है कि सूचना संकलन समय पर खो जाती है। इसके लिए गलत होने के लिए, आपको यह कहना होगा कि सूचना संकलन समय पर नहीं खोई गई है ... जैसा कि अन्य डेवलपर्स को भ्रमित करने के लिए, आप केवल एक उलझन में हैं कि मैं क्या कह रहा हूं।

— जॉन स्कीट

26

सबसे बड़ी समस्या यह है कि जावा जेनरिक केवल एक संकलन-समय है, और आप इसे रन-टाइम पर हटा सकते हैं। C # की प्रशंसा की जाती है क्योंकि यह अधिक रन-टाइम जाँच करता है। इस पोस्ट में वास्तव में कुछ अच्छी चर्चा है , और यह अन्य चर्चाओं से जुड़ा हुआ है।

— पॉल टॉम्बलिन
स्रोत

यह वास्तव में कोई समस्या नहीं है, यह रनटाइम के लिए कभी नहीं बनाया गया था। यह ऐसा है जैसे आप कहते हैं कि नावें एक समस्या है क्योंकि वे पहाड़ों पर नहीं चढ़ सकते। एक भाषा के रूप में, जावा वह करता है जिसकी कई लोगों को आवश्यकता होती है: एक सार्थक तरीके से अभिव्यक्त प्रकार। रनटाइम प्रकार के इनफ़ॉर्ममेंट के लिए, लोग अभी भी Classऑब्जेक्ट्स को पास कर सकते हैं ।

— विंसेंट कैंटिन

1

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

— विएग्लीज

1

@VincentCantin - यह निश्चित रूप से एक समस्या है। इसलिए, हम सभी इसके बारे में शिकायत कर रहे हैं। जावा जेनरिक आधा पके हुए हैं।

— जोश एम।

17

मुख्य समस्या यह है कि जावा वास्तव में रनटाइम पर जेनरिक नहीं है। यह एक संकलन समय की सुविधा है।

जब आप जावा में एक सामान्य वर्ग बनाते हैं, तो वे "टाइप एरासुरे" नामक एक विधि का उपयोग करते हैं, जो वास्तव में सभी सामान्य प्रकारों को कक्षा से हटा देते हैं और अनिवार्य रूप से उन्हें ऑब्जेक्ट के साथ बदल देते हैं। जेनरिक का एक मील ऊंचा संस्करण यह है कि कंपाइलर केवल निर्दिष्ट जेनेरिक प्रकार में कास्ट सम्मिलित करता है जब भी यह विधि बॉडी में प्रकट होता है।

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

यहाँ मतभेदों के महान अवलोकन: http://www.jprl.com/Blog/archive/development/2007/Aug-31.html

— JaredPar
स्रोत

2

मुझे यकीन नहीं है कि आप नीचे मतदान क्यों कर रहे थे। जो मैं समझता हूं कि आप सही हैं, और यह लिंक बहुत जानकारीपूर्ण है। ऊपर मतदान किया।

— जेसन जैक्सन

@ जेसन, धन्यवाद। मेरे मूल संस्करण में एक टाइपो था, मुझे लगता है कि मुझे इसके लिए नीचा दिखाया गया था।

— JaredPar

3

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

— oxbow_lakes

बहुत सारे लेख हैं जो कहते हैं कि प्रकार का क्षरण वास्तविक प्रकार के मापदंडों को खोजना असंभव बनाता है। कहते हैं: ऑब्जेक्ट x = नया X [Y] (); क्या आप दिखा सकते हैं कि कैसे, x, Y टाइप करें?

— user48956

@oxbow_lakes - एक सामान्य प्रकार खोजने के लिए प्रतिबिंब का उपयोग करना लगभग उतना ही बुरा है जितना कि ऐसा करने में सक्षम नहीं होना। उदा यह एक बुरा समाधान है।

— जोश एम।

14

रनटाइम क्रियान्वयन (अर्थात प्रकार के क्षरण नहीं);
आदिम प्रकारों का उपयोग करने की क्षमता (यह (1) से संबंधित है);
जबकि वाइल्डकार्डिंग सिंटैक्स उपयोगी है और यह जानने के लिए कि इसका उपयोग कब करना है जो बहुत से लोगों को स्टंप करता है। तथा
कोई प्रदर्शन में सुधार ((1) के कारण; जावा जेनरिक कास्टिंग की वस्तुओं के लिए सिंथेटिक चीनी है)।

(१) कुछ बहुत ही अजीब व्यवहार होता है। सबसे अच्छा उदाहरण मैं सोच सकता हूं। मान लीजिये:

public class MyClass<T> {
  T getStuff() { ... }
  List<String> getOtherStuff() { ... }
}

फिर दो चर घोषित करें:

MyClass<T> m1 = ...
MyClass m2 = ...

अब कॉल करें getOtherStuff():

List<String> list1 = m1.getOtherStuff(); 
List<String> list2 = m2.getOtherStuff();

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

मैं JDK से अपनी पसंदीदा घोषणा का भी उल्लेख करूंगा:

public class Enum<T extends Enum<T>>

वाइल्डकार्डिंग (जो एक मिश्रित बैग है) के अलावा मुझे लगता है कि। नेट जेनरिक बेहतर हैं।

— cletus
स्रोत

लेकिन संकलक आपको बताएगा, विशेष रूप से कच्चे माल के लिंट विकल्प के साथ।

— टॉम ह्विटिन -

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

— ओशनोरो 0

public class Redundancy<R extends Redundancy<R>>;)

— java.is.for.desktop

@ oconnor0 यह एक संकलन विफलता नहीं है, लेकिन एक संकलक चेतावनी है, बिना किसी स्पष्ट कारण के:The expression of type List needs unchecked conversion to conform to List<String>

— Artbristol

Enum<T extends Enum<T>>पहली बार में अजीब / निरर्थक लग सकता है, लेकिन वास्तव में बहुत दिलचस्प है, कम से कम जावा के बाधाओं के भीतर / यह सामान्य है। Enums में एक स्थिर values()विधि है, जो अपने तत्वों की एक सरणी को enum के रूप में टाइप करती है, नहीं Enum, और यह प्रकार जेनेरिक पैरामीटर द्वारा निर्धारित किया जाता है, जिसका अर्थ है कि आप चाहते हैं Enum<T>। बेशक, वह टाइपिंग केवल एक एन्यूमरेटेड टाइप के संदर्भ में समझ में आता है, और सभी एनीमे उप-वर्ग होते हैं Enum, इस प्रकार वे चाहते हैं Enum<T extends Enum>। हालाँकि, जावा को जेनेरिक के साथ कच्चे प्रकार का मिश्रण पसंद नहीं है, इस प्रकार Enum<T extends Enum<T>>स्थिरता के लिए।

— JAB

10

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

Map someMap;

अब, मुझे इसे घोषित करना होगा

Map<String, List<String>> someMap;

और हर बार जब मैं इसे किसी विधि में पास करता हूं, मुझे उस बड़ी लंबी घोषणा को फिर से दोहराना होगा। मेरी राय में, यह सब अतिरिक्त टाइपिंग डेवलपर को विचलित करता है और उसे "ज़ोन" से बाहर ले जाता है। इसके अलावा, जब कोड बहुत सारे cruft से भर जाता है, तो कभी-कभी बाद में वापस आना मुश्किल होता है और महत्वपूर्ण तर्क खोजने के लिए जल्दी से सभी cruft के माध्यम से झारना।

जावा में पहले से ही सामान्य उपयोग में सबसे अधिक मौखिक भाषाओं में से एक होने के लिए एक खराब प्रतिष्ठा है, और जेनेरिक बस उस समस्या को जोड़ते हैं।

और क्या आप वास्तव में उस सभी अतिरिक्त वाचालता के लिए खरीदते हैं? कितनी बार आपको वास्तव में समस्याएँ हुईं जहाँ किसी ने एक इंटेगर को एक ऐसे संग्रह में डाल दिया, जिसे स्ट्रिंग्स को धारण करना चाहिए, या जहाँ किसी ने स्ट्रिंगर्स को इंटेगर के संग्रह से बाहर निकालने की कोशिश की? वाणिज्यिक जावा अनुप्रयोगों के निर्माण में काम करने के मेरे 10 वर्षों के अनुभव में, यह कभी भी त्रुटियों का एक बड़ा स्रोत नहीं रहा है। इसलिए, मुझे वास्तव में यकीन नहीं है कि आपको अतिरिक्त क्रियाशीलता के लिए क्या मिल रहा है। यह वास्तव में मुझे केवल अतिरिक्त नौकरशाही सामान के रूप में प्रभावित करता है।

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

List someList = someMap.get("some key");

मुझे करना है

List someList = (List) someMap.get("some key");

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

मुझे लगता है कि जावा 1 से बेहतर होता अगर 1) इसमें जेनरिक नहीं जोड़ा गया होता, लेकिन 2) इसके बजाय एक सुपरटेप से एक उपप्रकार तक अंतर्निहित कास्टिंग की अनुमति दी थी। गलत जाति को रनटाइम पर पकड़ा जाए। तब मुझे परिभाषित करने की सरलता हो सकती थी

Map someMap;

और बाद में कर रहे हैं

List someList = someMap.get("some key");

सभी cruft चला जाएगा, और मुझे नहीं लगता कि मैं अपने कोड में बग का एक बड़ा नया स्रोत पेश करूंगा।

— क्लिंट मिलर
स्रोत

15

क्षमा करें, मैं आपकी हर बात से असहमत हूं। लेकिन मैं इसे वोट करने नहीं जा रहा हूं क्योंकि आप इसे अच्छी तरह से तर्क देते हैं।

— पॉल टॉम्बलिन

2

बेशक, पायथन और रूबी जैसी भाषाओं में निर्मित बड़े, सफल सिस्टम के बहुत सारे उदाहरण हैं जो मैंने अपने उत्तर में सुझाए थे।

— क्लिंट मिलर

मुझे लगता है कि इस प्रकार के विचार पर मेरी पूरी आपत्ति यह नहीं है कि यह एक बुरा विचार है, बल्कि यह भी है कि जैसे कि पायथन और रूबी जैसी आधुनिक भाषाएं डेवलपर्स के लिए जीवन को आसान और आसान बनाती हैं, बदले में डेवलपर्स बौद्धिक रूप से आत्मसंतुष्ट हो जाते हैं और अंततः कम होते हैं अपने स्वयं के कोड की समझ।

— दान ताओ

4

"और आप वास्तव में उस अतिरिक्त वाचालता के लिए क्या खरीदते हैं? ..." यह गरीब रखरखाव प्रोग्रामर को बताता है कि उन संग्रहों में क्या होना चाहिए। मैंने इसे व्यावसायिक जावा अनुप्रयोगों के साथ काम करने वाला एक मुद्दा पाया है।

— रिचज

4

"कितनी बार आपको वास्तव में समस्याएँ हुईं जहाँ किसी ने [x] एक संग्रह में रखा है जिसे [y] s धारण करना है?" - अरे लड़का मैंने गिनती खो दी है! यहां तक कि अगर कोई बग नहीं है तो यह एक पठनीयता हत्यारा है। और ऑब्जेक्ट को (या डिबगिंग) क्या होने जा रहा है यह पता लगाने के लिए कई फ़ाइलों को स्कैन करना वास्तव में मुझे ज़ोन से बाहर खींचता है। आप हास्केल को पसंद कर सकते हैं - यहां तक कि मजबूत टाइपिंग लेकिन कम cruft (क्योंकि प्रकार अनुमानित हैं)।

— मार्टिन कैपोडिसी

8

उन्हें संकलित करने और समय नहीं चलाने का एक और दुष्प्रभाव यह है कि आप सामान्य प्रकार के निर्माता को नहीं बुला सकते। तो आप उन्हें एक सामान्य कारखाने को लागू करने के लिए उपयोग नहीं कर सकते हैं ...


   public class MyClass {
     public T getStuff() {
       return new T();
     }
    }

--jeffk ++

— jdkoftinoff
स्रोत

6

जावा जेनरिक को संकलन समय पर शुद्धता के लिए जांचा जाता है और फिर सभी प्रकार की जानकारी को हटा दिया जाता है (प्रक्रिया को इरेज़र कहा जाता है । इस प्रकार, जेनेरिक List<Integer>अपने कच्चे प्रकार , गैर-जेनेरिक में कम हो जाएगाList , जिसमें मनमाना वर्ग की वस्तुएँ हो सकती हैं।

यह रनटाइम में सूची में मनमानी वस्तुओं को सम्मिलित करने में सक्षम होता है, साथ ही अब यह बताना असंभव है कि सामान्य पैरामीटर के रूप में किस प्रकार का उपयोग किया गया था। उत्तरार्द्ध बदले में परिणाम देता है

ArrayList<Integer> li = new ArrayList<Integer>();
ArrayList<Float> lf = new ArrayList<Float>();
if(li.getClass() == lf.getClass()) // evaluates to true
  System.out.println("Equal");

— एंटोन गोगोलेव
स्रोत

5

काश यह एक विकी होता तो मैं अन्य लोगों को जोड़ सकता था ... लेकिन ...

समस्या:

इरेज़र टाइप करें (कोई रनटाइम उपलब्धता नहीं)
आदिम प्रकारों के लिए कोई समर्थन नहीं
एनोटेशन के साथ असंगति (वे दोनों 1.5 में जोड़े गए थे मुझे अभी भी यकीन नहीं है कि एनोटेशन जेनेरिक को सुविधाओं से भागने की अनुमति नहीं देता है)
Arrays के साथ असंगति। (कभी-कभी मैं वास्तव में कक्षा की तरह कुछ करना चाहता हूं <? MyObject का विस्तार करता है> [], लेकिन मुझे इसकी अनुमति नहीं है)
अजीब वाइल्डकार्ड वाक्यविन्यास और व्यवहार
तथ्य यह है कि जेनेरिक समर्थन जावा कक्षाओं में असंगत है। उन्होंने इसे अधिकांश संग्रह विधियों में जोड़ा, लेकिन हर बार एक समय में, आप एक ऐसे उदाहरण में भाग लेते हैं, जहां इसकी आवश्यकता नहीं होती है।

— लाप्ली एंडरसन
स्रोत

5

पूरे प्रकार को नष्ट करने की गड़बड़ी को अनदेखा करना, जैसा कि निर्दिष्ट है, जेनेरिक बस काम नहीं करते हैं।

यह संकलन:

List<Integer> x = Collections.emptyList();

लेकिन यह एक सिंटैक्स त्रुटि है:

foo(Collections.emptyList());

जहां फू को परिभाषित किया गया है:

void foo(List<Integer> x) { /* method body not important */ }

तो क्या एक अभिव्यक्ति प्रकार की जाँच इस बात पर निर्भर करती है कि क्या यह एक स्थानीय चर को सौंपा जा रहा है या विधि कॉल के वास्तविक पैरामीटर को। कितना पागल है?

— नेट
स्रोत

3

जावेद द्वारा असंगत अनुमान बकवास है।

— एम.पी.

3

मैं यह मानूंगा कि बाद के फॉर्म को अस्वीकार कर दिया गया है क्योंकि विधि ओवरलोडिंग के कारण "फू" का एक से अधिक संस्करण हो सकता है।

— जेसन Creighton

2

यह समालोचना अब लागू नहीं होती है क्योंकि जावा 8 में सुधार लक्ष्य-प्रकार की शुरूआत पेश की गई है

— Oldrinb

4

जावा में जेनरिक का परिचय एक कठिन कार्य था क्योंकि आर्किटेक्ट विरासत कोड के साथ कार्यक्षमता, उपयोग में आसानी, और पिछड़े संगतता को संतुलित करने की कोशिश कर रहे थे। काफी उम्मीद है, समझौता करना पड़ा।

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

— ज़च स्क्रिवेना
स्रोत

3

जावा केवल समय पर जेनरिक लागू नहीं करता है, केवल संकलन समय पर।

इसका मतलब है कि आप दिलचस्प प्रकार कर सकते हैं जैसे गलत प्रकार को जेनेरिक कलेक्शंस में जोड़ना।

— Powerlord
स्रोत

1

संकलक आपको बताएगा कि आपने इसे प्रबंधित किया है या नहीं।

— टॉम हॉकिन -

@ टोम - जरूरी नहीं। कंपाइलर को बेवकूफ बनाने के तरीके हैं।

— पॉल टॉम्बलिन

2

क्या आप नहीं सुनते हैं कि कंपाइलर आपको क्या बताता है ?? (मेरी पहली टिप्पणी देखें)

— टॉम हैटिन -

1

@Tom, यदि आपके पास एक ArrayList <string> है और आप इसे एक पुराने-शैली विधि (जैसे, विरासत या तृतीय पक्ष कोड) को पास करते हैं, जो एक सरल सूची लेता है, तो वह विधि उस सूची में कुछ भी जोड़ सकती है जिसे वह पसंद करता है। यदि यह रनटाइम पर लागू होता है, तो आपको एक अपवाद मिलेगा।

— पॉल टॉम्बलिन

1

स्थिर शून्य addToList (सूची सूची) {list.add (1); } सूची <स्ट्रिंग> सूची = नया एरियर सूची <स्ट्रिंग> (); addToList (सूची); यह संकलन करता है, और यहां तक कि रनटाइम पर भी काम करता है। जब आप किसी समस्या को देखते हैं तो केवल तभी होता है जब आप सूची से एक स्ट्रिंग की उम्मीद से हटा देते हैं और एक इंट प्राप्त कर लेते हैं।

— लाप्ली एंडरसन

3

जावा जेनरिक केवल संकलन-समय हैं और गैर-जेनेरिक कोड में संकलित हैं। C # में, वास्तविक संकलित MSIL सामान्य है। प्रदर्शन के लिए इसके बहुत बड़े निहितार्थ हैं क्योंकि जावा अभी भी रनटाइम के दौरान आता है। अधिक के लिए यहाँ देखें ।

— सिजमन रोजगा
स्रोत

2

यदि आप जावा पॉस # 279 - जो डार्सी और एलेक्स बकले के साथ साक्षात्कार सुनते हैं , तो वे इस मुद्दे पर बात करते हैं। यह भी कहते हैं कि जावा के लिए संशोधित जेनरिक शीर्षक से एक नील Gafter ब्लॉग पोस्ट के लिए लिंक :

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

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

लक्ष्य स्रोत और ऑब्जेक्ट कोड दोनों की पश्चगामी संगतता प्रदान करना था, और माइग्रेशन संगतता भी।

— केविन हैकसन
स्रोत