I can only speak for myself, but after years of exposure to different specs and reference documents, I was very surprised to see Sun talk about the primitives that way in the language spec. Seems like a very poor choice of words to describe implied conversions. I suppose they were already feeling self-conscious about exposed primitives and wanted to make them "feel" a little less removed from the object paradigm than they actually are.
Alexey ________________________________ From: Kevin Wright <[email protected]> To: [email protected] Sent: Mon, December 6, 2010 4:44:11 PM Subject: Re: [The Java Posse] Re: James Gosling on Apple, Apache, Google, Oracle and the Future of Java Java Language Spec, 3rd Edition, page 63: 4.10.1 Subtyping among Primitive Types The following rules define the direct supertype relation among the primitive types: double > float float > long long > int int > char int > short short > byte immediately followed by "4.10.2 Subtyping among Class and Interface Types" "4.10.3 Subtyping among Array Types" I think it's totally, unarguably clear that subtyping ("extends") is used here in the very precise sense that it has attained with object-oriented programming. So yes, LSP really *does* apply here. It's just another of Java's beloved "simple" qualities... On 6 December 2010 21:27, Miroslav Pokorny <[email protected]> wrote: I believe extends in the prev post was about widening from int to long etc it was not about equal substitution aka Liskov s/p. > >On 07/12/2010, at 4:41 AM, Kevin Wright <[email protected]> wrote: > > >Whatever way you put it, any subtyping relationship between primitives is >going >to violate the Liskov Substitution Principle. And so should be considered evil. >>Implicit conversions, however, are perfectly acceptable :) >>On 6 Dec 2010 16:47, "Alexey Zinger" <[email protected]> wrote: >>> A few corrections are in order. I think you got the primitive type >>> hierarchy > >>> backwards: "double extends float" should read "float extends double", both >>> according to the link and if you think about which way loss of precision >>> occurs. To be fair, I think it's wrong to talk about type hierarchy with >>> primitives. By definition, they fall outside the traditional object model >>> and >> >>> behave as an approximation of characteristics of chips and memory and so >>> on. >>> With primitives, we talk about precision, type size and other low-level >>> concepts. Casting of primitive types, a la (long)5 is an entirely >>> different >>> operation that casting of reference types. It's actually type conversion. >>> True, sometimes it happens implicitly, which can generally happen along the >>> "hierarchy" outlined, but really, it's not at all the same as implicitly >>>casting >>> >>> String to Object. >>> >>> So it may be confusing to have some type hierarchy in wrapper classes that >>> extend Number that's totally different that implicit casts and direction of >>> precision loss in primitives, but it isn't wrong. The source of confusion >>> here >>> >>> is that we're straddling object- and non-object worlds. Their memory >>>allocation >>> >>> is different. They're passed around the stack differently. Garbage >>> collection >>> >>> is different. Type conversion is different. You could stipulate that Java >>> should have had primitive support on the bytecode level without exposing >>> them >>>in >>> >>> Java-the-language. And you could say it was important for certain library >>> authors to have that exposure, due to lack of other languages on the JVM at >>> the >>> >>> early stages. But whatever the case, in terms of legacy support, we have >>> what >> >>> we have in Java and the JVM, and we now have "purer" object models in some >>>other >>> >>> JVM languages and if we want to work in Java, we just need to be aware of >>> the > >>> quirks of the type system. We've always known that. >>> >>> Alexey >>> >>> >>> >>> >>> >>> ________________________________ >>> From: Reinier Zwitserloot <[email protected]> >>> To: The Java Posse <[email protected]> >>> Sent: Sun, December 5, 2010 8:51:14 AM >>> Subject: [The Java Posse] Re: James Gosling on Apple, Apache, Google, >>> Oracle >>>and >>> >>> the Future of Java >>> >>> If you want to blame somebody / some decision here, blame the notion >>> that primitives have different typing relationships than their boxed >>> equivalents. That's the primary issue stopping any attempt to make >>> primitives less 'special'. >>> >>> According to the JLS: >>> http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.10.1 >>> >>> double extends float extends long extends int extends short extends >>> byte. And while we're at it, int also extends char, and boolean is in >>> its own little world. >>> >>> Double, Float, Integer, Short, Byte, Character, and Long, on the other >>> hand, all extend Number, and have no sub/supertype relations amongst >>> themselves at all. >>> >>> This is a great source of puzzlers and the main argument Neal Gafter >>> uses to counter any talk of for example getting rid of primitives >>> altogether, or even allowing primitives in generics. In case you don't >>> see the relevance: Sub/supertype relations are important when >>> resolving methods. If you see: >>> >>> foo(5) >>> >>> and there's a foo method: >>> >>> void foo(double in) {} >>> >>> then the reason it'll get called is because 5 (being of the 'int' >>> type) is an instance of double (after all, 'int' is a subtype of >>> double. This is no different from an instance of ArrayList being >>> appropriate to pass as parameter to a method that takes List). But in >>> wrapper world, this doesn't work: >>> >>> foo(new Integer(5)); >>> >>> and with foo method: >>> >>> void foo(Double in) {} >>> >>> now the compiler won't compile it, complaining that 'Integer' cannot >>> be applied to 'Double', because while int is a subtype of double, >>> Integer is NOT a subtype of Double. If you start mixing primitives and >>> their wrappers, autoboxing comes into play and then nobody knows what >>> happens anymore. >>> >>> Note that method resolution is 100% a java-the-language thing. The JVM >>> has no resolution at all; each method call is explicitly defined with >>> complete information: full location (package + class), method name, >>> and full type of all parameters and the return type. i.e. >>> Integer.parseInt is in JVM speak: "java/lang/Integer parseInt (Ljava/ >>> lang/String;)I". There is no super/subtyping at all; if the method >>> signature doesn't match exactly, you get a MethodNotFoundError. >>> There's also no autoboxing, that was also a purely java-the-language >>> invention. Which does go to show that you can make primitives more >>> usable with a purely language-based change. >>> >>> If these subtyping relations had never been written (i.e. double was >>> never defined as being a superclass of float, for example), then >>> changing java-the-language to effectively get rid of primitives >>> altogether, with javac smart enough to optimize code and generate >>> primitives at the JVM level, would have been a heck of a lot simpler. >>> Alternatively blame the guys who designed java.lang.Integer and >>> friends. While strange, they could have mirrored these relationships >>> and declared java.lang.Integer to extend java.lang.Double, and so on. >>> Of course, fixing _that_ would be backwards incompatible. D'oh! >>> >>> *) Actually, my personal opinion on this runs counter to the concepts >>> above: It's already a cesspool no java developer but geeks like me who >>> read the JLS front-to-back understand. That'll never get better, so >>> might as well roll with it and come up with an even more convoluted >>> fix. Getting rid of primitives is worth making an already complicated >>> mess even more complicated. But this is one of those areas where I >>> haven't yet managed to convince the JLS brass (Reinhold, Goetz, >>> Buckley, and friends) yet that Neal's arguments get trumped by >>> practicality. Who knows, though - BGGA went down in flames in favour >>> of SAM-based closures... which incidentally vastly increase the >>> importance of at least allowing primitives in generics (so that you >>> can write a Comparator<int>, for example, which you could then use to >>> sort an int[], which is not currently possible in java without writing >>> your own method to do it!). Who knows what'll happen as Project Lambda >>> develops? >>> >>> >>> On Dec 4, 8:01 pm, Cédric Beust ♔ <[email protected]> wrote: >>>> On Sat, Dec 4, 2010 at 7:28 AM, Neil Bartlett <[email protected]> wrote: >>>> > I'm *not* surprised that he didn't mention the Date and Calendar APIs. >>>> > He should have, but I'm not surprised he didn't. I'm also not >>>> > surprised that he failed to mention primitives and arrays. >>>> >>>> Careful with revisionism here. >>>> >>>> I think the decision to have primitives is one of the subtle details that >>>> made Java the success it is today. Back then, performance was a huge deal >>>> and it took years before Java's speed started being perceived as "good >>>> enough". With that in mind, using objects for everything would have been a >>>> terrible mistake, one that might have turned Java into an interesting >>>> language that was soon sent back to the dark corners of programming language >>>> history. >>>> >>>> It's always dangerous to reexamine past decisions with present insight. >>>> >>>> A more interesting hypothetical question to me is what language would have >>>> emerged if Java hadn't succeeded... >>>> >>>> -- >>>> Cédric >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The >> >>> Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The >>>Java Posse" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>>[email protected]. >>> For more options, visit this group at >>>http://groups.google.com/group/javaposse?hl=en. >>> >> -- >>You received this message because you are subscribed to the Google Groups >>"The >>Java Posse" group. >>To post to this group, send email to [email protected]. >>To unsubscribe from this group, send email to >>[email protected]. >>For more options, visit this group at >>http://groups.google.com/group/javaposse?hl=en. >> > -- >You received this message because you are subscribed to the Google Groups "The >Java Posse" group. >To post to this group, send email to [email protected]. >To unsubscribe from this group, send email to >[email protected]. >For more options, visit this group at >http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
