Ankit Garg

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.

I do see this in the Exam objectives/topics, so I would assume it is covered:

Create worker threads using Runnable and Callable, and manage concurrency using an ExecutorService and java.util.concurrent API

Hi Jeremy, welcome to the ranch.

It really depends on how much time you can give to study for the exam, and how much practice you want to do. Since you mentioned you can spend a couple of hours study daily, I guess you'll be able to complete the book in a couple of months. Then you can do lots of mock exams. I studied for about 5-6 months for my own SCJP certification (1-2 hours study a day), including doing mocks for almost 2 months.

I can't find the Table 1.1 you are referring to, but if you think about it, although anonymous inner classes are implicitly final, there is no valid syntax to mark it final. If you do this

private final Runnable r = new Runnable() {   public void run() {} }
You are declaring the variable final not the anonymous inner class.

I can probably annotate each line if that helps:

final Child m = new Child(); final Person t = m; m.name = "Elysia";  // since the field name is static, this is the same as doing Child.name = "Elysia"; t.name = "Sophia";   // since the field name is static, this is the same as doing Person.name = "Sophia"; m.setName("Webby");  // this will call the setName method on Child class thus it will update Child.name t.setName("Olivia");  // this will call the setName method on Child class thus it will update Child.name // so now Child.name is "Olivia" which was set in the last statement, and Person.name is "Sophia" as it was set only once on the second statement

The question says that "For simplicity, let's give each module the same name as the package". The question doesn't say that the module name is magic.helper. I guess instead of making it simpler, the question made it more confusing

Hi Shoeb, welcome to the Ranch.

Did you try to contact your credit card provider?

The compiler is intelligent these days, so as Charles said, it can figure out that the value you are giving on the right hand side is within the range of short.

The only exception to this is when you are passing an int literal to a method which takes short as argument. In that case you have to do explicit type-cast. There is an example specifically in the JLS for this:

5.3. Method Invocation Conversion
class Test {    static int m(byte a, int b) { return a+b; }    static int m(short a, short b) { return a-b; }    public static void main(String[] args) {        System.out.println(m(12, 2));  // compile-time error    } }