João Victor Gomes

Hello Jeanne and Scott

I have the OCA Java 8 certification, and started to prepare myself for the OCP Java 8 in 2018, again with one of your books as the main reference. But unfortunately I didn't have the time to finish the preparation back then.
Now, I'm going to start it again, and take the OCP Java 8 certification exam, and then go for the update exam over the next year.
I'd like to know if you think it's a "must" to update now, and if so, how you advise me to study and prepare myself for the update exam using your new books.

Thanks, and keep the great work!

Hello everyone.

I'm trying to configure the session timeout for my application, and I've found that I should use the property server.servlet.session.timeout inside the application.properties. But it doesn't work at all.
Is there another configuration I need to do in order to set the timeout properly? I searched about it, and some people said that it work, but not for me.

Thanks.

Hello everyone,

In the Chapter 6, page 315, Exam Essentials section, end of the first paragraph, it says "DateTimeParseException, IOException and SQLException are common checked exceptions". It should say ParseException rather than DateTimeParseException, since the latter is an unchecked exception.


>> EDIT
Sorry, now I realize that this error was already reported here and here. The thing is that I couldn't find it on the errata page.

Jeanne Boyarsky wrote:I don't know what I was thinking when I logged the errata. As you noted the JavaDoc clearly says that. Removed the errata.

Hello Jeanne. I was just about to create a topic about this.
I believe the errata wasn't removed yet, right?

Campbell Ritchie wrote:

João Victor Gomes wrote:. . . If the ID field is defined inside Vehicle class . . . the Van and Car classes should not have their own equals() method . . .

I think that answers your question

Three resources worth reading:

1: Effective Java by Joshua Bloch pages 33‑50

2: Odersky Spoon and Venners

3: Angelika Langer

Start with your standard book about equals(), then read those three links. That should get you well on the way to understanding equals().

Yes, I'm currently studying for the OCP exam using a book focused on the exam, plus the two Core Javas (by Cay Horstmann), and I ordered the book Effective Java, just waiting it to arrive

Thanks for the advices.

Campbell Ritchie wrote:So, Vehicles usually have IDs, called registration numbers or license numbers depending where you are. If two Vehicle instances have the same ID, what is going to happen if you have the equals() method in the Car and Van classes? Should you allow the Van and Car classes to have their own equals() methods?

If the ID field is defined inside Vehicle class, and it is the only field responsible for defining if an object is equal to another (of course, taking into consideration the other rules, for example, if the object is of the same type of another), the Van and Car classes should not have their own equals() method, to avoid the inconsistence mentioned in your other post. And the ID test inside the equals() method couldn't be done directly inside the subclasses if I make the ID field private, besides, having one equals() version for each of those two classes could lead to the problem of having different fields to define the equality.

David Simkulette wrote:So could you define equal in the super class then defer to the super class in the subclass? You could, but since the super class is (obviously) not final how do you know you won't have yet another variant subclass of the superclass with new properties for which this won't work ?

Hello David, thanks for your answer.
But in my case, I don't plan to have the equals method defined inside the subclasses (for the reasons that Campbell mentioned), and the equality will be defined by only one field, and for my needs, it will work, since it is a simple unique ID test.


Any tips are welcome, thank you all for the nice discussion. I want to know all the possibilities to consider when overriding equals() method.

Hello Campbell

Nice explanation. I understand that when we have more than one field to define the equality of the object, we must be careful with the equals and hashcode methods inside the subclasses, but I have a question.
When the object equality will be defined by only one field, for example, an id, and if I have an abstract superclass, where the id field is defined, is it a good idea to override the equals and hashcode inside the super class, and not overriding inside the subclass? Since in this case it will be only possible to create instances of subclasses, and the instance of the subclass will have its own ID, so at runtime the equals and hashcode versions of the superclass would be executed, using the object's id value.
Is this a good way to go?

Hi guys

First of all, there is an entry in the errata page that says: "The second bullet should end with 'except for static final fields'". It is identified as an error of chapter 8, but is from chapter 1.
Secondly, I believe this should be added to the page 25 about member inner classes as well (fourth item), since we can declare static final fields within member inner classes.

Congratulations Shane! I'm happy to know that you passed too.

Now, let's go for the OCPJP

Hello everyone,

There is an error on page 16 of the guide. The first line of the second paragraph says this: "The this. syntax is not required. Line 12 could have been return idNumber == otherLion.idNumber."
When it says "Line 12 could..." it should be "Line 13 could..."

Congratulations! That's a great score.

Congratulations! Great score.

When you try to print and object, the toString() method is called, but your class StringObject doesn't override the toString() method, so it uses the one inherited from Object, which prints this pattern of the type of the object plus @ plus hash code, as you can see in the Java documentation.

If you override the method toString, you can have another result, like this:
class StringObject{   private String strVal;   public StringObject(String strVal) {   this.strVal= strVal;   }   public String toString() {   return strVal; //here you return the value that you want to represent your object   } } public class Tester {    public static void main(String[] args) {        StringObject so = new StringObject("World");        StringBuilder sb = new StringBuilder("World");        System.out.println("Hello, " + so);        System.out.println("Hello, " + sb);   } }

Congratulations!
I'm preparing myself for the the OCPJP now too.

Just changing your code in order to compile

class A { void B() { C(); } void C() { } }

Chivid Ram wrote:
1)Instance Methods can be called from another Instance method within a same class  without reference variable.

Instance methods can be called within another instance method in the same class directly, but don't get confused about reference variables and objects. The reference variable itself isn't sufficient for calling an instance method. The reference variable needs to point to an object in memory in order to call an instance member without problems at runtime.

Chivid Ram wrote:
2)Instance Methods can be called from another Instance method in child class without reference variable.

Again, be careful with reference variables and objects, as I mentioned above.
About your points:
2 - You can call an inherited method inside another instance method that belongs to the subclass, but be careful with access modifiers. Let's take a look at some examples:
//Assume that these two classes are in the same file class StringedInstrument { public void tune() { System.out.println("Tuning..."); } } class ElectricGuitar extends StringedInstrument { public void play() { tune(); //the tune() method is public in the superclass, so it is inherited in the subclass } }

Now, what happens if the two classes are in different files and different packages? Let's see a different approach
package instrument; public class StringedInstrument { protected void tune() { //the method has protected access modifier System.out.println("Tuning..."); } } package guitar; import instrument.*; public class ElectricGuitar extends StringedInstrument { public void play() { tune(); //the method is inherited, so it can be used directly as if it was defined within ElectricGuitar } }
But what if the tune() method of StringedInstrument was defined with default access (package private)? Then the code wouldn't compile, because a member with default access is only visible for the class where it was defined or for classes inside the same package of the class that the member belongs to. But in the example above, the classes are in different packages, and a member with default access inside the superclass StringedInstrument wouldn't be visible to the subclass ElectricGuitar.
However, the tune() method is defined with protected access in the previous example, which is fine, because the member is visible for classes in the same package or for subclasses (in any package).

Chivid Ram wrote:
3)Instance Methods cannot  be called from another Instance method which is outside the class without using reference variable.Here reference variable is used.

You can't call an instance method of one class in a method of the other class directly. So, you have to create an instance of it (again, not just the reference variable, you need to have an object).

Chivid Ram wrote:
4)Static method cannot call Instance method without reference variable  even within same class or different class.

Yes, static methods can't call instance members (methods or variables) directly (without an instance of the class), because a static method doesn't need an instance to be used, and we have to create an instance of the class (not just the variable) to call the instance member inside the static method.