This week's book giveaways are in the Cloud and AI/ML forums.
We're giving away four copies each of Cloud Native Patterns and Natural Language Processing and have the authors on-line!
See this thread and this one for details.
Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!

Alion Bada

Greenhorn
+ Follow
since Aug 30, 2016
Cows and Likes
Cows
Total received
1
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alion Bada

Nice book idea
There is no reason now to close a database connection in a catch clause :p

L Foster wrote:Alion:
If you have not understood it all, then I have not answered well enough.  Sorry for that.  I will try one more time.  Maybe I should stick very closely to the words of your question.

We know that only overriden instance methods are dynamically invoked based on the real object's type.
So why getClass() have this behaviour without being overriden?  Because You cannot override getClass (https://docs.oracle.com/javase/tutorial/java/IandI/objectclass.html).



The "getClass()" method is not being overridden.  Instead, it is just returning a different value.  The behavior is not changed--only the value being returned is different.



I add this to make things more clearer :
Every class loaded in Java has a corresponding instance of java.lang.Class representing that class.
Instances of the class Class represent classes and interfaces in a running Java application.

it helped a lot :p
1 year ago

L Foster wrote:Alion:
If you have not understood it all, then I have not answered well enough.  Sorry for that.  I will try one more time.  Maybe I should stick very closely to the words of your question.

We know that only overriden instance methods are dynamically invoked based on the real object's type.
So why getClass() have this behaviour without being overriden?  Because You cannot override getClass (https://docs.oracle.com/javase/tutorial/java/IandI/objectclass.html).



The "getClass()" method is not being overridden.  Instead, it is just returning a different value.  The behavior is not changed--only the value being returned is different.



Now I understand lol
Thank you very much  !!
1 year ago

L Foster wrote:Hello, Alion:

Actually what you are seeing is not overridden behavior.  The 'getClass()' method is returning the Class object associated with the instance.  Although the returned value can vary infinitely, the behavior is actually no different.  If you were to call "getClass()" on something declared and constructed as just "Object o = new Object();", the instance 'o' would return you a Class instance, and that instance would have methods to tell the class' name, etc.  So this is a case of something being configured with different data than it would be otherwise.  If you were to declare something wildly different like a java.sql.Connection, it's 'getClass()' returned value whose getClassName() method would give a different string.  It need not even be an instance of the same Class class (I don't know: maybe you could extend the Class class and return something different? I've never tried as it's not something most users need to ever do).

The point is, the getter just gives you whatever has been set somehow.

As a beginner, perhaps this is mind-blowing, or perhaps it's a boring fact you just hadn't thought of it before.  But you can make your own "getter" that returns some object like, say Employee.  Employee could have fields in it representing address, salary, date of hire, date of birth, etc.  And you could use that one Employee class to represent anyone who has a job in the entire world if you make it general enough.  The same goes for Class.

Enjoy.



Thank you very much for your answer even if I don't understand all you've said
1 year ago
Hi everyone,

We know that only overriden instance methods are dynamically invoked based on the real object's type.
So why getClass() have this behaviour without being overrided because You cannot override getClass (https://docs.oracle.com/javase/tutorial/java/IandI/objectclass.html).

Thank you in advance
1 year ago

Jeanne Boyarsky wrote:Alion,
Chapter 1 covers the fact that you are supposed to implement hashCode() if you implement equals(). So by chapter 4, this is implied without specifying it.

Et Merci pour les gentils mots sur mon livre (and thank you for the nice words about my book) - my French is rusty so the grammar might be a bit off



OK I understand
It's implied.
Sinon ton français est très bien !

Campbell Ritchie wrote:I think you should supply a bit more information before we can answer properly. I don't have that book, so I don't know what the code you are referring to looks like.

Alion Bada wrote:. . . Java calls hashCode() and equals() to determine whether the objects are the same. . . .

That isn't quite true. Java® doesn't call any methods, but the programs written in it do. Some things use hashCode and some things don't.



When we say Java we think JVM...but yes, you need to have the book to understand what's going on...
omg how is it possible to live in java world without https://www.amazon.fr/OCP-Certified-Professional-Programmer-1Z1-809/dp/1119067901 :O
GO BUY IT
HI,
It's written page 196 for the distinct method : As you might imagine, Java calls equals() to determine whether the objects are the same.

I think it's better to add hashCode() method : As you might imagine, Java calls hashCode() and equals() to determine whether the objects are the same.

Because, if you don't ovveride hashCode() method, the duplicates are not removed.

Thanks
Nice one man !
I didn't pay attention to the "new" ... I was so impressed by the way of accessing an array through method name...(myArray()[0] )
Hi guys,

With a big surprise, I discovered that the behavior is different depending on whether you access an Array directly or through a method call..
Does someone know why ?
I suspect there is a stack thing somewhere but I can't explain why I have this result because an Array is an Object




Henry Wong wrote:A link to the section of the JLS that you are referring to...

https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.3.3

As a side note, forward references is *not* something that I deal with much, if at all. For some reason, it just irks me to have it, and I generally make sure that I don't have it in my code...


BTW, have a cow for answering your own question.

Henry



Thanks Henry for the encouragement cow ! OMG it's my first one :-D
I just hope this forward reference thing is not in the Java 8 OCA scope ....
I found this rules which maybe explain why :

Use of instance variables whose declarations appear textually after the use is sometimes restricted, even though these instance variables are in scope. Specifically, it is a compile-time error if all of the following are true:

The declaration of an instance variable in a class or interface C appears textually after a use of the instance variable;

The use is a simple name in either an instance variable initializer of C or an instance initializer of C;

The use is not on the left hand side of an assignment;
<-- This rule is not applied in line 5 but is applied in line 6

C is the innermost class or interface enclosing the use.

Can you confirm that I am right ?
Hi guys,
Does anyone know why these 2 lines does not have the same compilation error ?



Thank you for your help