This is correct in terms of the strict math and logic of it, but in practice, this is slightly faulty reasoning.
1. While the source code is indeed the same whether you decide to pass an int or long value to a long variable, but in practice different bytecode is generated. That means LSV applies only on Java source code level and not on the JVM level. However, in many cases, bytecode is unaffected by whether a List variable accepts ArrayList or LinkedList. 2. Another LSV bi-product is that if appropriate and possible, it is considered a good practice to use superclasses and interfaces for left hand values and API signatures such as specifying DateFormat or Format instead of SimpleDateFormat. If I was confronted with a method accepting a SimpleDateFormat parameter, chances are good that I could refactor its signature to use DateFormat without any problems. Not only is that possible, everything will continue to work as before. However, if I did such a change on a method accepting int, to make it accept double instead, I could easily end up with a non-trivial performance sacrifice due to the implicit conversion. The Number class allows us to make ambiguous constraints with regard to numeric values, which can be appropriate and work well with the object model, but it also makes it quite obvious to the user of such interfaces that number conversions are likely and are not to be swept away from the programmer's view with syntax sugar. On the other hand, when the JVM and the compiler are able to work out operations like autoboxing and optimize them away completely and still allow the object way of thinking, then syntax sugar is available to pretend like these things aren't there at all. Alexey ________________________________ From: Reinier Zwitserloot <[email protected]> To: The Java Posse <[email protected]> Sent: Mon, December 6, 2010 7:39:19 PM Subject: [The Java Posse] Re: James Gosling on Apple, Apache, Google, Oracle and the Future of Java I indeed mixed up the order. Obviously doubles are at the top of the hierarchy; a double is not a suitable substitute for any other type, and byte is at the bottom; a byte will readily convert to everything else (Except char, and boolean). I double checked the rest, and other than reversing the order in the original list, no further brainfarts that I could see. However, I'm _not_ wrong / misguided when talking about a type hierarchy for these. They HAVE a hierarchy. Period. This is of extreme importance for method resolution, which is a massive setback for trying to do something interesting with unifying primitives and their object variants. Yes, 'casting' to primitives has absolutely no relation to casting to non-primitives; one converts numeric representations around, the other makes a type assertion. Nevertheless, none of that changes the notion that the primitive types are defined in a hierarchy that is different from java.lang.Number and subclasses. nearly trivial case in point: Allowing List<int> really isn't so difficult at first glance; treat it as Integer for all intents and purposes, except sprinkle in a few null checks where appropriate (i.e., auto-unbox and auto-box where needed), and update the VM so it can optimize back-to-back box/unbox operations across method calls, something the JRockit VM already does, so its evidently not rocket science (ho ho ho!). Except for that wrench in the works, type hierarchy. That, and arrays (though handwaving those away is easy: Well, by allowing primitives in generics, we do away most of the reasons of even having arrays, so, collateral damage in that area is acceptable). On Dec 6, 5:47 pm, 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.htm... > > 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 >athttp://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.
