"null", polymorphism and TCO

  A book said that one needed null to mark the end of a linked
  list:

class Entry { java.lang.String text; Entry next; };

public final class Main
{ public static void main( final java.lang.String[] args )
  { Entry first = new Entry(); first. text = "first";
    Entry second = new Entry(); second.text = "second";
    first.next = second;
    Entry last = new Entry(); last.text = "third";
    second.next = last;
    for
    ( Entry current = first; current != null;
      current = current.next )
    java.lang.System.out.println( current.text ); }}

  This prints:

first
second
third

  Neither null nor java.util.Optional is needed when one
  is using polymorphism, i.e., real OOP. We just need to say
  that an entry with a next entry is a different type than
  an entry without a next entry. No ?null?, no ?Optional?,
  just polymorphism!

abstract class Entry
{ java.lang.String text;
  abstract void accept
  ( java.util.function.Consumer< java.lang.String >consumer ); }

class TerminationEntry extends Entry
{ void accept
  ( java.util.function.Consumer< java.lang.String >consumer )
  { consumer.accept( text ); } };

class ContinuationEntry extends Entry
{ Entry next; void accept
  ( java.util.function.Consumer< java.lang.String >consumer )
  { consumer.accept( text ); next.accept( consumer ); }};

public final class Main
{ public static void main( final java.lang.String[] args )
  { ContinuationEntry first = new ContinuationEntry();
    first. text = "first";
    ContinuationEntry second = new ContinuationEntry();
    second.text = "second"; first.next = second;
    TerminationEntry last = new TerminationEntry();
    last.text = "third"; second.next = last;
    first.accept( java.lang.System.out::println ); }}

  This, too, prints:

first
second
third

  But now, there is a case of recursion (in the method
  ?accept? of the class ?ContinuationEntry?). But it is
  tail recursion. Now, this might be too far fetched,
  but insofar one might say that proper OOP needs TCO
  and hope that one day Oracle will find this out!

  From a practical point of view, the null solution
  seems to be a kind of optimization: When one wants
  to append to a TerminationEntry, one first needs to
  replace it by a ContinuationEntry. This wastes more
  resources than just overwriting a null value.