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.
