Ankit Garg

I agree with you Fabricio, the question is ambiguous. The compilation error is not on line 3, but to me the error/mistake is more on line 9 where hatch is not passed to super constructor.

int i1 = c1 + c2; //Here c1 and c2 are promoted to ints?
char c3 = c1 + c2; //How about here?

You are right, c1 and c2 will be promoted to int, that's why the 2nd line won't compile.

int i2 = 'a' + 'b'; //There is no promotion?
char c4 = c1 + c2;   //How about here?

Here I'm assuming you wanted to write char ch4 = 'a' + 'b'; which does compile i.e. the literal values are not promoted to int.

As Mikalai mentioned, there is generally an option which says the code won't compile, but it won't ask how many lines won't compile. The creators of the exam make extra effort to make questions which are not ambiguous (or dependent on compiler behavior like this).

Howdy Marco, let's take a look at it with an example. Let's say you have this parent class:

class Parent {  void print() {    System.out.println("Message: " + getMessage());  }  String getMessage() {    return "Parent class";  } } class Child extends Parent {  String getMessage() {    return "Child class";  } } class Caller {  void call(Parent target) {    target.print();  } }
Now looking only at the above code, can you say for sure whenever print method is called it will always print Message: Parent class? I might call the call method with new Parent() as parameter OR I might send a new Child() to the call method. Or I might create another class which extends Parent. I'm pretty sure that's what the question meant to say. When you look only at your class (Parent in this case), you don't know who will inherit from it (someone else 6 months later might inherit from your class), so you cannot be sure which method call will be overridden.

R Pinjarkar wrote:how much objects will be created from
1) String s=”amit” 2) String s=”amit” 3) String s=new string ”amit"
What is the answer

Howdy, welcome to Coderanch.

Let me try to fix your code slightly so that it would compile, then I would try to answer it
String s1 = "amit"; String s2 = "amit"; String s3 = new String("amit");
There will be 2 String objects created here. s1 and s2 will point to the same String object (coming from the String constant pool), while s3 will point to a separate String object as you are specifically calling the constructor.

Hi Karem,

Welcome to the Ranch!

I would say give the exam that you've prepared for. If you've prepared for the Java 11 exam for last 4 months, then give that one. Each exam adds and removes topics compared to previous exams, so if you've prepared for a different one and attempt a different one, you might encounter topics you've not studied. Also remember most of the mock/practice exams are more difficult than the real exam.

Good Luck for clearning the exam, hopefully your contract will be renewed

Hi Priyanka,

So in both cases, the problem is that the Comparator you are using is causing this confusion. So the max method takes a Comparator and uses that to compare each object with the other. The comparator is supposed to compare the two numbers, return a positive value is the first one is bigger or a negative value if the second one is bigger. So something like this:

Comparator<Integer> normalComparator = (a, b) -> a - b;
But your comparator always returns the biggest value, so whenever it compares two numbers, it will always thinks the first number is bigger. So it will do the following:

Arrays.asList(3,4,6,9,2,5,7);
1. Compare 3 to 4, comparator will return 4, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.
2. Compare 3 to 6, comparator will return 6, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.
3. Compare 3 to 9, comparator will return 9, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.
4. Compare 3 to 2, comparator will return 3, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.
5. Compare 3 to 5, comparator will return 5, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.
6. Compare 3 to 7, comparator will return 7, since it is a positive number the Stream thinks the first number i.e. 3 is bigger.

So due to the comparator you are passing, the stream thinks the first number is the biggest.

What was the output when you ran the code, and do you have any doubts about why the output was what it was?

Strange, for me even if I remove the body of SUMMER, the code doesn't compile, I get a different error:

Season is abstract; cannot be instantiated

use this block for both SUMMER and FALL because I want the same implementation for both of them.

Is this some new syntax rule that I'm not aware of?

Hi Moe,

Are you sure the code compiles without the printHours in any of the enum constants? If I try to remove one of the methods I get this error

enum Season {  WINTER {}, <-- no method declared in enum constant  SPRING {    public void printHours() { System. out .println("9am-5pm"); }  },  SUMMER {    public void printHours() { System. out .println("9am-7pm"); }  },  FALL {    public void printHours() { System. out .println("9am-5pm"); }  };  public abstract void printHours(); } <br /> Season> is not abstract and does not override abstract method printHours() in Season.WINTER

My personal experience with SCJP was that I got like 4-5 questions wrong initially. Fortunately I had time to review all answers, and I corrected all of them (at least I think I did, I still got 1 question wrong in the end ).

Kertes Gray wrote:The answer is the moment you put a collection with a reference bound(upper-bound), it is now immutable.

Hi Kertes, this is not entirely true though. The collection is mutable, you can sort it, clear it, delete elements at certain indexes from it. You just cannot call add method on it as the parameter <? extends Bird> won't take any type of object as a valid argument. The only way to call add on a List<? extends Bird> is to do something like this add(new <? extends Bird>()) which obviously is not a valid syntax

To add to Jesse's excellent explanation, the purpose of such a list is to get objects from it and perform operations on them which all birds can do. So for example

class Bird {  void feed(Food food) {....} } class Nightingale extends Bird {  void sing() {...} } class GenericsTest {  private Food someFood;  void feedBirds(List<? extends Bird> birdsToFeed) {    for(int i = 0; i < birdsToFeed.size(); i++) {      Bird birdToFeed = birdsToFeed.get(i);      birdToFeed.feed(someFood);    }  } }
So as you can see, you can loop over the List<? extends Bird> and feed all the birds.

It is not that the List<? extends Bird> is immutable, but no parameter you pass to the add method will be allowed by compiler. The main difference lies in the declaration of the add and get methods.
public interface List<T> {  T get(int i);  void add(T elementToAdd); }
For a List<? extends Bird> the get method returns <? extends Bird> you don't know exactly what it returns but it will be either Bird or Nightingale or some other sub-class of Bird so you can always be sure it is assignable to Bird. <br /> But for the add method, any parameter you pass won't be allowed as <? extends Bird> doesn't tell the compiler exactly what the type <T> is. So whether you try to pass a Bird object or a Nightingale to the add method, nothing is <? extends Bird> so the compiler cannot allow you to pass any of them to the add method. <br /> Thus although it might look like a List<? extends Bird> is immutable, but actually the problem is the there is no valid parameter to the add method. You can for example call List.clear method to clear a List<? extends Bird> so it is not immutable.

Hi Priyanka,

One of the key is to understand here is that once a variable is assigned, the compiler doesn't keep track of what value was assigned to it. All it cares about is the type of the variable.

catch(Exception ex) {   ex = null;   throw ex; }
On the throw statement the compiler doesn't know whether ex was assigned null or something else. All it knows is that ex is of type Exception and that you need to handle it.

There are many ways to confirm this behavior, for example the following code:

class Super {} class Sub extends Super {} class Main {   public static void main(String[] args) {      Super sup = new Sub();      Sub sub = sup;  // compiler error   } }
In the above code when you try to assign sup which is of type Super to sub which is of type Sub (which inherits from Super), the compiler won't allow it. Even though you know the assignment will work (as sup contains an object of type Sub), but when compiler sees the statement Sub sub = sup; all it knows is sup is of type Super and Super is-not-a Sub.

I had a similar delimma when I did SCJP, I started preparation with SCJP for Java 1.4 book (not realizing there was SCJP for Java 1.5), then bought and went through the 1.5 book, but eventually gave SCJP 1.6 exam (the 1.5 and 1.6 exams were supposed to be almost the same). Between Java 1.4 and 1.5 there were a lot of changes, so I was glad I took the latest exam.