The way an API writer would do it in Java is roughly equivalent but different
without the availability of MI.

Let's turn the problem about and look at it from the framework author's
viewpoint.  Your C++ author uses MI to combine widgetism with skinnableism,
etc.  Your Java author would use interfaces instead, and hide the
implementations that combine the contracts from you altogether.  So, they
might define

 public abstract class JComponent extends Container
 implements Serializable // and by inheritance, ImageObserver, MenuContainer

Concrete implementations (subclasses) of JComponent will have the equivalent
of multiple inheritance of default implementations for all three of those
interfaces, much as they would if they inherited from three base classes.

Also, interfaces do support MI; only classes do not.

The idiomatic difference between extending multiple classes as in C++ vs.
implementing multiple interfaces as in Java has to do with when you do the
mixdown.  In Java you typically mix the interfaces down into an abstract
superclass that establishes the equivalent of MI, but specific to the domain
of discourse for the project.  That is the real point of the Widget vs. Mammal
comparison - interfaces define a common kind of behavior or attribution
without restricting the semantic space too much.

Note that I am not saying one style is better or worse than another.  Java's
designers chose to avoid MI for implementations (classes) because of the
problems that it causes.  They kept it in for contracts (interfaces) because
that's where multiple inheritance actually shows most of its usefulness
without most of the complications.  This in turn necessitates Java idioms like
the common abstract base class that acts as the gatherer for relevant interfaces.