0

Java 8 introduces a new feature called default methods which looks like this:

interface A {
    default int getInt() {
        return 0;
    }
}

However, if we add multiple methods:

class Event{...}
class EventA extends Event{...}
class EventAData{}
interface A {
    default void handleEvent(Event event) {
        if(event instanceof EventA) {
            handleData(((EventA) event).getData());
        }
    }

    default void handleData(EventAData data) {
        handleEvent(new EventA(data));
    }
}

handleEvent() checks if the event is of class EventA and by default implements a legacy way to handle EventA. handleData() converts the data into an Event and uses the super new method handleEvent() to handle the data.

The problem I see is that, when neither of them was implemented, the two methods would call each other, resulting in a stack overflow error. I would probably use reflection to check if the caller is the default handleEvent() and return if it is.

Is it okay to do so? If not, why?

EDIT: fixed a typo, handleEventA should be handleData

lospejos
  • 1,976
  • 3
  • 19
  • 35
vincent163
  • 384
  • 2
  • 13
  • 5
    No. This is a terrible idea. Providing a `default` implementation that crashes is just bad. You also cannot work out how the caller of a method is through reflection. So that's an even worse idea. – Boris the Spider Jan 29 '17 at 17:05
  • 2
    Wait, where is `handleEventA` in your code defined? – Chetan Kinger Jan 29 '17 at 17:07
  • This implementation is definitely not ok, you are making assumptions on how the client of your interface should use it and structuring it in a way that wrong usage will break the default implementation. – uraimo Jan 29 '17 at 17:09
  • @BoristheSpider I agree that it's a bad idea to provide default implementations that crashes, but I believe that somehow I could resolve the stack overflow problem. – vincent163 Jan 29 '17 at 17:18
  • Wait a minute, how can a method that takes an `EventAData` be passed an `EventA`. That's it, I am calling the SWAT team. (Voting to close unless code is corrected) – Chetan Kinger Jan 29 '17 at 17:30
  • using reflection to check such unexpected calls is a bad idea because reflection is terribly slow (relative to method calls and other standard operations). See [here](http://stackoverflow.com/questions/3502674/why-is-reflection-slow). Can you use a "consumed" boolean (set in first line of default handleEvent) on the event to check if it's already handled by the default handleEvent? – Christoph Bimminger Jan 29 '17 at 17:46
  • 1
    Would your problem not merit the adapter pattern? – Joe C Jan 29 '17 at 18:10
  • @CKing EventA.getData() returns an instance of EventAData. – vincent163 Jan 30 '17 at 05:01
  • @ChristophBimminger That's what I'm thinking, I will probably not use reflection but by 'normal' ways, such as putting a flag in EventA, etc. Anyway I don't think the stack overflow error is the major problem here. – vincent163 Jan 30 '17 at 05:03

0 Answers0