Posts Tagged ‘SCJP’

Studying Java at University should give you enough grounding to get by in your day job, but can you really call yourself a Java programmer unless you know the language inside and out? In this series we will outline the lesser known features of how the language works, taken from the SCJP objectives. Mastering these will increase your understanding of the language, and possibly (no guarantees) elevate you to demi-god status in the workplace. If you are studying for the SCJP examination you may also find these examples to be useful revision.

Variable Names

Identifiers in Java can begin with a letter, underscore or $. The characters after the first one can include digits too. These are all valid variable declarations:

int myVar;
int $var;
int _var;
int _var2;
int $$$;

Normally you would stick to using the alphabet, with following words capitalised:

int myLongVariableName;

Beginning local variables with an underscore (_) is a common convention as well.

int _aLocalVariable;

Interface Constants

Given the following interface:

public interface ConstantInterface {
    int x = 2;

and an implementation of it

ConstantInterface impl = new ConstantInterface() {
   void test() {
      x = 2;

This will not compile! The variable x is implicitly public static and final because it is declared in an interface. The code could be made more readable by capitalising the variable name, to show the intent that it is a constant. Alternatively, move the constant out of the interface as constant interfaces are rarely a good idea [1]

What do protected methods really mean?

Everyone knows that public methods can be called anywhere and that private methods can only be called within it’s own class. So what about protected methods? First, lets explain what no access modifier means:

package com.example.epiccode;
public class Ping {
   void myMethod() {
      System.out.println("fuzzy wuzzy was a bear");

myMethod can be called from any class within the same package. i.e. any class that belongs to the package com.example.epiccode. This is because it has no (default) access modifier. If a class belonged to the package com.example.epiccode.winner it cannot call this method because it is in a different package (no exception made to sub-packages).

Protected methods follow exactly the same rules as default methods, except they also allow access to subclasses by inheritance only. This is a very subtle point as shown below.

package com.example.epiccode;
public class Ping {
   protected void myMethod() {
      System.out.println("I'm default yeh");

We have changed myMethod to be protected. Now let’s subclass Ping.

package com.example.anotherpackage;
import com.example.epiccode.Ping;
public class Submarine extends Ping {
   void dive() {

This code is perfectly fine – dive can call myMethod because Submarine extends Ping (even though they are in different packages).

The following code will not compile:

package com.example.anotherpackage
import com.example.epiccode.Ping
public class Submarine2 extends Ping {
   void dive() {
     Ping p = new Ping();

We are not accessing myMethod through inheritance, instead we are creating a new instance of Ping and trying to call myMethod on it. This will not compile since Submarine is not in the same package as Ping. Funnily enough this subtlety is too much for Eclipse to handle:

eclipse error

The method is already protected, so the quick fix will not work.


[1] Effective Java 2nd Edition by Joshua Bloch – Item 19: Use interfaces only to define types.

Read Full Post »