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.
