Skip to content

Misfiring Neurones

Last night, I let my memory drive my mouth. Always a baaad idea. My memory tends to be…how to put it…imprecise. Whereas my mouth faithfully does whatever it is told; there’s no auto-correct feature that might cut in when needed.

My naughty neurones told me that since Java 1.6 one could have the following:

class Rubbish {
    private Integer get() {
        return 42;

    private String get() {
        return "42";

    public static void main(String [] args) {
        Rubbish r = new Rubbish();
        Integer i = r.get();
        String s = r.get();

I was thinking that the definition of a method’s signature had been changed to include the return type.

Bzzzzzt! Wrong! Nonsense!

The JLS says:

Two methods have the same signature if they have the same name and argument types.

No mention of return type there.

Both IntelliJ and the Java compiler are more than happy to point out the numerous inadequacies of my naive neural noodlings:

What was I thinking?


Java 1.5(!) introduced a feature called “covariant return types.” Wikipedia says:

…a covariant return type of a method is one that can be replaced by a “narrower” type when the method is overridden in a subclass.

Put another way:

…a method in a subclass may return an object whose type is a subclass of the type returned by the method with the same signature in the superclass. This feature removes the need for excessive type checking and casting.

This feature actually looks like this (thanks to Wikipedia again):

 // Classes used as return types:

 class A {

 class B extends A {

 // "Class B is more narrow than class A"
 // Classes demonstrating method overriding:

 class C {
     A getFoo() {
         return new A();

 class D extends C {
//Overriding getFoo() in father class A
     B getFoo() {
         return new B();

The Simpsons can be trusted to provide an apposite snippet for almost any situation, including this one:

Homer’s brain: Wait! Are you sure that’s how this sort of thing works?
Homer’s Homer: Shut up, brain, or I’ll stab you with a Q-tip!

In a slight non-sequitur, I thought it would be interesting to look at how times change with respect to API definitions.

Here’s two methods. The first is from JDBC, java.sql.DriverManager, API originated ca. 1997:

public static Connection getConnection(String url,
                       String user,
                       String password)
                                throws SQLException
Attempts to establish a connection to the given database URL.
The DriverManager attempts to select an appropriate driver from the set of registered JDBC drivers.

And the second API (the one that started the paux-pas for which I herein atone in the first place) from Java ME 8, jdk.dio.DeviceManager, API ca. 2014:

static <P extends Device<? super P>> P open(int id)
Looks up and opens a Device instance for the provided numerical ID.

Now, I’m GUESSING that these two methods do ROUGHLY the same thing: return an instance of some common-ish type based on some sort of lookup.

Look how “grown up” Java has become! Some might say that it is suffering from middle-aged spread.

Tags: ,

C, Java Enterprise Edition, JEE, J2EE, JBoss, Application Server, Glassfish, JavaServer Pages, JSP, Tag Libraries, Servlets, Enterprise Java Beans, EJB, Java Messaging Service JMS, BEA Weblogic, JBoss, Application Servers, Spring Framework, Groovy, Grails, Griffon, GPars, GAnt, Spock, Gradle, Seam, Open Source, Service Oriented Architectures, SOA, Java 2 Standard Edition, J2SE, Eclipse, Intellij, Oracle Service Bus, OSB