Ulf Lindqvist

Yelena Druzhilova wrote:
If these definitions aren't correct could you, please, help with a sample or reference to the Upcasting explanation?

The term upcasting is a common generic term but it's not defined by Java. In the JLS it's called,

---

5.1.5. Widening Reference Conversion

A widening reference conversion exists from any reference type S to any reference type T, provided S is a subtype (§4.10) of T.

Widening reference conversions never require a special action at run time and therefore never throw an exception at run time. They consist simply in regarding a reference as having some other type in a manner that can be proved correct at compile time.

---

But let's call the above upcasting. This is an example of upcasting indeed,

Machine m = new Camera(); // upcast (after object creation)

and this is too,

Camera c; // Machine m = c; // upcast

and this,

Camera c; // Machine m = (Machine) c; // upcast (explicit)

In the last case the upcast has been made explicit. This is not necessary.

Machine is a supertype of Camera and that's what makes all above assignments upcasts. Upcasting takes place upward in an inheritance hierearchy.

The deeper reason why upcasting works is polymorphism, namely that an object may have many types (polymorphism == many forms). A subtype object has its own type but also at the same time all types of its supertypes. It IS all of them.

Ivan Jozsef Balazs wrote:

JVM loads that bytecode and executes it.

And performs just-in-tome compilation: compiles some byte code portions into native code in order to achieve better performance.

A JVM can do optimizations but to the best of my knowledge isn't required to do so.

It's a bonus if it does.

Winston Gutkowski wrote:
"The Java programming language is a general-purpose concurrent class-based object-oriented programming language"
doing in the Preface to the first Edition, written by Gosling himself (2nd paragraph).

Okay, in the preface to the first edition of the JLS you managed to find a reference to OO. But then it's gone because the JLS shouldn't care as you should know.

The JLS supports my advice. It does that by not giving any performance guarantees on the switch statement. So prefer a switch unless you know the selection probabilities, then prefer an if-else chain.

My advice is fully supported by the JLS. Your opposition is based on your personal view only. You have no support in the JLS whatsoever.

Jayesh A Lalwani wrote:
No, I know what I'm testing here, because the only differrence between the test methods is the if-else chain vs switch statement.

Well that's not enought.

What you're comparing should constitute the major part of the test methods. Otherwise any difference will be lost in the bulk of the test methods. What you want to measure must stick out, right.

That's one problem with your test, among many.

Chetan Dorle wrote:
There is no keyword or language level construct to indicate immutability (though I wish there was).

Well you can always use C++ which has the const keyword.

Still the keyword approach has its limits and that's because immutability comes in two flavours, formal and by design, and that's really an issue. To resolve it C++ has had to introduce a counter measure to const called mutable.

So with the C++ example in mind and further discouraged by the general threat that "if you suggest a language change you must donate a kidney" I think Java should stay as it is.

Chan Ag wrote:
I've been trying to write a singleton class

The general consensus is that the "Enum Singleton" is the best implementation in Java.

Why not check it out and see if it meets your expectations. It's so simple it must be good.

Jayesh A Lalwani wrote:
Actually, no you are wrong. I ran this unit test.

Sure you did but what are you measuring really? It seems the test code is spending most of the time doing other things than comparing the alternatives. And do you really print during execution? If you do it's bad and if you don't the code does nothing and is subject to optimization and may even be removed so that's bad too. In short you don't know what you're measuring here.

But, putting the traps of performance testing aside, please consider this quote of yours,

"This is mainly because the testId runs a comparison 3 times, whereas switch probably (my emphasis) does it one operation. However, like Winston said, this is highly dependent on the JVM, and actually the OS and even the CPU."

That's right. The JLS presents the switch statement from a grammatical and semantic point of view only. Other properties are subject to guessing. And this is why my advice makes sense. Utilizing application specific knowledge to remove implementation dependencies, that's a fine cigarr.