Friday, 18 May 2018

Access control modifiers in Java

Just a small blog post.

Some time ago I came across a basic fact in the core Java programming language, that I have interpreted too narrowly for a very long time.

I always have interpreted the "protected" keyword as making the properties or methods of a class available in its subclasses.

Turns out, according to [1] this is not entirely accurate. That's not all it does.

The following table is lifted from the docs in [1]:

no modifier Y Y N N
private Y N N N

If you look at the table above, you'll notice that protected is really only one level more secure than public, which was an eye opener for me.

It turns out "protected", isn't really that protected really.

No modifier

If you omit any kind of modifier, you will automatically get the behaviour that the method/property can be accessed only by other classes in the same package.

There are several sources declaring it "no modifier" or "default modifier" or "default protected modifier", but I prefer the "package private modifier" (or just "package-private" for short). The latter is the official Java convention as described in [1].

To my mind it is the best clear short precise definition of what you can do with it.

The JLS2 strictly only mentions "package access".


Apparently there is no Access Modifier in Java that makes methods or fields only be inherited from subclasses3.

However we can achieve the same goal, by putting the subclasses of a class into the same package, and keep this package devoid of all others.

Sealing JARs

Of course, it means that if I create a package with the same name as a package in a JAR file included in my project, I will gain access to all the package private classes in the same package in the JAR.

This problem can apparently be solved by sealing4 the JAR file.


[1] Oracle - The Javatm Tutorials - Controlling Access to Members of a Class
[2] Oracle - Java Language Spec - JDK 8
[3] StackOverflow - Why is there no subclasses only access modifier in Java?
[4] Oracle - The Javatm Tutorials - Sealing Packages within a JAR File

Thursday, 10 May 2018

Default method 'toString' overrides a member of 'java.lang.Object'

An interface "inherits" methods from the Object class. I wrote about this here1.

The quotes are appropriate, because Interfaces can only inherit from other Interfaces. An interface, when it does not have a super interface, declares all public non-final methods of the Object as members of the Interface (if not explicitly defined in the interface.

I recently attempted something like this TaxBracket2:

It doesn't work. In fact my IDE started complaining immediately with the following message.

Default method 'toString' overrides a member of 'java.lang.Object'

It is supposed to do that, so says the Java Language Spec3:

It is a compile-time error if a default method is override-equivalent with a non-private method of the class Object, because any class implementing the interface will inherit its own implementation of the method.

My colleague helpfully provided the alternative, which is to make an "elementString()" method in the Interface, which can be called in the toString() method of every Class that implements the Interface. (Further down in the JLS, this approach is almost word for word also given)

StackOverflow4 has a helpful link to the JDK mailinglist5 that explains it a lot more in depth.

One of the remarks that really struck a cord with me, is the fact that toString(), equals() and hashCode() are all basically related to the state of a Class, and do not belong in an Interface.

I have therefore decided to remove the offending default method.


[1] Do interfaces inherit from object class?
[2] Wikipedia - Tax bracket
[3] JLS 8 - Requirements in Overriding
[4] StackOverflow - Java8: Why is it forbidden to define a default method for a method from java.lang.Object?
[5] Malinglist OpenJDK - Allow default methods to override Object's methods